IRC log for #brlcad on 20110101

12:06.42*** join/#brlcad mafm (~mafm@126.Red-83-42-153.dynamicIP.rima-tde.net)
15:08.16*** join/#brlcad crazy_imp (~mj@a89-182-5-83.net-htp.de)
18:06.35*** join/#brlcad Elrohir (~kvirc@p5B14BA25.dip.t-dialin.net)
21:18.29*** join/#brlcad mafm (~mafm@126.Red-83-42-153.dynamicIP.rima-tde.net)
22:57.36*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
IRC log for #brlcad on 20110102

IRC log for #brlcad on 20110102

11:25.28*** join/#brlcad mafm (~mafm@91.Red-81-35-69.dynamicIP.rima-tde.net)
13:28.42*** join/#brlcad Elrohir (~kvirc@p5B14A5CF.dip.t-dialin.net)
14:39.33brlcadwhat does vtkfreetype add that a) we need and b) is different than just using ftgl or freetype directly
14:47.49CIA-48BRL-CAD: 03brlcad * r41902 10/brlcad/trunk/src/other/libz/ (zconf.h zlib.h): make sure _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS are defined before testing their values
15:07.41*** join/#brlcad crazy_imp (~mj@a89-182-206-37.net-htp.de)
17:41.44*** join/#brlcad mafm_ (~mafm@91.Red-81-35-69.dynamicIP.rima-tde.net)
21:47.05starseekerbrlcad: vtkfreetype is a subset of freetype that can be built with CMake
21:47.46starseekerit does not replace ftgl - I'm hoping it gives us the font file -> ftgl display conversion capability
21:48.03starseekerif freetype is installed we can use it directly, but on Windows that's a no-go
21:48.29starseekerand the current freetype build system doesn't look at all encouraging
21:48.46starseekerhopefully, vtk has already solved the problem
22:27.10starseekerof course, they're using some pretty old versions so I may still have to tackle the freetype build in the end
22:45.58*** join/#brlcad mafm_ (~mafm@91.Red-81-35-69.dynamicIP.rima-tde.net)
22:45.58*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
22:45.58*** join/#brlcad willdye (~willdye@fern.dsndata.com)
22:55.09*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
22:55.09*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
23:29.20*** join/#brlcad mafm_ (~mafm@91.Red-81-35-69.dynamicIP.rima-tde.net)
23:29.20*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
23:29.20*** join/#brlcad willdye (~willdye@fern.dsndata.com)
23:42.32*** join/#brlcad CIA-43 (~CIA@208.69.182.149)
23:58.21*** join/#brlcad Elrohir (~kvirc@p5B14B63F.dip.t-dialin.net)
IRC log for #brlcad on 20110103

IRC log for #brlcad on 20110103

00:50.51*** part/#brlcad AR_ (~AR@24.115.208.248)
04:12.46brlcadstarseeker: ah, then 'meh' .. :)
04:13.28brlcada forked freetype isn't very interesting.
04:13.56brlcadthey're big enough and with enough momentum/activity that any fork is pretty much busy work .. making a proper cmake build for the freetype folks would probably be more worthwhile
08:37.35*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:43.58*** join/#brlcad mafm_ (~mafm@131.Red-83-37-155.dynamicIP.rima-tde.net)
10:55.54*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
10:55.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:05.17DaveLo-AFKMernin all!
12:33.55*** join/#brlcad _psilva_ (~psilva@static-96-255-52-7.washdc.fios.verizon.net)
12:38.54*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:53.14*** join/#brlcad Ralith (~ralith@216.162.199.202)
12:53.14*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
12:53.14*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
14:38.49*** join/#brlcad mafm (~mafm@131.Red-83-37-155.dynamicIP.rima-tde.net)
15:08.00*** join/#brlcad crazy_imp (~mj@a89-182-195-216.net-htp.de)
15:43.59*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
15:52.42CIA-43BRL-CAD: 03erikgreenwald * r41903 10/brlcad/trunk/src/conv/dem-g.c: remove duplicate declaration of buf3
18:40.45CIA-43BRL-CAD: 03erikgreenwald * r41904 10/brlcad/branches/bottie/src/librt/primitives/bot/btg.c: remote hitsort (should already be sorted from tie). test for maxhits earlier.
18:43.16*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:18.29*** join/#brlcad Stattrav_ (~Stattrav@117.192.128.58)
19:27.32*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:25.28*** join/#brlcad Ralith (~ralith@216.162.199.202)
21:29.09*** join/#brlcad mafm (~mafm@185.Red-88-15-71.dynamicIP.rima-tde.net)
22:01.37*** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl)
22:37.09*** join/#brlcad Ralith (~ralith@216.162.199.202)
22:41.59*** join/#brlcad crazy_imp (~mj@a89-182-195-216.net-htp.de)
23:41.58CIA-43BRL-CAD: 03starseeker * r41905 10/brlcad/branches/cmake/src/ (71 files in 9 dirs): Sync cmake branch to trunk r41904
23:45.36*** join/#brlcad roberthl (~robert@v001.rhl.me.uk)
23:45.36*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
IRC log for #brlcad on 20110104

IRC log for #brlcad on 20110104

00:36.22*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
01:07.43CIA-43BRL-CAD: 03starseeker * r41906 10/brlcad/trunk/regress/ (13 files): Try to structure the regress scripts so they will work both with CMake and autotools
01:10.11starseekerO.o  the cmake build of mged in-dir is somehow pulling the /usr/brlcad versions of libraries even when mged -v reports the right versions for libs
01:17.26CIA-43BRL-CAD: 03starseeker * r41907 10/brlcad/branches/cmake/regress/library.sh: Sync library.sh with trunk.
01:50.42starseekerno, maybe it's more subtle than that... it doesn't work right if all the dependencies aren't in place, but it still returns lscon somehow with the ? command
01:56.08CIA-43BRL-CAD: 03starseeker * r41908 10/brlcad/branches/cmake/src/mged/CMakeLists.txt: Just like btclsh/bwish, mged needs to require itcl/itk be built if using local copies - build will succeed, but package require will fail.
01:57.37*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
01:59.09CIA-43BRL-CAD: 03starseeker * r41909 10/brlcad/branches/cmake/regress/CMakeLists.txt: Flesh out the dependencies on the regression scripts.
02:03.29CIA-43BRL-CAD: 03starseeker * r41910 10/brlcad/trunk/src/conv/iges/ (getcurve.c iges_struct.h): pull the EQUAL out of iges_struct.h, replace its use with NEAR_EQUAL
02:19.06CIA-43BRL-CAD: 03starseeker * r41911 10/brlcad/branches/cmake/src/libbu/parse.c: Hmm - looks like a sync didn't quite get everything - update libbu parser.c to match trunk.
02:36.36starseekergrowl... what's wrong with the shader regression? have to test in autotools...
02:37.48starseekercan't help thinking our shader code shouldn't be this fragile...
02:40.14starseekerhmm, cmake specific
02:40.27starseekerok, that's good and bad
02:45.06starseekerlooks like some syncs went wrong somehow... figures
02:45.14starseekerwill sort the mess out tomorrow
04:17.21CIA-43BRL-CAD: 03starseeker * r41912 10/brlcad/branches/cmake/regress/ (CMakeLists.txt shaders.sh): This may not be the whole story, but clearly this was wrong - generalize gencolor call in shaders.h
04:23.04starseekeryeah, that's not the only issue
04:32.29starseekerwonders if his FindTCL.cmake antics have broken stuff... quite possible
07:22.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:58.14*** join/#brlcad Ralith (~ralith@216.162.199.202)
08:27.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:44.50*** join/#brlcad Stattrav (~Stattrav@122.172.38.200)
08:44.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:47.41*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
08:47.41*** join/#brlcad willdye (~willdye@fern.dsndata.com)
08:47.41*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
08:47.53*** join/#brlcad Ralith (~ralith@216.162.199.202)
08:48.49*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
08:48.49*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
08:48.49*** join/#brlcad DaveLo (~claymore@BZ.BZFLAG.BZ)
08:49.04*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
08:49.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:26.15*** join/#brlcad roberthl (~robert@v001.rhl.me.uk)
09:26.15*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
09:39.29*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
10:22.22*** join/#brlcad roberthl_ (~robert@v001.rhl.me.uk)
10:26.37*** join/#brlcad roberthl (~robert@v001.rhl.me.uk)
10:26.37*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
10:57.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:10.07*** join/#brlcad mafm (~mafm@72.Red-83-54-182.dynamicIP.rima-tde.net)
11:54.15*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
11:54.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:03.09*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:56.00*** join/#brlcad Ralith_ (~ralith@216.162.199.202)
14:00.36CIA-43BRL-CAD: 03starseeker * r41913 10/brlcad/trunk/regress/shaders.sh: Add the generalization of shaders.sh to trunk too
14:30.56CIA-43BRL-CAD: 03starseeker * r41914 10/brlcad/trunk/ (7 files in 4 dirs):
14:30.57CIA-43BRL-CAD: Hmm. Looks like the CMake logic for liboptical/libmultispectral is
14:30.57CIA-43BRL-CAD: significantly different than autotools in some fashion. This set of changes
14:30.58CIA-43BRL-CAD: gets things working in trunk with regression test passing - need to reexamine
14:30.58CIA-43BRL-CAD: the liboptical CMake build in detail.
14:50.36CIA-43BRL-CAD: 03starseeker * r41915 10/brlcad/branches/cmake/src/ (5 files in 2 dirs): Sync cmake branch to trunk r41914
15:08.19*** join/#brlcad crazy_imp (~mj@a89-182-217-101.net-htp.de)
15:16.01CIA-43BRL-CAD: 03starseeker * r41916 10/brlcad/branches/cmake/src/adrt/CMakeLists.txt: Sync adrt build logic to match Makefile.am - per Erik, master and slave commands aren't really relevant anymore so removing build logic. This code is still in a state of flux, apparently.
15:17.59CIA-43BRL-CAD: 03starseeker * r41917 10/brlcad/branches/cmake/src/adrt/CMakeLists.txt: Add note about needing to examine Windows build files for custom logic
15:20.44CIA-43BRL-CAD: 03starseeker * r41918 10/brlcad/branches/cmake/src/ (libmultispectral/CMakeLists.txt liboptical/CMakeLists.txt): Make the liboptical/libmultispectral build match more closely the Makefile.am build. This appears to result in the shader test passing.
15:40.39starseekerbreaths a sigh of relief
15:56.43CIA-43BRL-CAD: 03starseeker * r41919 10/brlcad/branches/cmake/doc/docbook/ (CMakeLists.txt fop.xconf.in): set srcdir in the CMakeLists.txt file so we can use the fop.xconf.in that is compatible with autotools (looks like we may have had the wrong CMake variable in there anyway)
16:00.25CIA-43BRL-CAD: 03starseeker * r41920 10/brlcad/trunk/ (include/raytrace.h src/proc-db/csgbrep.cpp): Have csgbrep go through the table interface.
16:06.10CIA-43BRL-CAD: 03starseeker * r41921 10/brlcad/trunk/src/tclscripts/archer/images/ (Makefile.am Themes/): Archer should no longer be using the Themes directory - eliminate it.
16:11.48CIA-43BRL-CAD: 03starseeker * r41922 10/brlcad/branches/cmake/src/tclscripts/archer/images/Makefile.am: Sync archer/images Makefile.am with trunk
16:15.38CIA-43BRL-CAD: 03starseeker * r41923 10/brlcad/branches/cmake/src/libgcv/wfobj/ (libobj/ obj_grammar.yy obj_rules.ll): For now, put the wfobj dir back the way it was. We need a working byacc/flex solution before libobj can be hooked into the build properly.
16:19.44CIA-43BRL-CAD: 03starseeker * r41924 10/brlcad/trunk/src/brlman/brlman.sh.in: We don't use AWF anymore - fix the comment in brlman
IRC log for #brlcad on 20110107

IRC log for #brlcad on 20110107

22:38.43*** join/#brlcad ibot (~ibot@rikers.org)
22:38.43*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years...
22:41.25*** join/#brlcad ibot (~ibot@rikers.org)
22:41.25*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years...
22:50.46*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
IRC log for #brlcad on 20110108

IRC log for #brlcad on 20110108

00:53.06*** join/#brlcad cjdevlin1 (~devlin@d118-75-252-178.try.wideopenwest.com)
01:02.15*** join/#brlcad crazy_imp (~mj@a89-182-203-165.net-htp.de)
01:06.35*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
01:12.51*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
01:12.52*** part/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
02:04.23*** join/#brlcad DX^ (~DX@c-71-59-50-121.hsd1.ga.comcast.net)
02:04.56DX^If I want to convert a file from .G to another format, it asks me for a region name in the command line.  I tried "top" and "all" and a bunch of other crap but I can't remember what the correct parameter is.
02:05.18DX^Also, is there a command line function to list all of the names of the objects in a .G database file?
02:07.16RalithI don't know the answers to your questions, but is there a reason you can't just open it in mged and list it there?
02:18.15brlcadDX^: the command is "tops", not "top"
02:18.22DX^ah bah
02:18.32brlcadtop just sets a top-view
02:18.45brlcadls would list objects
02:18.55brlcadtree will list the hierarchy
02:49.15*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
04:54.33*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
05:38.03*** join/#brlcad ntosme2 (~narf@user-105n9h9.cable.mindspring.com)
05:52.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:04.13ntosme2hey guys, I just compiled and installed brl-cad...where's the main executable?
06:06.29ntosme2all I see are brlman and brlcad-config
06:08.04ntosme2ah /usr/brlcad/bin/mged
06:08.31ntosme2why is it not in the path?
06:23.05*** join/#brlcad Stattrav (~Stattrav@122.167.254.119)
06:23.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:24.25RalithDoes anyone have jonored's email?
06:27.30*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
11:06.02*** join/#brlcad mafm (~mafm@6.Red-81-37-119.dynamicIP.rima-tde.net)
11:56.53*** join/#brlcad ibot (~ibot@rikers.org)
11:56.53*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years...
12:11.46*** join/#brlcad Stattrav (~Stattrav@122.167.254.119)
12:11.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:32.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:58.25*** join/#brlcad mafm (~mafm@6.Red-81-37-119.dynamicIP.rima-tde.net)
15:51.09*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
16:47.36CIA-43BRL-CAD: 03starseeker * r42037 10/brlcad/branches/cmake/ (4 files in 4 dirs): Gah - per target defines didn't work so hot, revert to previous approach which special-cases src/adrt
16:50.24starseekerntosme2: we don't put things in system paths because it tends to result in conflicts with already installed stuff - simpler just to add /usr/brlcad/bin to your path
16:52.40starseekerbrlcad: is libtie viable as a src lib, or does it belong in a subdir somewhere?  (haven't synced trunk yet because I'm waiting for the dust to settle before reworking CMake logic for libtie/librender)
16:57.50CIA-43BRL-CAD: 03starseeker * r42038 10/brlcad/branches/cmake/src/other/openNURBS/CMakeLists.txt: Shouldn't need the opennurbs-static target with Visual C++, unless I'm missing something.
17:39.58CIA-43BRL-CAD: 03starseeker * r42039 10/brlcad/branches/cmake/CMakeLists.txt:
17:39.59CIA-43BRL-CAD: Try adding nologo to some more variables, although I'm not sure these will have
17:39.59CIA-43BRL-CAD: much/any impact - the most annoying one currently is the Resource Compiler,
17:40.00CIA-43BRL-CAD: which cannot be suppressed:
17:40.00CIA-43BRL-CAD: http://social.msdn.microsoft.com/Forums/en/windowssdk/thread/88bd1f52-af7d-4aa7-982a-f8798b32288d
17:46.07brlcadstarseeker: not sure what you're asking
17:46.39brlcad"yes"?
18:01.39starseeker``Erik moved libtie to src as a toplevel library
18:01.48starseekerwe weren't sure whether that was "toplevel" worthy
18:10.11CIA-43BRL-CAD: 03starseeker * r42040 10/brlcad/branches/cmake/src/other/ (tcl/CMakeLists.txt tk/CMakeLists.txt): Update version to 8.5.9, also don't compile the manifest file for wish (causes errors, not sure what precisely is going on - may need some special foo for user-supplied rc file)
18:11.39starseeker``Erik: somewhat to my surprise, I seem to have a build of both libtie and librender here from CMake
18:12.32brlcadmerged as an implementation library for librt, it should either be in src or a subdir under librt
20:13.53*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
20:26.31CIA-43BRL-CAD: 03starseeker * r42041 10/brlcad/branches/cmake/include/CMakeLists.txt: opennurbs_ext.h isn't in include anymore.
20:27.03brlcadstarseeker: the one thing that comes to mind, though, is that tie.h was NOT set up as a public interface header
20:27.19brlcadif it's going to live in include/ it really should be, especially since it's a new header
20:28.19brlcadthe other headers have heritage excuse, it's a "new" library so it really doesn't have any excuse for having private macros, types, hacks and such in its public header
20:29.18brlcadmaybe separate the private stuff in tie.h out into src/libtie/tieprivate.h
IRC log for #brlcad on 20110109

IRC log for #brlcad on 20110109

00:58.11*** join/#brlcad ibot (ibot@rikers.org)
00:58.11*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years...
01:02.42*** join/#brlcad crazy_imp (~mj@a89-182-211-75.net-htp.de)
01:53.50starseekergrowls... something about Tk isn't set up right
01:54.13starseekergonna have to dig back into the build logic for that - I can't even package require it
01:58.06starseekerhmm... that could be a problem, I never added pkgIndex logic for Tk itself (turns mildly red)
01:58.32starseekerstill not quite sure why bwish wouldn't start, but that explains some things...
06:13.57*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
06:13.57*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
09:14.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:47.20*** join/#brlcad mafm (~mafm@65.Red-79-159-0.staticIP.rima-tde.net)
12:46.30*** join/#brlcad Dweezahr (~Dweezahr@flits102-34.flits.rug.nl)
13:57.25CIA-43BRL-CAD: 03starseeker * r42042 10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: This may not do it for Windows, but make a stab at pkgIndex logic for Tk
14:00.14starseekerhas a feeling the ordering of auto_path may be an issue - it MIGHT explain why I keep getting interference from system installs of Tcl/Tk
14:05.49starseekerwonders why he did have a pkgIndex.tcl for tk in /usr/brlcad... left over maybe?
14:05.52starseekerweird
14:12.41starseekerhmm - "On the mac we build both X11 and Aqua versions of our gui tools such that
14:12.41starseekerif you rsh/ssh in and set your display you get X11 and it just works,
14:12.43starseekerotherwise you get Aqua."
14:12.59starseekerthat's an interesting approach - one that hadn't occurred to me
14:17.02CIA-43BRL-CAD: 03starseeker * r42043 10/brlcad/branches/cmake/src/util/bwcrop.c: compiler warning about comparing types - cast abs to size_t
14:27.06starseekertries to see what other damage might have been done by his FindTCL changes...
15:15.25*** join/#brlcad mafm (~mafm@65.Red-79-159-0.staticIP.rima-tde.net)
15:19.32*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
15:22.03CIA-43BRL-CAD: 03starseeker * r42044 10/brlcad/branches/cmake/ (56 files in 56 dirs): Try to clean up the mess left by FindTCL changes... this appears to build on Gentoo, but needs more testing.
15:53.58CIA-43BRL-CAD: 03starseeker * r42045 10/brlcad/branches/cmake/src/other/tk/library/CMakeLists.txt: add new spinbox.tcl file
15:56.14CIA-43BRL-CAD: 03starseeker * r42046 10/brlcad/branches/cmake/src/tclscripts/mged/CMakeLists.txt: Add man.tcl to CMakeLists.txt
16:04.49CIA-43BRL-CAD: 03starseeker * r42047 10/brlcad/branches/cmake/src/other/libpng/CMakeLists.txt: Sigh - need a mod to libpng's CMakeLists.txt file to account for CMAKE_LIBRARY_OUTPUT_DIRECTORY and CMAKE_ARCHIVE_OUTPUT_DIRECTORY being set. Have emailed upstream to see what their take is.
16:44.53*** join/#brlcad crazy_imp (~mj@a89-182-211-75.net-htp.de)
16:50.32CIA-43BRL-CAD: 03starseeker * r42048 10/brlcad/branches/cmake/src/other/libpng/CMakeLists.txt: And one more libpng tweak - another issue that only showed up on the install attempt.
17:29.57CIA-43BRL-CAD: 03starseeker * r42049 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Append tkstub to the list rather than resetting it
17:47.04starseekergrowl.  Still some problem with tk on Windows - will have to examine our Tk build and the nmake logic tomorrow
17:48.08``Erikwindows is ... special
20:37.17*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
22:34.51*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
23:24.24CIA-43BRL-CAD: 03brlcad * r42050 10/brlcad/trunk/ (12 files in 6 dirs): expand all BoT processing from using ints to using size_t for face/vertex/normal indices and counter variables.
IRC log for #brlcad on 20110110

IRC log for #brlcad on 20110110

00:13.08CIA-43BRL-CAD: 03starseeker * r42051 10/brlcad/branches/cmake/doc/docbook/system/mann/en/CMakeLists.txt:
00:13.08CIA-43BRL-CAD: Start prototyping a system to use the GLOB feature of CMake to test whether our
00:13.09CIA-43BRL-CAD: lists of files are complete - may be able to work out an EXTRA_DIST like
00:13.20CIA-43BRL-CAD: feature, although this should probably only be run when a specific target is
00:13.20CIA-43BRL-CAD: called and needs to handle all the various directories... may or may not be
00:13.20CIA-43BRL-CAD: worth it, we could just do a clean svn checkout prior to packaging up for
00:13.21CIA-43BRL-CAD: distribution.
00:13.40brlcadmid-building here, update with caution (may break build)
00:28.17starseekerbrlcad: np - been putting off a sync to tree
00:28.45starseekerjust trying to decide whether I have to attempt implementation of an EXTRA_DIST-like mechanism
00:34.00starseekerwhat I've done now is a little more specific - it haults the makefile generation if it spots a stray xml file not added to the CMakeLists.txt list - intended to catch man pages added to repository but not to build logic
00:38.01starseekerassuming I can coax the build into a state where a full build of BRL-CAD leaves a pristine source tree behind if built out-of-dir, would that alleviate the need for the EXTRA_DIST stuff?
00:50.58DX^I posted a bug about IGES a long while ago
00:51.03DX^but I don't think anyone cares any more :)
00:55.20brlcadDX^: caring doesn't imply time available, or more specifically mean that it'll get fixed quickly
00:55.58brlcadmoreover, there's been literally months of time and effort going into that particular problem
01:02.46*** join/#brlcad crazy_imp (~mj@a89-183-80-79.net-htp.de)
04:38.44*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
06:57.37*** join/#brlcad Stattrav (~Stattrav@122.172.16.143)
06:57.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:16.13*** join/#brlcad mafm (~mafm@231.Red-83-38-34.dynamicIP.rima-tde.net)
11:12.04CIA-43BRL-CAD: 03davidloman * r42052 10/rt^3/trunk/HACKING: Fixt up some Engrish issues in Hacking.
11:34.34*** join/#brlcad mafm (~mafm@231.Red-83-38-34.dynamicIP.rima-tde.net)
12:08.43*** join/#brlcad Stattrav (~Stattrav@122.172.16.143)
12:08.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:40.59*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
15:22.56*** join/#brlcad merzo (~merzo@193.254.217.44)
15:24.31*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
15:28.23CIA-43BRL-CAD: 03d_rossberg * r42053 10/rt^3/trunk/src/coreInterface/Arb8.cpp: the VAPPROXEQUAL() macro was renamed to VNEAR_EQUAL(), so it was changed here too
15:30.36CIA-43BRL-CAD: 03d_rossberg * r42054 10/brlcad/trunk/ (2 files in 2 dirs):
15:30.36CIA-43BRL-CAD: libz is called zlib now
15:30.37CIA-43BRL-CAD: (and opennurbs_ext.h a private header)
15:42.11CIA-43BRL-CAD: 03d_rossberg * r42055 10/brlcad/trunk/src/conv/iges/brlcad_brep.cpp: another case of pullback_curve() usage and therefore opennurbs_ext.h include
15:43.21CIA-43BRL-CAD: 03d_rossberg * r42056 10/brlcad/trunk/src/libbn/CMakeLists.txt: there is no screengrab.c in libbn
15:48.53CIA-43BRL-CAD: 03d_rossberg * r42057 10/brlcad/trunk/src/libbu/CMakeLists.txt:
15:48.53CIA-43BRL-CAD: synced with Makefile.am (timer.c)
15:48.54CIA-43BRL-CAD: compiles fine with MSVC 2008
16:11.57CIA-43BRL-CAD: 03d_rossberg * r42058 10/brlcad/trunk/src/other/libz/CMakeLists.txt:
16:11.57CIA-43BRL-CAD: the zconf.h has to lie in the same directory as zlib.h no matter where the binaries are build to be visible by the other libraries
16:11.58CIA-43BRL-CAD: the original CMakeLists.txt makes sense for a standalone project but causes problems as a sub-project configuration in larger programs
16:11.58CIA-43BRL-CAD: (nevertheless it's a good starting point)
16:18.09starseekerd_rossberg: I don't think we want to alter the libz CMakeLists.txt if we can help it
16:18.58starseekerd_rossberg: I'm using the vanilla file in the cmake branch with one tweak for MAN pages and it works fine - the trick is to include_directories both the source and the binary dirs to get both zlib.h and zconf.h (unless I'm missing something)
16:19.38starseekerI do that in a lot of places - my goal is to have a complete BRL-CAD build take place without the build process altering the source tree in any way
16:20.08starseekerI'm pretty close - the main issue is a tcl script that insists on generating files in src - I need to provide it with an output dir target
16:26.57d_rossbergstarseeker: i'm afraid zlib's CMakeLists.txt has to be modified anyway, either as i did or it has to export its include directories
16:27.31starseekerbut if you're doing a subproject, you know where both its src dir and its build dir are?
16:28.06starseekerI'm building openNURBS in the cmake branch successfully...
16:29.00d_rossbergi don't want to guess where zlib's include files could be all around
16:29.38starseekerthat's just it - you don't.  There are only two possibilities
16:29.48starseekerif you include both, you should be good
16:30.33d_rossbergi don't even know where zlibs binary directory is (in other libs than zlib)
16:31.51starseekerah - that's probably my THIRD_PARTY_SUBDIR macro
16:33.15d_rossbergno, the is cmake 2.6 (?) standard behavior
16:33.47starseekeryeah, you're right that the default behavior works that way
16:34.10starseekerbut we have a macro in misc/CMake in the cmake branch that lets us avoid those issues
16:34.26starseekerhave you tried the cmake branch lately?
16:35.01d_rossbergno, today is my first day back in the office
16:35.04d_rossbergwe can talk about it tomorrow, i've to catch my bus ;)
16:35.09starseekercool
16:35.38d_rossberg... i'll try the cmake branch later ...
17:04.42CIA-43BRL-CAD: 03starseeker * r42059 10/brlcad/branches/cmake/src/other/ (6 files in 6 dirs): Generalize the logic for writing out pkgIndex files
17:07.19brlcadgone way down the rabbit hole with these latest size_t changes.. so much stuff!
19:27.23*** join/#brlcad Ralith (~ralith@d142-058-093-144.wireless.sfu.ca)
19:48.19CIA-43BRL-CAD: 03starseeker * r42060 10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: Hmm - put the stubs line inside quotes, and just tclstub on Win32...
19:48.41*** join/#brlcad Ralith (~ralith@d142-058-093-144.wireless.sfu.ca)
20:14.23starseekerWOOOOT
20:14.57starseekerfirst successful run of MGED on Windows from a CMake build
20:15.48brlcadcongratulations
20:18.45*** join/#brlcad Ralith (~ralith@d142-058-093-144.wireless.sfu.ca)
20:24.27CIA-43BRL-CAD: 03brlcad * r42061 10/brlcad/trunk/ (24 files in 7 dirs):
20:24.27CIA-43BRL-CAD: revert libtie migration until the problems are fixed. there was no build logic
20:24.28CIA-43BRL-CAD: in src/libtie/ (so the build was broken) and the tie.h header included private
20:24.28CIA-43BRL-CAD: implementation details not appropriate for promotion into the include/
20:24.29CIA-43BRL-CAD: directory. this reverts the remaining portion of commit r42032 not already
20:24.29CIA-43BRL-CAD: reverted by r42035.
21:29.12CIA-43BRL-CAD: 03johnranderson * r42062 10/brlcad/trunk/src/conv/asc/asc2g.c:
21:29.14CIA-43BRL-CAD: Now accepts initial comments at start of file
21:29.15CIA-43BRL-CAD: First non-comment non-blank line must still be a "title" or "put" command,
21:29.25brlcadwoot
21:47.35CIA-43BRL-CAD: 03starseeker * r42063 10/brlcad/branches/cmake/src/other/tkhtml/CMakeLists.txt: Tweak building of tkhtml for Windows
22:56.41*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
23:03.18CIA-43BRL-CAD: 03starseeker * r42064 10/brlcad/branches/cmake/CMakeLists.txt: Start setting up logic for CPack. Start slowly - this is just the tar.gz, tar.bz2 and .zip files, to match what make distcheck produces (that will need to be confirmed).
23:36.40CIA-43BRL-CAD: 03starseeker * r42065 10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt:
23:36.41CIA-43BRL-CAD: Try moving the generated script files into the bin dir - this should, in theory,
23:36.41CIA-43BRL-CAD: be the last thing that was writing back to the source tree during build. Will
23:36.42CIA-43BRL-CAD: need to try in an svn or git repository with no ignore settings.
23:51.17starseekerwoo-hoo, that looks like it may be it - untarred one of the cpack tarballs, built using the untarred result as the src dir, untarred again into another dir, and a diff -r of the two directories reported no differences
IRC log for #brlcad on 20110111

IRC log for #brlcad on 20110111

01:02.11*** join/#brlcad crazy_imp (~mj@a89-182-209-17.net-htp.de)
02:02.12*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
03:21.19*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
03:23.26*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
03:23.34*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
03:27.42*** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net)
03:37.23*** join/#brlcad Dweezahr (~Dweezahr@flits102-34.flits.rug.nl)
03:37.23*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
03:37.23*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
03:37.23*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
03:37.23*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
03:37.23*** join/#brlcad DaveLo (~claymore@BZ.BZFLAG.BZ)
05:08.07starseekerfinally finds a workable way to splice multiple videos into one and convert them to mpeg2
05:14.24*** join/#brlcad Stattrav (~Stattrav@122.172.16.143)
05:14.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:00.10CIA-43BRL-CAD: 03brlcad * r42066 10/brlcad/trunk/src/mged/Makefile.am: the bot face/normal arrays should probably be reverted back to integers, but turn off strict in here in the meantime to fix the build.
06:31.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:33.32CIA-43BRL-CAD: 03brlcad * r42067 10/brlcad/trunk/ (20 files in 9 dirs): more size_t cascading. put the type to use throughout much of libbn and most caller code. other code affected was sketch object code, vertex and curve counts.
07:45.31*** join/#brlcad ibot (~ibot@rikers.org)
07:45.31*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years...
07:52.55CIA-43BRL-CAD: 03brlcad * r42068 10/brlcad/trunk/src/conv/asc/ (asc2g.c g2asc.c): isspace() needs ctype.h
08:19.04CIA-43BRL-CAD: 03brlcad * r42069 10/brlcad/trunk/src/librt/primitives/ (extrude/extrude.c nmg/nmg_misc.c): size_t quellage
08:33.45CIA-43BRL-CAD: 03brlcad * r42070 10/brlcad/trunk/ (23 files in 11 dirs):
08:33.46CIA-43BRL-CAD: revert the conversion of the bot face/vertex/normal arrays from being size_t
08:33.46CIA-43BRL-CAD: back to int. additionally, convert the remainder of bot struct size types over
08:33.47CIA-43BRL-CAD: to size_t completely. this propagates hundreds of ancillary changes (more than
08:33.47CIA-43BRL-CAD: 400) but provides the added benefits of more extensive value range on some
08:33.53CIA-43BRL-CAD: platforms, better warning/bug detection, and more consistently making size types
08:33.53CIA-43BRL-CAD: be unsigned so no negative values is inherent.
08:33.53CIA-43BRL-CAD: 03brlcad * r42071 10/brlcad/trunk/src/libged/bot_merge.c: quellage, use size_t
08:33.56CIA-43BRL-CAD: 03brlcad * r42072 10/brlcad/trunk/src/libged/bot.c: use EQUAL() for exact floating point comparison
08:49.45CIA-43BRL-CAD: 03brlcad * r42073 10/brlcad/trunk/src/mged/ (animedit.c chgtree.c edars.c edsol.c titles.c usepen.c): more size_t quellage
10:44.09*** join/#brlcad Stattrav (~Stattrav@117.192.240.10)
10:44.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:46.42*** join/#brlcad mafm (~mafm@134.Red-83-35-148.dynamicIP.rima-tde.net)
11:29.24*** join/#brlcad Stattrav (~Stattrav@122.172.16.143)
11:29.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:48.46*** join/#brlcad Stattrav (~Stattrav@122.172.16.143)
11:48.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:52.46*** join/#brlcad Axman6_ (~Axman6@pdpc/supporter/student/Axman6)
12:09.44*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:27.16*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:47.31starseekerd_rossberg: any luck with the cmake branch?
14:12.34d_rossbergstarseeker: i'm still looking for a way to set the install directory
14:13.36*** join/#brlcad AlecTaylor (~Tauk@unaffiliated/alectaylor)
14:13.37AlecTaylorhi
14:16.50AlecTaylorHow do I create this http://i55.tinypic.com/1606amg.jpg in BRL-CAD?
14:48.34starseekerd_rossberg: install directory?  BRLCAD_PREFIX may be what you want
14:49.26starseekerAlecTaylor: the sketch, or a 3D object?
14:53.27d_rossbergstarseeker: but BRLCAD_PREFIX isn't present in the cmake gui
14:54.48d_rossbergi could probable add it, however it is an important value which should be there
14:55.19starseekerum...
14:56.15starseekerweird
14:56.29starseekeri've been using CMake from the command line...
14:56.38starseekerI see it isn't there, one second...
15:01.08CIA-43BRL-CAD: 03starseeker * r42074 10/brlcad/branches/cmake/CMakeLists.txt: Make a stab at getting BRLCAD_PREFIX displayed in the CMake gui
15:01.43starseekersee if that helps - I've been using cmake almost exclusively from the command line, so there are probably other tweaks needed to clean up the gui presentation
15:02.26starseekerincidently, there is a known limitation right now about spaces in pathnames - they will almost certainly cause failures with the Tcl/Tk build
15:02.41starseekerI'm working on that, but it's not fixed yet
15:03.30starseekerreflects that should probably be renamed to BRLCAD_INSTALL_PREFIX...
15:05.01d_rossbergi'll have a look at it as soon as the compile jobs ended
15:05.09starseekerno problem :-)
15:05.32starseekerwhich platform are you building on?
15:06.51AlecTaylorstarseeker: 3D object
15:07.12starseekerI'd use a series of cylinders
15:07.23starseekerare you new to BRL-CAD?
15:07.33AlecTaylorstarseeker: Here's the top view http://i56.tinypic.com/24bklds.jpg
15:07.43AlecTaylorstarseeker: Never used it before
15:08.18starseekerAlecTaylor: ah, then you'll want to start with this:  http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf
15:09.08starseekerthat object looks pretty straightforward, so you should be able to do it with the techniques described in that tutorial
15:09.34d_rossbergstarseeker: MS Windows XP (32bit) with MSVS 2008
15:09.47starseekerwinces - ah, the toughest platform
15:24.56CIA-43BRL-CAD: 03erikgreenwald * r42075 10/brlcad/trunk/src/adrt/ (5 files in 2 dirs): new tieprivate.h, clean up of tie.h
15:27.17CIA-43BRL-CAD: 03erikgreenwald * r42076 10/brlcad/trunk/src/adrt/Makefile.am: add STRICT_FLAGS
15:31.33AlecTaylorstarseeker: How long will it take (about) to learn how to do it, then to create it?
15:31.50AlecTaylorwon't be able to work on it after tonight, and it's 2:30am already
15:32.17brlcadAlecTaylor: there have been new users / students that have gotten through all of the mged tutorials in just a couple hours
15:32.51brlcadyou won't be very good, but you should be able to make a model as simple as the one you sketched in under an hour once you have the basics
15:33.29brlcadthe hardest part is usually learning all of the various modeling commands, learning how to use them
15:33.51AlecTaylorhmm
15:34.00brlcadsomeone proficient in mged could probably make that model in less than 10 minutes
15:34.15AlecTaylorbrlcad: 10 minutes?
15:34.20brlcadless than
15:35.11CIA-43BRL-CAD: 03erikgreenwald * r42077 10/brlcad/trunk/src/adrt/libtie/ (tie.c tieprivate.h): Move the win32 near/far fix to the right place
15:35.27AlecTayloris a volunteer putting in 8 hours a day, 6 days a week for a robotics competetion [mentoring]. Would you be able to do me a [massive] favour by modelling it for me?
15:35.31AlecTaylorbrlcad^
15:35.38brlcadonce you climb the steep learning curve, you can be just as efficient as you'd be in other CAD/modeling systems
15:37.07AlecTaylorbrlcad: I'll read the entire guide + more in a week, I just need something working [literally in the next little while; as I'm going in for surgery tomorrow and want to show my students my Robot design in CAD]
15:37.26brlcadAlecTaylor: heh, sorry ... I put a lot of volunteer time into BRL-CAD as it is; my skills are better put to use doing software development
15:37.50AlecTaylorSame, that's my area of expertise!
15:37.57AlecTaylorSwap for 10mins? :P
15:38.25AlecTayloris an avid C++ programmer and enthusiast, everything from Qt to Wt and CLI!
15:38.30brlcadit wouldn't be 10 minutes for *me* .. I'm certainly not a proficient modeler :)
15:38.48AlecTaylorI see! :)
15:39.43brlcadyou know, if you're just showing off a design, you might have better luck quickly whipping up something in sketchup
15:40.00brlcadit'd be crappy for CAD purposes, but it'd showcase your design in 3D
15:48.17CIA-43BRL-CAD: 03erikgreenwald * r42078 10/brlcad/trunk/src/adrt/librender/ (13 files): const propogation
15:51.27AlecTaylorbrlcad: ended up just showing them something I wrote in Blender [the stand for the telescope] and the aforementioned side-view and top-view mockups
15:52.15AlecTaylorThanks though
15:53.20brlcadAlecTaylor: if you hang around, someone might be willing to help you out
16:04.45CIA-43BRL-CAD: 03starseeker * r42079 10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: Don't cram two commands on one line - make use of CMake's support for multiple COMMAND lines executed in order.
16:04.55d_rossbergstarseeker: it looks like there is a clean-up somewhere in the cmake build which makes looking for errors uncomfortable
16:05.07CIA-43BRL-CAD: 03brlcad * r42080 10/brlcad/trunk/TODO: cp command should take multiple copy names
16:05.18starseekerd_rossberg: what do you mean?
16:07.24d_rossbergi'm using the batch build in VS, there i got 3 errors, then i started the batch build again to see these errors but it started to compile the successfull builds too
16:09.32starseekerhmm
16:10.15starseekerI'm seeing a few errors on my first pass, but I'm not sure what those are because my second pass comes up clean
16:10.23starseekernot sure why it's rebuilding everything
16:10.36starseekeryou're using the ALL_BUILD target?
16:13.39d_rossbergALL_BUILD and INSTALL are switched off
16:21.25brlcadtoo bad AlecTaylor wasn't more patient, http://brlcad.org/tmp/stand.png
16:21.58brlcadhalf hour, not too shabby but I still suck
16:22.16*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
16:22.53starseekerd_rossberg: um...
16:23.08starseekermaybe I'd better write up how I'm building so we can compare notes
16:24.22d_rossbergstarseeker: don't worry, i've completely different problems at the moment ;)
16:28.40starseekerd_rossberg: with the cmake branch or other stuff?
16:29.21d_rossbergwith other stuff
17:31.40CIA-43BRL-CAD: 03brlcad * r42081 10/brlcad/trunk/src/libged/ (38 files): massive quantities of quellage. size_t upgrades, unused params, exact floating point comaprisons, and more. 300+ fixes. oh my.
17:33.15*** join/#brlcad mafm_ (~mafm@134.Red-83-35-148.dynamicIP.rima-tde.net)
17:38.53CIA-43BRL-CAD: 03starseeker * r42082 10/brlcad/branches/cmake/CMakeLists.txt:
17:38.53CIA-43BRL-CAD: Take the first steps to 'properly' handle CMAKE_INSTALL_PREFIX and the issue of
17:38.54CIA-43BRL-CAD: find_package searching in it when cmake is re-run. Don't really want to
17:38.54CIA-43BRL-CAD: manhandle CMAKE_INSTALL_PREFIX any more than we have to, so try this.
18:01.41DX^I hate modeling
18:01.45DX^thank god for CAD operators
18:26.21CIA-43BRL-CAD: 03starseeker * r42083 10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: Try explicit copy and remove steps - apparently rename causes some issue with NFS, let's see if it's specific to rename
18:36.44CIA-43BRL-CAD: 03starseeker * r42084 10/brlcad/branches/cmake/ (4 files in 4 dirs): Try to migrate more towards standard CMake variables - BRLCAD_PREFIX should now be only for the purposes of removal from find_package search paths.
19:01.22*** join/#brlcad merzo (~merzo@53-11-94-178.pool.ukrtel.net)
20:04.10*** join/#brlcad AlecTaylor (~Tauk@unaffiliated/alectaylor)
20:11.51brlcadAlecTaylor: welcome back
20:12.24brlcadAlecTaylor: if you'd waited 10 more minutes, I had this up right after you left: http://brlcad.org/tmp/stand.png
20:42.44*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
20:50.29AlecTaylorbrlcad: Perfect!
20:50.30AlecTaylorThanks
20:55.03AlecTaylorhas never been happier about setting up his auto-connect!
20:55.32AlecTaylorbrlcad: Would you be able to share the actual CAD file?
21:20.47CIA-43BRL-CAD: 03brlcad * r42085 10/brlcad/trunk/src/conv/g-xxx.c:
21:20.47CIA-43BRL-CAD: refactor the example converter to leave all of the more advanced and deprecated
21:20.48CIA-43BRL-CAD: primitives as an exercise to the reader since we don't actually do anything with
21:20.48CIA-43BRL-CAD: the object variables pulled from the idb_ptr. quell remaining warnings too.
21:21.06brlcadAlecTaylor: it's in that same directory
21:22.03brlcadAlecTaylor: and a word of caution, I didn't really use any best practices or structure the geometry in any way, just made a shape approximation to your sketch
21:23.08CIA-43BRL-CAD: 03brlcad * r42086 10/brlcad/trunk/src/librt/db_path.c: off_t's may be signed, accommodate.
21:26.37CIA-43BRL-CAD: 03erikgreenwald * r42087 10/brlcad/trunk/src/adrt/ (38 files in 3 dirs): favor direct struct use instead of hiding them behind a typedef.
21:38.02CIA-43BRL-CAD: 03brlcad * r42088 10/brlcad/trunk/ (3 files in 2 dirs): make ars parameters be unsigned size_t types as well.
21:38.51CIA-43BRL-CAD: 03brlcad * r42089 10/brlcad/trunk/src/adrt/libtie/tie.c: eliminate exact floating point comaprison
21:39.12CIA-43BRL-CAD: 03brlcad * r42090 10/brlcad/trunk/src/adrt/libtie/tie_kdtree.c: quell warnings on 'index' and undefined preprocs.
22:15.40CIA-43BRL-CAD: 03brlcad * r42091 10/brlcad/trunk/src/adrt/adrt.h: unused variables, dunno if safe to remove
22:15.58CIA-43BRL-CAD: 03brlcad * r42092 10/brlcad/trunk/src/adrt/librender/render_internal.h: remove trailing semi so uses have to have semi. quiets warnings about ISO C not allowing floating semis outside of functions.
22:17.37CIA-43BRL-CAD: 03brlcad * r42093 10/brlcad/trunk/src/adrt/load.c: static init no-go
22:18.24CIA-43BRL-CAD: 03brlcad * r42094 10/brlcad/trunk/src/adrt/ (load.h load_g.c): remove unused dlen param, mark other unused params.
22:32.42CIA-43BRL-CAD: 03brlcad * r42095 10/brlcad/trunk/src/adrt/librender/camera.c:
22:32.43CIA-43BRL-CAD: ouch, tricky one. ISO C doesn't actually permit dlsym() to work the way it
22:32.43CIA-43BRL-CAD: works with the need to convert a void* to a function pointer so the compiler has
22:32.44CIA-43BRL-CAD: to be cajouled. we trick it with a cast through an intptr_t, which is a type
22:32.44CIA-43BRL-CAD: big enough to hold a pointer address, albeit not necessarily a function pointer.
22:32.45CIA-43BRL-CAD: the rest of the changes are just consistency with the callback mechanism type
22:32.45CIA-43BRL-CAD: returning an int and constness.
22:33.15``Erik_ffffu
22:38.04CIA-43BRL-CAD: 03erikgreenwald * r42096 10/brlcad/trunk/src/adrt/ (30 files in 3 dirs): major migration to use significantly more vmath types/macros
22:42.44brlcad``Erik: heh, hope that's not causing too much grief
22:42.56``Erika few conflicts
22:43.03brlcadyou enabled strict in there, so my build's busted -- it was either fix em or turn it back off
22:44.21``Erikhm, which compiler? it works for me on fbsd (gcc4.2.1), linux (gcc4.1.2, mac (gcc4.2.1) and win32(msvc80
22:44.25``Eriks/0$/)/
22:45.01``Erikanyways, I think I'm done with it for the night, all committed up O.o
22:45.11brlcadhermes is failing
22:45.50brlcadgcc 4.1.2 linux
22:46.04brlcadmaybe you didn't --enable-warnings (goes hand-in-hand with STRICT_FLAGS)
22:53.14CIA-43BRL-CAD: 03brlcad * r42097 10/brlcad/trunk/src/adrt/ (13 files in 2 dirs): mark a bunch of unused params
22:55.56brlcadlooks like your only parially done with the migration?  the render work() function takes a TIE_3* but you're passing it vect_t* (camera.c:511)
23:05.30CIA-43BRL-CAD: 03brlcad * r42098 10/brlcad/trunk/src/adrt/Makefile.am: looks like just few warnings remaining (be sure to --enable-warnings), about 65 on 64-bit linux, but saving them for later to minimize conflict. remove strict_flags in the meantime.
23:18.36brlcadnow you'll get 'em
23:18.57CIA-43BRL-CAD: 03brlcad * r42099 10/brlcad/trunk/configure.ac:
23:18.58CIA-43BRL-CAD: now that more than 2/3rds of the package compiles completely free of warnings,
23:18.58CIA-43BRL-CAD: go ahead and make verbose warnings the default. fully sync the warning flags
23:18.59CIA-43BRL-CAD: with strict so if strict is enabled, you're getting everything that
23:18.59CIA-43BRL-CAD: --enable-warnings was providing along with -Werror.
23:25.12CIA-43BRL-CAD: 03brlcad * r42100 10/brlcad/trunk/src/conv/ (24 files in 9 dirs):
23:25.13CIA-43BRL-CAD: this huge update represents the remainder compilation quieting of all the
23:25.13CIA-43BRL-CAD: converters. missing params, exact floating point comparisons, shadowed
23:25.38CIA-43BRL-CAD: variables, unused params, long string literals, signedness mismatching, size_t
23:25.38CIA-43BRL-CAD: updates and more so that STRICT_BUILD works clean (on Mac gcc 4.0.1). several
23:25.38CIA-43BRL-CAD: days to complete, more than 1300 (minor) changes.
23:45.29``Erikhm, I had the flags in the compile lines, odd *shrug* I'll dig into it some more tomorrow
23:47.44CIA-43BRL-CAD: 03brlcad * r42101 10/brlcad/trunk/src/other/openNURBS/ (7 files):
23:47.44CIA-43BRL-CAD: the ON_OBJECT_IMPLEMENT() and ON_VIRTUAL_OBJECT_IMPLEMENT() macros are followed
23:47.45CIA-43BRL-CAD: in code with semicolons so the macro itself needs to end with a statement that
23:47.45CIA-43BRL-CAD: requires a semicolon. a simple reordering of the first line suffices.
23:47.46CIA-43BRL-CAD: remainder of fixes are stray semicolons mysteriously following functions.
IRC log for #brlcad on 20110112

IRC log for #brlcad on 20110112

00:06.04CIA-43BRL-CAD: 03johnranderson * r42102 10/brlcad/trunk/src/libbu/simd.c: Since we are using -Wundef option, we must use defined( __SSE__ )
00:32.49CIA-43BRL-CAD: 03brlcad * r42103 10/brlcad/trunk/src/libbn/bntester.c: init vars. potential for function_num and test_case_line_num to be accessed without initialization
00:33.08CIA-43BRL-CAD: 03brlcad * r42104 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: trailing comma at end of enumerator list makes gcc unhappy
00:33.59brlcad``Erik: --enable-warnings (before r42099) had two or three extra warnings that weren't enabled by default
00:45.23CIA-43BRL-CAD: 03brlcad * r42105 10/brlcad/trunk/src/libbn/bntester.c: (log message trimmed)
00:45.24CIA-43BRL-CAD: this is a really tricky one. quell warnings about variables getting clobbered
00:45.24CIA-43BRL-CAD: after a longjmp or vfork by making them all static. we can do this here because
00:45.50CIA-43BRL-CAD: they're all just main() variables fortunately. bu's jump mechanism uses
00:45.51CIA-43BRL-CAD: setjump, so an implementation could clobber local non-static non-volatile
00:45.51CIA-43BRL-CAD: variables. this tricking making them static works or it would have also worked
00:45.51CIA-43BRL-CAD: to wrap the BU_SETJUMP/BU_UNSETJUMP calls into functions that are passed
00:59.50CIA-43BRL-CAD: 03brlcad * r42107 10/brlcad/trunk/src/libbu/simd.c: no guarantee that __GNUC__ will be defined either.
00:59.52CIA-43BRL-CAD: 03brlcad * r42106 10/brlcad/trunk/src/conv/ (3 files in 2 dirs):
00:59.53CIA-43BRL-CAD: behold the annoyance of -pedantic. believe it or not, even for ISO C++,
00:59.54CIA-43BRL-CAD: variable sized arrays are but a mere gcc extension. if you want variable-sized,
00:59.55CIA-43BRL-CAD: you either have to new/delete/malloc/free (bleh) or leverage std::vector
00:59.56CIA-43BRL-CAD: templatization. the latter is fortunately a trivial declaration tweak and the
00:59.57CIA-43BRL-CAD: rest should behave accordingly.
00:59.59CIA-43BRL-CAD: 03starseeker * r42108 10/brlcad/branches/cmake/TODO.cmake: Sigh. Update the TODO list for CMake with more known items.
01:02.34*** join/#brlcad crazy_imp (~mj@a89-182-195-57.net-htp.de)
01:06.40CIA-43BRL-CAD: 03starseeker * r42109 10/brlcad/branches/cmake/CMakeLists.txt: Want to set to /usr/brlcad as default instead of the CMake default.
01:12.02CIA-43BRL-CAD: 03brlcad * r42110 10/brlcad/trunk/src/conv/iges/ (g-iges.c main.c usage.c): more string literals that are way too long. convert to usage() functions.
01:12.26CIA-43BRL-CAD: 03brlcad * r42111 10/brlcad/trunk/src/conv/comgeom/tools.c: curious one, untested.
01:13.56CIA-43BRL-CAD: 03brlcad * r42112 10/brlcad/trunk/src/vdeck/vdeck.c: more size_t
01:19.21CIA-43BRL-CAD: 03brlcad * r42113 10/brlcad/trunk/NEWS: john added support for comments as the first line(s) of a .asc file. previously was using title/units as keywords to recognize a .asc file, now it's the first non-comment line that has to have a title/units command.
01:27.21CIA-43BRL-CAD: 03starseeker * r42114 10/brlcad/branches/cmake/ (45 files in 45 dirs): Generalize the INSTALL_* variables - gives a parent project the chance to do its own setting, in principle, without having to use the BRLCAD specific variables. Not sure how useful it really is, but why not.
01:28.16CIA-43BRL-CAD: 03starseeker * r42115 10/brlcad/branches/cmake/TODO.cmake: reminder - need to rework SCL CMake logic
01:30.28CIA-43BRL-CAD: 03starseeker * r42116 10/brlcad/branches/cmake/src/libbu/CMakeLists.txt: Add timer.c to libbu CMakeLists.txt file
01:45.26CIA-43BRL-CAD: 03starseeker * r42117 10/brlcad/branches/cmake/src/tclscripts/ (hv3/pkgIndex.tcl hv3/tclIndex swidgets/scripts/tclIndex): Add back in some of the tclIndex and pkgIndex files - this should all go when CMake becomes mainline, but for now put them back to avoid difference with trunk.
01:46.27CIA-43BRL-CAD: 03brlcad * r42118 10/brlcad/trunk/ (6 files in 5 dirs):
01:46.28CIA-43BRL-CAD: differentiate BU_PTBL_LEN() from BU_PTBL_END() such that the prior is not a
01:46.28CIA-43BRL-CAD: valid lvalue. this makes it more appropriate for loop testing and can be an
01:46.29CIA-43BRL-CAD: unsigned type instead of the potentially signed off_t offset type of the
01:46.29CIA-43BRL-CAD: underlying struct member. update references accordingly.
01:48.48CIA-43BRL-CAD: 03starseeker * r42119 10/brlcad/branches/cmake/ (37 files in 14 dirs): Update cmake branch to trunk r42052. This is known to be a non-working CMake state, but this sync is being done in stages to avoid some conflicts from the trunk CMakeLists.txt files.
01:55.04CIA-43BRL-CAD: 03brlcad * r42120 10/brlcad/trunk/src/ (5 files in 4 dirs): more quieting of the compilation
01:58.46CIA-43BRL-CAD: 03starseeker * r42121 10/brlcad/branches/cmake/ (197 files in 44 dirs): Update cmake branch to trunk r42119
02:33.16CIA-43BRL-CAD: 03starseeker * r42122 10/brlcad/branches/cmake/ (7 files in 6 dirs): Update cmake branch to trunk r42120
02:58.06CIA-43BRL-CAD: 03starseeker * r42123 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Tweaks - seems to produces better results for make package.
03:12.51CIA-43BRL-CAD: 03starseeker * r42124 10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Add the deprecated Tcl/Tk vars into the handle-standard-args logic - they apparently aren't visible to other projects otherwise.
03:27.43CIA-43BRL-CAD: 03starseeker * r42125 10/brlcad/branches/cmake/TODO.cmake: Tweaks to settings seem to have CPack behaving better - need to study results a lot more, but at least the bin directory has more than a couple dozen binaries now.
03:29.07CIA-43BRL-CAD: 03brlcad * r42126 10/brlcad/trunk/src/conv/dxf/dxf-g.c: init vars before testing
03:33.24CIA-43BRL-CAD: 03brlcad * r42127 10/brlcad/trunk/src/conv/g-acad.c:
03:33.25CIA-43BRL-CAD: massive restructure in order to fix a bug assuming that variables are accessible
03:33.25CIA-43BRL-CAD: after a longjmp. quite a chore to quell the warning due to a bug in pre 4.3
03:33.26CIA-43BRL-CAD: gcc, but seems to be possible to quiet the warning if we start a new frame (and
03:33.26CIA-43BRL-CAD: don't access the var/arg after that call). some testing, seems to work.
03:33.55CIA-43BRL-CAD: 03brlcad * r42128 10/brlcad/trunk/src/conv/Makefile.am: not quite intentional to enable strict in here just yet. -pedantic is a bitch.
04:17.10CIA-43BRL-CAD: 03brlcad * r42129 10/brlcad/trunk/src/librt/primitives/bot/bot.c: off-by-one copypaste typo. 2, not k.
04:32.48CIA-43BRL-CAD: 03starseeker * r42130 10/brlcad/branches/cmake/CMakeLists.txt: Tweak generator list, vars for CPack
04:33.57CIA-43BRL-CAD: 03starseeker * r42131 10/brlcad/branches/cmake/src/other/ (tcl/doc/install_man.cmake.in tk/doc/install_man.cmake.in): the Tcl/Tk man page script was installing to CMAKE_INSTALL_DIR even during make package - make it respect DESTDIR if it's set.
04:56.43starseekerhmm... that won't do either, CPack ignores those man pages as not being from a target
05:03.26*** join/#brlcad Stattrav (~Stattrav@122.172.16.143)
05:03.32*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:29.12CIA-43BRL-CAD: 03starseeker * r42132 10/brlcad/branches/cmake/src/other/ (4 files in 2 dirs): Make another stab at the Tcl/Tk man pages, this time doing the generation up front and using FILE(GLOB to grab the results and put them into install targets.
05:35.57CIA-43BRL-CAD: 03starseeker * r42133 10/brlcad/branches/cmake/src/other/ (tcl/doc/CMakeLists.txt tk/doc/CMakeLists.txt):
05:35.58CIA-43BRL-CAD: Only do the generation once. If we really want to do this right we need some
05:35.59CIA-43BRL-CAD: kind of custom commands, targets, output files to signify completed commands,
05:35.59CIA-43BRL-CAD: etc - not worth it, and this avoids repeated processing we don't need.
05:50.14CIA-43BRL-CAD: 03starseeker * r42134 10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Tcl link workaround isn't working for make package - need to re-examine.
05:54.07CIA-43BRL-CAD: 03starseeker * r42135 10/brlcad/branches/cmake/src/other/tcl/doc/CMakeLists.txt: Arrrrgh - make package is still not grabbing these files. May have to go all out with custom commands and targets.
07:26.22*** join/#brlcad AlecTaylor (~Tauk@unaffiliated/alectaylor)
09:54.50*** join/#brlcad mafm_ (~mafm@166.Red-83-45-72.dynamicIP.rima-tde.net)
11:38.09DaveLoMernin! Anyone at work yet?
13:36.40CIA-43BRL-CAD: 03d_rossberg * r42136 10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: added bu_vls_trunc2() for asc2g conversion program
13:40.40starseekerhmm... KDE on Windows
13:41.06starseekeris intrigued, but hesitates to mess with his Windows partition too much because it would be hard to fix
13:46.02starseekerhuh - kinda looks like bzflag with some enhancements:  http://www.ubuntugamer.com/2011/01/zero-ballistics-a-rather-addictive-native-3d-tank-shooter/
13:51.15*** join/#brlcad mafm (~mafm@166.Red-83-45-72.dynamicIP.rima-tde.net)
13:52.13CIA-43BRL-CAD: 03starseeker * r42137 10/brlcad/branches/cmake/src/other/ (tcl/doc/CMakeLists.txt tk/doc/CMakeLists.txt): Ah, was shooting myself in the foot. We only GENERATE the man pages once, but we add them to the INSTALL list every time cmake is run.
14:04.21*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
14:15.09*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
14:36.21CIA-43BRL-CAD: 03starseeker * r42138 10/brlcad/branches/cmake/CMakeLists.txt:
14:36.22CIA-43BRL-CAD: Small change, but important for CPack packages - don't use absolute dirs as
14:36.22CIA-43BRL-CAD: targets for install, which allows CPack to put things in the package without
14:36.23CIA-43BRL-CAD: hard-coding the prefix (in essence building a subdirectory structure inside the
14:36.23CIA-43BRL-CAD: archive
14:55.59CIA-43BRL-CAD: 03starseeker * r42139 10/brlcad/branches/cmake/src/ (7 files in 7 dirs):
14:56.00CIA-43BRL-CAD: Strip out more absolute paths for installs. The src/other/step directory isn't
14:56.00CIA-43BRL-CAD: with the program yet, but that needs major cleanup anyway so leave it for now.
14:56.01CIA-43BRL-CAD: Probably shouldn't be hardcoding bin and lib in as DESTINATIONS, may want to do
14:56.01CIA-43BRL-CAD: a sweep for that too.
15:02.21brlcadstarseeker: have you looked at tom's crash?  have a question on tedit for you
15:03.17brlcadwhat's the intent around line 986 where it calls: editor = bu_which(EMACS_EDITOR); if (!strcmp(editor, bu_which(EMACS_EDITOR)) ...
15:03.54d_rossbergi could reproduce the crash, now i'm looking for a work-around
15:04.15brlcadd_rossberg: I have a simplistic fix for the crash that at least avoid strcmp()
15:05.53CIA-43BRL-CAD: 03brlcad * r42140 10/brlcad/trunk/src/mged/tedit.c:
15:05.54CIA-43BRL-CAD: strcmp() doesn't like NULL and bu_which() may produce NULL, so don't feed the
15:05.54CIA-43BRL-CAD: output of the latter directly into the prior. should at least avoid the
15:05.55CIA-43BRL-CAD: specific crash reported by tom browder to the devel mailing list, albeit
15:05.55CIA-43BRL-CAD: probably not the full fix needed.
15:09.27starseekerbrlcad: ah, thanks - I neglected to check if strcmp would handle null.  Looks like it's platform dependent, and therefore not to be relied on
15:11.03brlcadthere's not many stdc calls that can be trusted to accept null, even ones that are documented to accept null
15:11.17d_rossbergon  Windows strcmp(0) will crash
15:13.02CIA-43BRL-CAD: 03starseeker * r42141 10/brlcad/branches/cmake/src/archer/CMakeLists.txt: Archer's CMakeLists.txt file needs a lot of love to make it work in the build dir - these are just the first tweaks, lots more will be needed.
15:13.02starseekersigh
15:13.25starseekerlaunching an editor from C code really seems to be a pain
15:13.32brlcadI believe posix strcmp() is undefined if passed a null anyways, so crashing is acceptable behavior
15:13.45d_rossbergwhot do you think about a bu_strcmp()?
15:14.27brlcadyou mean adding one?
15:14.45d_rossbergyes
15:15.16starseekerd_rossberg: (bty - more to be done, but hopefully CMAKE_INSTALL_PREFIX will behave more normally now and you won't need BRLCAD_PREFIX anymore."
15:15.41starseekerleftover garbage from early in the learning process
15:15.44d_rossbergstrcmp() is really annoying
15:17.49starseekergets ready to head in...
15:17.56CIA-43BRL-CAD: 03starseeker * r42142 10/brlcad/branches/cmake/TODO.cmake: Add note about archer to TODO.cmake
15:18.08d_rossbergstarseeker: i've still the problem of huge rebuilds ...
15:21.25brlcadd_rossberg: bu_strcmp() and/or bu_strlcmp() would be good additions to make given there is already bu_str(lcat|lcpy|dup)
15:21.44brlcadstarseeker: any insight on that question?
15:22.15d_rossbergbrlcad: i'm already working on it
15:22.27starseekerbrlcad: the strcmp or the rebuilds?
15:22.35brlcadwhat's the intent around line 986 where it calls: editor = bu_which(EMACS_EDITOR); if (!strcmp(editor, bu_which(EMACS_EDITOR)) ...
15:22.46brlcadnow line 904 or something
15:23.18brlcadit sets editor to the path to emacs, then checks if editor is .. the path to emacs
15:23.33starseekerlooks...
15:24.16brlcadI added the "(editor &&" part just to check the result from bu_which .. wasn't there before
15:24.24brlcad*just* added it in the last commit
15:24.33brlcadd_rossberg: okay, cool
15:26.52starseekerI believe what was going on there was a check (once in classic mode) to see if any of the known editor configurations that would work in classic mode were viable
15:27.30brlcadI think I see that, but those two specific lines don't make sense to me
15:28.22starseekerum.
15:28.28starseekeryeah, not sure what was going on there
15:28.40starseekerthat strcmp does look kinda pointless
15:29.16starseekerI think you have the right answer
15:29.20brlcadwell what I'm reading is that IF you have emacs, then all of the other editor tests will fail
15:29.26brlcadwhich maybe was the intent
15:29.31d_rossbergbrlcad: there is no strlcmp
15:29.41brlcadd_rossberg: I meant to write one :)
15:30.13starseekerbrlcad: probably it was something like that
15:30.21brlcadwith similar intent of the strlcpy functions, strlcmp checks for null, maybe has a length specifier
15:30.33d_rossbergthere are strl*() functions for writing on buffers only
15:31.47brlcadokay
15:32.19brlcadfair enough, it was just a thought for consistency with our own bu functions, but matching the replacement is probably more important
15:32.44``Eriknow that's a lot of breakage
15:33.13starseekerbrlcad: I think I may have some rather convoluted logic there - I'm not sure what the whole idea was with the count thing
15:33.21brlcadI could see bu also providing a BU_STREQ() macro so that all of the equality testing could be simplified consistent
15:34.12brlcadstarseeker: yeah, that is pretty funky ... search for everything, then if you found anything, search for something
15:34.46starseekeroh, wait
15:35.11starseekerI think I might have been looking to see if a preset editor from above was a potential bad case for classic mode
15:35.43starseekerlooks at the previous revision of the code
15:36.05brlcadhm, maybe if(BU_EQUALS(str1, str2)) or if (BU_EQUAL_STR(str1, str2))
15:36.55starseekeryeah, that was it
15:36.57``Erikusing vls's?
15:37.07brlcadthere are approximately 1418 calls to strcmp() in the code
15:38.12starseekerbrlcad: the idea was to check the editor variable to spot cases which might be a problem, and if it WAS a problem case then force-feed it something known to be safe
15:38.58starseekerso it blew up due to the bu_which finding nothing to compare editor TO
15:39.17brlcadright
15:39.36brlcadso then my fix should, in theory, work and fall through correctly
15:39.38starseekerso your fix is actually correct
15:39.41starseekeryes :-)
15:39.59starseekershudders in memory - that was a long night sorting all that logic out
15:41.08brlcadthose first two lines inside the if (count > 0) block still don't make sense though
15:41.39brlcadbecause editor = bu_which(EMACS_EDITOR) will have unlikely changed between the first and second lines.. :)
15:41.47starseekerright :-)
15:42.20starseekerI think that was brain-overload coding - it functioned, so go with it
15:42.28starseekerremoves the stray strcmp
15:42.49brlcaddid you actually see "editor[0] == '\0'" ?
15:43.02starseekeruh - don't recall
15:43.04brlcadbu_which() certainly shouldn't be returning that -- could even test for that
15:43.11brlcad(in bu_which())
15:43.25starseekerprobably not - I think it was more stupidity on my part
15:46.16CIA-43BRL-CAD: 03brlcad * r42143 10/brlcad/trunk/src/libbu/ (whereis.c which.c): add code to make sure, even though it's a very unlikely event, that we never return an empty string.
15:46.18CIA-43BRL-CAD: 03starseeker * r42144 10/brlcad/trunk/src/mged/tedit.c:
15:46.18CIA-43BRL-CAD: We can trust bu_wish not to return \0, so we don't need that check there. May
15:46.24CIA-43BRL-CAD: not need it anywhere, but we are getting returns from other functions early on
15:46.24CIA-43BRL-CAD: so would need more careful checking. Also remove the useless strcmp for editor
15:46.24CIA-43BRL-CAD: just after setting it to emacs.
15:47.05starseekerbrlcad: uh, it's close to a certainty that my brain said "check for an empty char array here" and did something colossally stupid - I doubt bu_which is at fault
15:48.10brlcadstarseeker: it's still a reasonable "guarantee" that bu_which() should be able to say, NULL if not found, non-NULL non-empty if found
15:48.17starseekerhas been doing too much build logic... s/bu_wish/bu_which
15:48.35starseekercool
15:52.34starseekerdoes head in this time...
15:52.49d_rossbergi like the NULL as a return value because i haven't to provide memory for it
15:57.04CIA-43BRL-CAD: 03brlcad * r42145 10/brlcad/trunk/src/conv/iges/iges.c: make sure initd before use, compiler doesn't see the bu_bomb().
15:58.29CIA-43BRL-CAD: 03brlcad * r42146 10/brlcad/trunk/src/conv/ (euclid/g-euclid.c iges/g-iges.c): restructure exception handling into try/catch form
16:07.55CIA-43BRL-CAD: 03d_rossberg * r42147 10/brlcad/trunk/ (include/bu.h src/libbu/str.c):
16:07.56CIA-43BRL-CAD: introduced bu_strcmp() with a more graceful string comparison as strcmp() does
16:07.56CIA-43BRL-CAD: "" and NULL are considered as equal
16:08.08d_rossbergi've always wanted to do that
16:25.11CIA-43BRL-CAD: 03d_rossberg * r42148 10/brlcad/trunk/include/bu.h:
16:25.12CIA-43BRL-CAD: the BU_STR_EMPTY() macro tests a string for emptiness ("" or NULL)
16:25.13CIA-43BRL-CAD: its result is either true or false
16:43.19CIA-43BRL-CAD: 03brlcad * r42149 10/brlcad/trunk/src/conv/iges/ (91 files): cleanup of the old and new iges codes. ws, consistency, de-k&r, indent, authorship, etc.
16:47.55brlcadstarseeker: I take it back, the old iges code is so much more extensive than the new that it'd be just ridiculous to dump it for the new one
16:48.25brlcadthe new one does have some nice stucture to it, but it's so devoid of implementation that it seems better just because there is so little complexity (or value) involved
16:56.52CIA-43BRL-CAD: 03brlcad * r42150 10/brlcad/trunk/include/bu.h: (log message trimmed)
16:56.53CIA-43BRL-CAD: follow suit and provide another BU_STR_EQUAL() macro for comparing two strings
16:56.53CIA-43BRL-CAD: for equality. this is similar to the STREQ recommendation by the ibm
16:56.54CIA-43BRL-CAD: developerworks best practices article
16:56.54CIA-43BRL-CAD: (http://www.ibm.com/developerworks/aix/library/au-hook_duttaC.html) so that
16:56.55CIA-43BRL-CAD: developers can use equality as a truthfulness return value consistently. there
16:57.09CIA-43BRL-CAD: are approximately 1400 present uses of strcmp() in BRL-CAD that can use this
17:32.49starseekerbrlcad: so... gradually refactor the old code to use better structure and convert to the new nurbs?
17:33.10starseekeror I suppose do so as part of merging it into libgcv
17:40.22CIA-43BRL-CAD: 03starseeker * r42151 10/brlcad/branches/cmake/ (102 files in 9 dirs): Update cmake branch to trunk r41250
17:45.29brlcadstarseeker: there is always possibility for better structure, particularly the bigger, older, and more complex code becomes ... so that's a given
17:46.01brlcadbut yeah, merge in capability for new nurbs would probably be better -- it'll just be more costly up front to learn the existing code
17:48.03brlcadunrelated topic, the compiler is reporting that it cannot inline the opennurbs_ext BBNode bounding box routine (GetBBox()), so there is possibly some significant performance to be gained by fixing that
18:06.55CIA-43BRL-CAD: 03starseeker * r42152 10/brlcad/branches/cmake/src/conv/iges/revolve.c: PI is coming up as undefined on OSX - use M_PI
18:10.58CIA-43BRL-CAD: 03brlcad * r42153 10/brlcad/trunk/src/librt/opennurbs_ext.h: force inlining on the bounding box routines since gcc (4.0.1) complains that it cannot without increasing an inline limit. remove inline from destructors (gcc is similiarly complaining that it cannot).
18:11.50CIA-43BRL-CAD: 03brlcad * r42154 10/brlcad/trunk/src/librt/ (bool.c comb/comb.c): sign matching
18:32.42CIA-43BRL-CAD: 03erikgreenwald * r42155 10/brlcad/trunk/src/libbn/ (bntester.c poly.c tabdata.c): fix various warnings
18:35.08CIA-43BRL-CAD: 03starseeker * r42156 10/brlcad/branches/cmake/src/other/tcl/ (4 files in 4 dirs): Start the process of taking things out of -D defines and putting them in config headers.
18:48.27CIA-43BRL-CAD: 03starseeker * r42157 10/brlcad/branches/cmake/src/other/ (5 files in 5 dirs):
18:48.27CIA-43BRL-CAD: more -D elimination - a lot of these defines probably aren't even needed in
18:48.28CIA-43BRL-CAD: CMake builds, as they don't seem to be used by the C code and CMake is handling
18:48.29CIA-43BRL-CAD: the generation of whatever config files are needed itself... for the ones that
18:48.33CIA-43BRL-CAD: are, the only code change is to include the generated header. Definitely more
18:48.33CIA-43BRL-CAD: cleanup to do on these to reduce the build logic to the functioning minimum.
18:53.19CIA-43BRL-CAD: 03starseeker * r42158 10/brlcad/branches/cmake/CMakeLists.txt: Let's try a space on Windows again and see if those defines fixed it...
18:59.41CIA-43BRL-CAD: 03brlcad * r42159 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: size_t
19:00.09CIA-43BRL-CAD: 03brlcad * r42160 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: VMOVE before we print the value.
19:01.24CIA-43BRL-CAD: 03brlcad * r42161 10/brlcad/trunk/src/librt/primitives/nmg/nmg_brep.cpp: init max_pt too, quell warning
19:06.31CIA-43BRL-CAD: 03brlcad * r42162 10/brlcad/trunk/ (8 files in 2 dirs): make a slew of other object count struct data members be size_t instead of long and int so that can be properly unsigned and higher bound. match signedness in librt accordingly.
19:14.49CIA-43BRL-CAD: 03brlcad * r42163 10/brlcad/trunk/src/ (9 files in 2 dirs): another BU_PTBL_LEN caller, size_t it up.
19:17.10CIA-43BRL-CAD: 03brlcad * r42164 10/brlcad/trunk/include/bu.h: just call bu_strcmpm() directly instead of macro. didn't get the preproc syntax right anyways.
19:26.35brlcadis excited that we're SO CLOSE to a strict clean build!
19:29.16brlcadimproved security, maintainability, conformance/verification/validation, .. yum
19:34.56brlcadenvisions a day where the source code is completely 100% lintian free with best practices enforced across the entire 1M+ body of code
19:37.36CIA-43BRL-CAD: 03brlcad * r42165 10/brlcad/trunk/src/conv/iges/revolve.c: didn't starseeker already fix this? M_PI is the new coke.
19:39.50CIA-43BRL-CAD: 03brlcad * r42166 10/brlcad/trunk/src/conv/iges/iges.c: multicharacter string constants are not valid to cpp, so move the literal to a define in order to catch future auto-expansions
20:23.25*** join/#brlcad ibot (~ibot@198.60.114.207)
20:23.25*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years...
20:28.16CIA-43BRL-CAD: 03brlcad * r42170 10/brlcad/trunk/src/fb/pp-fb.c: init to zero pixels
20:28.17CIA-43BRL-CAD: 03starseeker * r42169 10/brlcad/branches/cmake/CMakeLists.txt: Interesting - the -c option causes the time delta compile to fail.
20:30.20CIA-43BRL-CAD: 03brlcad * r42173 10/brlcad/trunk/src/util/ (pc_test.c pixborder.c pixcount.c pixdsplit.c): more unset before use insanity.
20:30.49CIA-43BRL-CAD: 03brlcad * r42174 10/brlcad/trunk/bench/pixcmp.c: test of conversion to BU_STR_EQUAL() instead of directly calling strcmp().
20:31.23DaveLogetting an error in arbn.c:
20:31.37DaveLoprimitives/arbn/arbn.c: In function ?rt_arbn_describe?:
20:31.37DaveLoprimitives/arbn/arbn.c:1026: error: format ?%lu? expects type ?long unsigned int?, but argument 3 has type ?size_t?
20:31.40DaveLoprimitives/arbn/arbn.c:1037: error: format ?%lu? expects type ?long unsigned int?, but argument 3 has type ?size_t?
20:32.32``Eriklots of those
20:32.33``Eriklots and lot
20:32.34``Eriks
20:33.48``Erikthinks he's about to get very involved with GS O>o
20:33.54CIA-43BRL-CAD: 03erikgreenwald * r42175 10/brlcad/trunk/src/adrt/ (27 files in 3 dirs): warning quellage. formatting fixes.
20:34.19DaveLowhat makes you say that?
20:35.07*** join/#brlcad ibot (~ibot@rikers.org)
20:35.07*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years...
20:35.10``Erik(k keeps building after failure)
20:35.23``Erikor didja mean GS?
20:35.58DaveLohuh?
20:36.21starseekerwhat made him say what?
20:36.33DaveLowhos a what?
20:36.40``Erikforshizzle?
20:36.48DaveLoforrizzle!
20:40.58DaveLoFYI: I was updating the repos on my Ubuntutututu box and ran into some size_t compile errors in brlcad
20:41.27DaveLofigured I'd mention it since brlcad is in the mist of some massive size_t work
21:13.20CIA-43BRL-CAD: 03starseeker * r42176 10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: Remove old files before making new ones...
21:37.00CIA-43BRL-CAD: 03starseeker * r42177 10/brlcad/branches/cmake/src/other/ (6 files in 6 dirs): Remove all the -c flags from the Tcl/Tk builds
21:40.31*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
21:56.14brlcadDaveLo: I've got a clean build on mac and linux, but size_t is going to be pretty sensitive to platform differences so some failures undoubtedly need weeding out
21:56.29brlcadshould be trivial fixes, at least
21:57.00brlcadDaveLo: and --enable-warnings is now the default (as of yesterday)
22:08.21CIA-43BRL-CAD: 03starseeker * r42178 10/brlcad/branches/cmake/CMakeLists.txt: For whatever reason, CMAKE_C_FLAGS is upsetting VC++ 2010 - comment it out
22:15.44CIA-43BRL-CAD: 03erikgreenwald * r42179 10/brlcad/trunk/src/libfb/if_ogl.c: signed/unsigned comparison fixes
22:41.39``Erikbrlcad: if'n ya get bored, http://brlcad.org/~erik/r42179/  :D *heads home*
22:49.49brlcadheh
22:49.52CIA-43BRL-CAD: 03brlcad * r42180 10/brlcad/trunk/src/libbu/CMakeLists.txt: sync timetester to cmake build for distcheck
22:50.41starseekergrowls... CMake build doesn't run as of 42152
22:50.55starseekerseems to run at 42150, confirming that
22:51.15starseekerwhat could possibly have changed...
22:52.47brlcadi've done so much fast typing for over a week now that my rsi is starting to act up
22:53.08starseekerwinces - that's not good
22:54.40brlcadnot too bad just yet, just having to take more breaks
22:55.04brlcadediting thousands of files will do that
22:56.01brlcadstarseeker: i'd be cautious on any failure -- those size_t changes could easily have (and undoubtedly have in some places) caused a bug to get injected somewhere/anywhere
22:56.19brlcadalong with the changes before I got on the size_t rampage even
22:56.49starseekernods - I'm trying to isolate when it happend
22:57.23starseekerwill cheerfully revert the source of cmake branch to a known good state and work on that, if he can find such a state
23:02.53starseekerOK, NOT working at 42150
23:09.52starseeker42139 working
23:09.58starseekerdid that archer change mess things up somehow???
23:25.10CIA-43BRL-CAD: 03starseeker * r42181 10/brlcad/branches/cmake/src/archer/CMakeLists.txt: Hmm - this makes mged REALLY unhappy, so don't do it...
23:26.46CIA-43BRL-CAD: 03brlcad * r42182 10/brlcad/trunk/src/mged/hideline.c: protect from peculiar setjmp() use in here by making the variables set before and accessed afterwards as static. candidate for removal.
23:29.17CIA-43BRL-CAD: 03brlcad * r42183 10/brlcad/trunk/src/mged/dodraw.c:
23:29.17CIA-43BRL-CAD: one of the more complicated ways to handle BU_SETJUMPing so that variables set
23:29.18CIA-43BRL-CAD: before the jump and accessed afterwards do not have their values clobbered when
23:29.18CIA-43BRL-CAD: a jump occurs. solution is to pull just exactly the try/catch code out into
23:29.19CIA-43BRL-CAD: their own functions so there are no variables in that frame that might be
23:29.19CIA-43BRL-CAD: clobbered in the first place. this is done twice here.
23:29.52CIA-43BRL-CAD: 03brlcad * r42184 10/brlcad/trunk/src/mged/cmd.c: size_t upconvert argc
23:30.17starseekerO.o - that's some scary sounding logic - why are we need jumps like that, speed?
23:30.51starseekerbreaths a sigh of relief - MGED runs again
23:39.13CIA-43BRL-CAD: 03brlcad * r42185 10/brlcad/trunk/src/mged/rtif.c: wrong comment to the wrong file. protect from peculiar setjmp() use in here by making the variables set before and accessed afterwards as static. candidate for removal.
23:39.56CIA-43BRL-CAD: 03brlcad * r42186 10/brlcad/trunk/src/mged/mged.c: make sure we have an out if we don't have an out.
23:40.51CIA-43BRL-CAD: 03brlcad * r42187 10/brlcad/trunk/src/mged/ (cad_parea.c chgview.c clone.c): init vars before they're used, especially when they're only set within conditionals.
23:42.19starseekerheh 42186 sounds like Yogi Berra
23:46.32CIA-43BRL-CAD: 03brlcad * r42188 10/brlcad/trunk/src/mged/cad_boundp.c: one more needing to be initialized
23:47.46brlcadstarseeker: jumps are the old school way to perform exception handling
23:48.11brlcadc++'s exception handling was originally implemented using setjmp/longjmp and macros
23:48.37brlcadyou just have to know what you're doing and what happens when a jump occurs
23:49.02brlcadsome of our code was making assumptions which work in practice, but aren't guaranteed
23:49.20starseekerah
23:49.50brlcadbasically, IF a jump happens, variables are reset back to their state when the jumppoint was *set* .. so if you modify them after the set and then jump, their values are clobbered
23:50.17brlcadmost of the time, that's perfectly fine
23:51.03brlcadand whether it's fine or not, doing the "wrap the try/catch" in a function trick makes the problem pretty much moot because there are no longer any stack variables getting clobbered
23:51.52starseekernods
23:53.17brlcadI want to rewrite our macros so we're not setting and unsetting jumps, instead providing BU_TRY/BU_CATCH macros
23:53.39starseekerhow many places in the code will that touch?
23:56.28starseekerworries about brlcad's wrists
23:56.47brlcadI don't remember how many places, not too many
23:56.54starseekercool
23:56.58brlcadunfortunately not really scriptable though :)
23:57.03starseekerheh
23:57.13brlcadjust scan on BU_SETJUMP though and you'll find them all
23:58.32starseekerpopular in the convertors
23:58.52brlcadyep, nmg stuff throws exceptions as part of normal business
23:59.43brlcadBU_SETJUMP is the way to catch a bu_bomb() so it doesn't actually exit
IRC log for #brlcad on 20110113

IRC log for #brlcad on 20110113

00:05.30CIA-43BRL-CAD: 03starseeker * r42189 10/brlcad/branches/cmake/src/tclscripts/ (18 files in 18 dirs):
00:05.30CIA-43BRL-CAD: Alright, I'm tired of fighting with trying to get the custom tclscripts to run
00:05.31CIA-43BRL-CAD: cleanly in parallel when they're doing copy commands after the btclsh script
00:05.31CIA-43BRL-CAD: runs. Put copies of the tcl files in the build dir and run the scripts there.
00:05.32CIA-43BRL-CAD: Simplifies the logic and avoids the hackery of copying things around as part of
00:05.32CIA-43BRL-CAD: the custom command.
00:06.20starseekermmm... bu_brlcad_data clearly isn't up to what I'm trying with archer...
00:12.03brlcadhow so?
00:12.15brlcadit has a pretty well-defined usage contract
00:12.53starseekerit may just be I don't have the right things in place in the build dir
00:13.29brlcadif which in reality should end up in just one or two file/dir stats if everything is set up right, the rest of the logic being just for failure backup
00:13.30starseekerrror in startup script: couldn't read file "/usr/brlcad/share/tclscripts/itk_redefines.tcl": no such file or directory while executing
00:13.33starseeker"source [file join [bu_brlcad_data "tclscripts"] itk_redefines.tcl]" (file "./bin/archer" line 62)
00:14.05starseekerprefix isn't /usr/brlcad for this build either, but once I do a make install it finds things OK
00:14.15brlcadit shouldn't need to be /usr/brlcad
00:14.21starseekerright
00:14.35brlcadbu.h has the search priority ordering
00:14.46starseekerchecks...
00:15.01brlcadfirst step is to make sure itk_redefines.tcl is actually in /usr/brlcad/share/brlcad/version/tclscripts/itk_redefines.tcl (or whatever your data root is)
00:15.32brlcadthen can make sure bu_brlcad_data "." is reporting the data root just by running bwish
00:15.48brlcadthen bu_brlcad_data "tclscripts" to make sure it's there, etc
00:17.05brlcadthat looks right to me, the archer logic might be wrong
00:17.59starseekerweird... from the build directory it's returning /usr/brlcad/share/. but once installed it's /Users/user/brlcad-install-svn/share/.
00:18.17starseekerwill look into it later, not a huge deal
00:18.26starseekerdunno if archer is even set up to run from the build dir at all
00:18.59brlcadif it cannot find it pre-install, it will fall back on /usr/brlcad where it's undoubtedly finding an old root
00:19.13starseekerah
00:19.17brlcadhttp://pastebin.mozilla.org/930556
00:19.48starseekernods
00:20.31brlcadyeah, I'm not seeing that file anywhere
00:20.47starseekeryep - if I make a share directory, it finds it.  That's also why that archer CMakeLists.txt change played such havoc with mged - it found a data dir with nothing in it
00:21.17starseekerbrlcad: that file is specific to the CMake branch so far - it's what allows archer to run with vanilla Itcl/Itk
00:21.31brlcadahh, okay
00:22.10starseekerit looks like if I want to do this right I'll have to fully populate the share dir in the build dir
00:22.11brlcadif you're working on pre-install build states and with partial empty install trees, you probably should familiarize with the search path rules it uses
00:22.30starseekernods
00:22.59starseekerI don't recall ever trying - does archer run from the build dir in trunk?
00:23.12starseekermaybe I should worry about this later
00:23.26brlcadit has for me
00:23.38starseekercrud
00:23.40brlcadhaven't tested latestly
00:29.00CIA-43BRL-CAD: 03starseeker * r42190 10/brlcad/branches/cmake/TODO.cmake: Update TODO.cmake
00:32.29brlcadhm, looks like trunk has problems running uninstalled, but it's due to ... Tkhtml3 :)
00:32.46starseekergrowl
00:33.17starseekerwonders what possessed him to ever fool with tkhtml...
00:33.39brlcadah, looks like tktable too
00:34.22brlcadyou can't just add dependencies and everything gets found -- you have to tell the code that looks for things where to look for the new things when they're added
00:35.01starseekerwants the computer to be smart, doggone it
00:36.01brlcadroyal you, not you specifically :)
00:36.11brlcadnot that you aren't royal
00:36.12starseekerah :-)
00:36.28starseeker<- royal pain
00:37.32starseekerI'll dig into this, but it looks like studying usage of bu_brlcad_data will be the key - thanks!
00:39.57brlcaddon't be shy to fix archer
00:40.46starseekerbrlcad: I'm more concerned about the notion of a build-dir share directory and how it fits (or doesn't fit) with how bu_brlcad_root and bu_brlcad_data are working
00:41.05brlcadbu_brlcad_data/bu_brlcad_root *should* be suitable for any use .. there are lots of places in archer that probably don't use it yet or call it correctly
00:42.12brlcadthere is no such notion to bu_brlcad_root/bu_brlcad_data other than to check the current directory
00:42.20starseekerthe thing is, I'm going to want bu_brlcad_root to return the build directory root if I'm not running installed, but the installed root directory if I am
00:42.28brlcadthe package require system is completely separate foo
00:42.42starseekerpackage require I'm getting a handle on
00:43.34starseekerI can already package require Tkhtml/tkpng/etc from ./bin/bwish
00:44.16brlcadan easy solution is to make the resources locatable w.r.t. archer
00:44.41starseekernods
00:45.15*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
00:45.16*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
00:45.19starseekerthat itk_redefines.tcl file should probably fold straight into archer itself
00:45.21brlcadso if something does rely on bu_brlcad_data, calling bu_brlcad_data "tclscripts/archer" is going to find src/archer/tclscripts/archer or something similar
00:45.57starseekerum
00:46.12brlcadyou build instal an uninstalled install root?
00:46.51starseekerbasically - the build dir is a pseudo-install tree
00:47.07brlcadbut are they only binaries or also data files?
00:47.18brlcadlike tclscripts
00:47.28starseekerso far binaries, libraries and whatever tcl/tk stuff I've needed to get package require working
00:47.48starseekerI haven't rebuilt the tclscripts install dir yet, but even if I did I'm not sure it would work
00:47.51brlcadwell that'd be most of our tclscripts dir too then
00:48.41brlcadour tclscripts dir has a slew of packages defined in there, package require Archer for example, package require GeometryBrowser, etc
00:49.18starseekerright - it was trying to get those working that I ran into the problem with a share dir in the toplevel build dir blowing up mged
00:49.59starseekertclAutoPath has a bunch of paths for the tclscript dirs - I figured I could leverage that
00:50.35brlcadyeah, that's the separate system
00:51.02brlcadwhat about just making the build tree be an *exact* replica of the install tree?
00:51.04starseekereven copying the complete installed share dir from the install back into the build dir didn't make mged happy, which worries me
00:51.24brlcadso installing is literally the same as cp -R buildTree /usr/brlcad
00:51.35starseekerbrlcad: that gets back to the bu_brlcad_root - in that instance, it would have to use the toplevel build dir as its root dir
00:51.48starseekerand it's not set up to do that right now, unless I'm missing something
00:52.02starseekerI could make it do that, but I figured I'd get in trouble :-P
00:52.32brlcadno, that'd definitely work if it's a full root
00:52.49brlcadthe third rule for bu_brlcad_root
00:53.11starseekertries again...
00:53.26brlcadit searches an env override if set first, then the compile-time install path if it exists, then the current RUN TIME path if it doesn't .. that'd match
00:54.01starseekerah - what if the compile-time install path exists but is empty?
00:54.08brlcadthen that's a problem
00:54.16brlcadit looks for directories
00:54.34brlcadthe code calling bu_brlcad_root/data is then supposed to verify files
00:55.17starseekerI always use brlcad-install-svn for my target, so that directory already exists
00:55.33brlcaddelete the dir?
00:55.54brlcadinstall should create it
00:55.56starseekerI can, but shouldn't it be robust enough to recognize that there is nothing in there and try the next possibility?
00:56.16brlcadit has no idea what you're looking for
00:56.22brlcade.g., bu_brlcad_root .
00:56.44brlcadhow do you know if it found root or not, other than it exists?
00:56.55brlcadat least maintainably without some random assumption
00:56.59starseekersure, but a totally empty root may as well not exist
00:57.28brlcadright, so ideally, code calling bu_brlcad_root should be more specific than "."
00:57.35brlcadand most places are
00:57.45brlcadbu_brlcad_data tclscripts, for example
00:58.11starseekerok, but if it doesn't find tclscripts in the first possiblity will it move on to the second?
00:58.18brlcadyep
00:58.33brlcadbu_brlcad_root (subdir)
00:58.57brlcadit searches for (subdir) in those search-order paths returning the first found
00:59.28starseekerthen how can an empty share dir in the toplevel build make mged crash, and removing it allows it to run?
01:00.24brlcadit wouldn't make sense to assume if ROOT/some/subdir is empty, then skip it (e.g., ROOT/.) .. because it just as easily could be a read/write location we're using, (e.g., ROOT/caches/rt)
01:00.58brlcadyou've got the crash, debug it! :)
01:01.05brlcadshouldn't crash regardless
01:01.13brlcadthat should be easy to stack trace fix
01:02.06starseekerpackage require Itcl is failing
01:02.58*** join/#brlcad crazy_imp (~mj@a89-182-24-66.net-htp.de)
01:03.33starseekeruh... why?  bwish and btclsh do fine...
01:04.19brlcadcutting a narrow path through the forest just wide enough to slip through isn't going to be safe route for travel
01:05.56starseekerhmm?  Right now I've got no path
01:06.59starseekeralso has to get home
01:09.55brlcadright, but the goal isn't just getting any path and then later widening it too
01:10.08brlcadthat's the super-expensive way
01:10.31starseekerbrlcad: oh, I'm going to try and figure out what's going on and what the right way is to handle it
01:11.25starseekerbut this seems to be right in that ugly underbelly of interaction between data path searching, tcl/tk weirdness, and application initialization from a build directory - that's pretty much a poster child for "tangled web"
01:11.32brlcadI know, just noting that you found a crash but aren't actually working on fixing the crash :)
01:12.07starseeker<snort> I will tomorrow - I've got a 6:30am gym session, and if I'm up late tonight I might never make it in at all tomorrow :-P
01:12.21brlcadbecause even if the right way masks the problem for now, it's almost guaranteed to bite someone down the road
01:12.28brlcadand the older a bug gets, the harder they bit
01:12.39brlcadeven ones you rediscover later
01:13.12brlcadmm.. gym is the perfect excuse, stay healty ;)
01:13.31starseekerwell, it remains to be seen if this is truely a bug, since I'm in a very different setup than the autotools build and I could quite easily being doing Something Wrong with the build logic
01:13.46starseekerI doubt this behavior has ever been observed with autotools
01:13.53brlcadI seem to be having a lot of one-byte erors tonight :)
01:14.15starseekerouch
01:14.25brlcad"something wrong" that makes mged crash is still mged's fault
01:14.29brlcadand preventable
01:15.02brlcadthat just means mged/archer/whatever was assuming something -- there should be no assumptions, you test everything
01:15.08starseekerthis is an altered mged though - remember how I switched it from using Itcl's C interface to using package require?
01:15.29starseekerso it's almost certainly my fault
01:15.54brlcadthe code is still at fault for crashing -- you can catch the problem state in code before crashes occur
01:16.17starseekernods
01:16.37brlcadyou may have made it more brittle or just differently brittle, but the code is still at fault for crashing
01:17.03starseekerwas hoping that using package require instead of the C api would make the migration to 8.6 easier, when it comes
01:17.12brlcadeven if you feed it /dev/random, or bang on they keyboard and randomly move files around while they're being read, it shouldn't crash
01:17.31starseekernods
01:18.01brlcadpackage require should be better
01:18.06brlcadjust means you're not done :)
01:18.22brlcadthough time really is running out, GS is REALLY going to be hurting
01:18.42starseekerthis can be put on hold
01:18.48brlcadsays to pot to the kettle as I make some more size_t fixes
01:19.07brlcads/to pot/the pot/
01:19.28starseekerlast time I talked to DaveLo, it sounded like the code wasn't in any shape to be talking to any test harness...
01:19.57starseekerstill, I guess if that's the case step one will be to rewrite it until it is...
01:20.03brlcadyour test harness should show that, it's fully independent effort
01:20.19brlcadand once you get to the point where you see where it's not, you can help with exactly that next step
01:21.15brlcadcoupled development is a major no-no for any project of value
01:23.24brlcadstarseeker: I see why archer is failing to load (at least current set of problems)
01:23.37brlcadit is just blindly setting the data root and trying to load
01:24.04brlcadthe previous code checked if it was running in a source configuration with a neat bu_brlcad_data "src" trick :)
01:24.16brlcadsee src/archer/plugins/Wizards/humanwizard.tcl for an example
01:25.01brlcadbasically it's falling back onto the last rule that bu_brlcad_data uses, looking for paths relative to the current directory
01:25.49starseekerthat doesn't get hijacked by the presence of /usr/brlcad?
01:26.36brlcadsorry, second to last rule ;)
01:26.45brlcad/usr/brlcad is checked even if it's not the build dir
01:26.50brlcader install dir
01:28.30starseekeryeah - isn't that kinda a bad idea? the presence of /usr/brlcad will kill any possibility of the current directory being used
01:29.43CIA-43BRL-CAD: 03starseeker * r42191 10/brlcad/branches/cmake/TODO.cmake: Few more notes about current state of CMake - will probably have to leave this for a while.
01:29.48starseekerok, I really do have to go
01:33.36brlcadstarseeker: no, it'll check current dir before it
01:33.44brlcadsee the search order rules in bu.h
01:42.51CIA-43BRL-CAD: 03brlcad * r42192 10/brlcad/trunk/src/archer/archer: try a little harder to find data resources so archer can run uninstalled
01:43.27CIA-43BRL-CAD: 03brlcad * r42193 10/brlcad/trunk/src/tclscripts/archer/LoadArcherLibs.tcl: if hv3/tkhtml won't load, it's not the end of the world.
01:45.28brlcadaha, that is the problem, looking for "." is not what you'd expect for a multi-root install since it'll find the /usr/brlcad hail mary case
01:54.48CIA-43BRL-CAD: 03brlcad * r42194 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: search harder here too for aboutArcher.png and mike-tux.png
01:55.02CIA-43BRL-CAD: 03brlcad * r42195 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: look for src dir too
01:59.59CIA-43BRL-CAD: 03brlcad * r42196 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: hopefully not lost in the indentation cleanup, make bu_brlcad_data only check for one subdir, then use [file join] on the rest
02:21.47brlcadheh, interesting
02:22.05brlcadsrc/tclscripts/nirt/prototype.sh  <-- starseeker, you might find that amusing
02:22.25brlcada prototype interface around nirt by pjt
02:22.30brlcadcheck it out before updating, because I'm killing it
02:27.21CIA-43BRL-CAD: 03brlcad * r42197 10/brlcad/trunk/src/tclscripts/ (13 files in 3 dirs):
02:27.21CIA-43BRL-CAD: bu_brlcad_root should ideally only be called with one subdirectory for
02:27.22CIA-43BRL-CAD: portability, then use tcl's [file join] on the rest of the path. this is likely
02:27.22CIA-43BRL-CAD: the problem that necessitated adding '.exe' extensions to the binaries for
02:27.23CIA-43BRL-CAD: windows because the lower-level C code was trying to stat the file. this should
02:27.23CIA-43BRL-CAD: simplify things nicely.
02:28.35CIA-43BRL-CAD: 03brlcad * r42198 10/brlcad/trunk/ (configure.ac src/tclscripts/Makefile.am src/tclscripts/nirt/):
02:28.35CIA-43BRL-CAD: remove the nirt tclscripts directory. there was just one source file in there,
02:28.36CIA-43BRL-CAD: prototype.sh, which was a prototype interface by pjt for nirt. long since
02:28.36CIA-43BRL-CAD: overcome by events and not that great a prototype anyways... sorry paul. :)
02:30.25CIA-43BRL-CAD: 03brlcad * r42199 10/brlcad/trunk/src/tclscripts/rtwizard/lib/ (FbPage.itk PictureTypeE.itcl): unnecessary but consistent
02:31.14CIA-43BRL-CAD: 03brlcad * r42200 10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeF.itcl: missed one, wrap in quotes for consistency
02:42.41CIA-43BRL-CAD: 03brlcad * r42201 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl):
02:42.42CIA-43BRL-CAD: remove brlcadDataPath since you really don't want to look for '.' unless you
02:42.42CIA-43BRL-CAD: absolutely have to, otherwise you risk getting a non-usable /usr/brlcad default.
02:42.43CIA-43BRL-CAD: looking for the subdirectories individually makes them try the run-time relative
02:42.43CIA-43BRL-CAD: path first, which means we don't even need to try a separate 'src' search unless
02:42.44CIA-43BRL-CAD: it's for items that are in a different place hierarchically in the source tree
02:42.45CIA-43BRL-CAD: than they are after install.
03:02.45CIA-43BRL-CAD: 03brlcad * r42202 10/brlcad/trunk/src/tclscripts/lib/Command.tcl: gracefully handle a failure to create a slave interpreter
03:13.13CIA-43BRL-CAD: 03brlcad * r42203 10/brlcad/trunk/src/tclscripts/lib/Command.tcl: catch the other place we create an interpreter too
03:28.22CIA-43BRL-CAD: 03brlcad * r42204 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c:
03:28.23CIA-43BRL-CAD: for some reason, 'create interp' goes through a different initialization process
03:28.24CIA-43BRL-CAD: which causes a failure to find init.tcl if we try to run uninstalled. it checks
03:28.25CIA-43BRL-CAD: [tcl::pkgconfig get scriptdir,runtime] but does not respect $tcl_library. it
03:28.26CIA-43BRL-CAD: DOES, however, respect env(TCL_LIBRARY) so make sure we set that too when we're
03:28.27CIA-43BRL-CAD: initializing unless the user already has it set to something.
03:36.13CIA-43BRL-CAD: 03brlcad * r42205 10/brlcad/trunk/src/libtclcad/ged_obj.c:
03:36.14CIA-43BRL-CAD: error message is very obtuse. is the type printed not supported for a given
03:36.15CIA-43BRL-CAD: use, or not supported because it wasn't compiled. the latter was meant but not
03:36.15CIA-43BRL-CAD: stated. reword for clarity and provide some instruction for when things go bad.
03:36.18brlcadthere, that should bring archer back into a working state
03:36.24brlcaduninstalled
03:36.40DX^"Several BRL-CAD developers are working on implementing a full STEP converter."
03:36.43DX^who are these developers?
03:37.40brlcadDX^: http://www.ohloh.net/p/brlcad/contributors  <-- developers with activity in the past year
03:38.39brlcadthere is already initial support for import, with more work happening this year to complete it
03:39.04brlcadthere has been rumbling talks about an exporter (which is WAY easier), but nobody is working on it yet
03:42.48CIA-43BRL-CAD: 03brlcad * r42206 10/brlcad/trunk/src/libbu/Makefile.am: wow, long time since I've seen THIS particular build system bug.. heh. add missing \ line continuation after timetester.c in EXTRA_DIST so CMakeLists.txt isn't left out.
03:49.45DX^brlcad: I did minor modificiations to g_xxx-facets.c to output JSON (javascript)
03:50.25DX^I am very interested in IGES/STEP import/export
03:50.57DX^I also think there should be a tool/script that takes one file format directly to another, without having to do foo->g->newfoo, but haven't really figured out how this would work yet
03:51.13DX^the code is massive and complicated, and I have difficulty understanding what is going on most of the time to be honest
03:52.09brlcadDX^: you know we have pretty extensive support for iges import/export
03:52.34DX^I submitted an IGES bug not too long ago
03:52.35brlcadit was (and still is in some ways) our most extensive converter
03:52.44brlcadjust quite aged and lacking attentino
03:52.59DX^it won't import the 2011/2012 Autodesk versions of IGES for whatever reason
03:53.19brlcadnot surprising, it was written around version 5.1
03:53.30DX^brl-cad or autodesk?
03:53.35brlcadprobably something very very minor
03:53.37brlcadiges
03:53.39brlcadiges 5.1
03:54.03brlcadcurrent/last iges is 5.3 or 6.0 draft if they were on the drafting committee before it collapsed
03:54.22DX^hmm
03:54.42brlcadso it could be something as simple as a header having a 5.3 in it and our converter choking on it
03:54.43DX^I wonder the amount of work required to support IGES 5.3
03:54.53brlcadmore than likely a "little" more complicated than that, but probably not much more
03:55.21brlcadthere weren't huge changes, the format itself is the same -- just slightly different entity details
03:55.57brlcadthe spec is available: http://www.uspro.org/documents/IGES5-3_forDownload.pdf
03:56.00DX^http://sourceforge.net/tracker/?func=detail&aid=3125119&group_id=105292&atid=640802
03:56.02brlcadso you could review and compare
03:56.05DX^was what I submitted
03:56.10DX^Add_nurb_loop_to_face: Edgeuse/vertex mixup!
03:56.59brlcadyeah, that's not even format-related -- it parsed all of the entities as shown in the summary
03:57.31DX^yep, not sure what the deal is
03:57.41brlcadit's some deficiency or bug in importing that specific object type
03:57.56DX^but the same file imported into older versions of inventor and exported as IGES imported into BRL-CAD just fine
03:58.09DX^so I think they changed something (obviously)
03:58.26brlcadthe method it uses isn't the best because when the converter was written it had to turn most iges entities into polygons during import -- so that's what it's trying to do and failing on
03:58.53brlcadthat's the (eu == edge use) toplogy failure
03:59.42brlcadDX^: could be LOTS of reasons why it failed really
03:59.54DX^yeah
04:00.02brlcadsimple subtle changes in the floating point alone after reconverting could have made it work
04:00.16brlcadwould have to compare the summary reports from the one that worked
04:00.24DX^I need to brush up on more advanced C before I can touch this code base
04:00.32DX^I'd love to help but I'm afraid my meddling hands would break too much
04:00.52brlcadanything you did would get reviewed by others, so don't be too afraid to dig in ;)
04:01.09brlcadyou're not going to break anythign that will hurt anyone but yourself :D
04:01.12DX^thing is that I just don't know what the hell is going on yet
04:01.46DX^I'm more focused on the converters.. I think a solid suite of geometry converters would bring more attention to BRL-CAD
04:01.48brlcadyou should turn your g_xxx-facets.c work to a proper g-json tool
04:02.11DX^I will make it more robust and submit it
04:02.21brlcadit would, we have more converters than anyone, and the hardest ones at that (iges, step, dxf, etc)
04:02.58DX^an export to COLLADA would be immensely powerful, but that spec is confusing as all hell
04:03.36brlcadfor what it's worth, your tracker item hasn't been commented on mostly because the library that iges-g is using there is undergoing a massive review for robustness/stability
04:03.43brlcadcollada would be easy
04:04.39DX^think so?
04:04.54brlcadthere's an MIT-licensed SDK, so it would just be a matter of wiring it up
04:05.02brlcadno more complicated than writing json really
04:05.14DX^hmm I'll look into the SDK
04:05.21DX^another problem I was having is finding the top level object
04:05.33DX^I got it from mged, but its kind of confusing that you have to type it in manually at the command line
04:05.48brlcadcommon point of confusion for new users
04:05.58DX^I get the robustness of having it typed in, but shouldn't it default to all objects if the arg is omitted?
04:06.11brlcadthere's a todo-item to make all of the converters work on all top-level objects by default, but that's pretty low priority
04:06.47brlcadone of the reasons (though not the whole story) is that many formats only have support for single object export
04:06.51brlcade.g., stl
04:07.32brlcadso do you export one of the top-levels, which one?  combine all of them into a new top-level and export that?  it's not well-defined
04:07.47brlcadso the user has to learn what their situation is and decide
04:08.38brlcadnot great, but not terrible -- everyone figures it out pretty quickly, even faster if they go through any of the intro tutorials
04:13.57DX^yeah I certainly understand the dilemma
04:14.06DX^perhaps list all top level objects and allow the user to choose one
04:14.07DX^?
04:14.22DX^or write each one to a separate file
04:21.03brlcadyeah, ideally you'd just write each one to a separate file and make the usage default to specifying a filename template so it's defined and not surprising
04:21.13brlcadand scriptable
04:21.44brlcadnot an insurmountable problem, just nobody working in that particular area at the moment -- sounds like a great patch though ;)
04:22.08brlcadsrc/libged/tops.c shows how to get a list of top-level objects
04:22.23brlcadplenty of folks here to help walk through code
04:23.41brlcad``Erik: the very first error on the mac issues file is a failure in metaball.c saying parameter mismatch.  they match here, so maybe not up-to-date or something?  many of the errors that followed were just cascade failures from librt not compiling
04:52.25``ErikI looked at it and the types all looked correct, I'd verified with svn revert and svn diff before running that build... I just recall lots of signed/unsigned, lots of %lu vs size_t, and lots of unused parameter stuff showing up *shrug* I'll look at it some more tomorrow after the GS meeting
05:03.29CIA-43BRL-CAD: 03brlcad * r42207 10/brlcad/trunk/src/adrt/slave/slave.c: another BU_STR_EQUAL() conversion
05:03.54brlcadthe linux log looks valid
05:04.15brlcadfor whatever reason, the machine I tested isn't kicking those out with my build
05:04.55CIA-43BRL-CAD: 03brlcad * r42208 10/brlcad/trunk/src/burst/ (burst.c error.c fb.c ui.c): a lot more manual BU_STR_EQUAL conversions
05:06.59CIA-43BRL-CAD: 03brlcad * r42209 10/brlcad/trunk/src/util/ (6 files): fix a slew of warnings from erik's linux build log. don't ignore the return values from fread/fwrite/read/write/scanf.
05:07.58CIA-43BRL-CAD: 03brlcad * r42210 10/brlcad/trunk/src/fb/ (cat-fb.c fb-bw.c pl-fb.c pp-fb.c): more fixing of warnings from erik's linux build log. don't ignore the return values from fread/fwrite/read/write/scanf.
05:08.18CIA-43BRL-CAD: 03brlcad * r42211 10/brlcad/trunk/src/bwish/cmd.c: BU_STR_EQUAL
05:08.42CIA-43BRL-CAD: 03brlcad * r42212 10/brlcad/trunk/src/anim/chan_permute.c: strcmp -> BU_STR_EQUAL
05:09.45CIA-43BRL-CAD: 03brlcad * r42213 10/brlcad/trunk/src/util/Makefile.am: remove strict flags until all i/o funcs have return values checked
05:37.34*** join/#brlcad Stattrav (~Stattrav@122.172.16.143)
05:37.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:38.23CIA-43BRL-CAD: 03brlcad * r42214 10/brlcad/trunk/src/util/ (29 files): fix the remainder of the fread/fwrite/scanf/read/write return value warnings, adding simple diagnostic perror() error reporting if a failure is detected.
05:42.42brlcadawesome, only about 3000 issues remaining (TOTAL)
05:43.25brlcadshould compile 7.0 to see how far we've come along
05:44.06brlcad``Erik: that should be all of the linux error issues unless I missed something
05:46.32CIA-43BRL-CAD: 03brlcad * r42215 10/brlcad/trunk/src/conv/iges/readglobal.c: another COMMA case
06:33.46CIA-43BRL-CAD: 03brlcad * r42216 10/brlcad/trunk/src/ (77 files in 32 dirs): mass conversion from \!strcmp() to rossberg's newly added bu_strcmp() via the related BU_STR_EQUAL() macro. improved readability. 300+ calls modified.
07:05.54CIA-43BRL-CAD: 03brlcad * r42217 10/brlcad/trunk/misc/win32-msvc8/Makefile.am: pixcmp and pixblend missing from dist
07:06.19CIA-43BRL-CAD: 03brlcad * r42218 10/brlcad/trunk/src/libbn/Makefile.am: bntester.dat missing from dist
07:08.11CIA-43BRL-CAD: 03brlcad * r42219 10/brlcad/trunk/src/other/tktable/Makefile.in: misc directory is missing from dist
07:10.50CIA-43BRL-CAD: 03brlcad * r42220 10/brlcad/trunk/src/other/libz/Makefile.am: another trailing slash missing
07:25.21CIA-43BRL-CAD: 03brlcad * r42221 10/brlcad/trunk/src/ (146 files in 29 dirs): another even massiver conversion from strcmp()==0 to rossberg's newly added bu_strcmp() via the related BU_STR_EQUAL() macro. improved readability and consistency. 800+ calls modified.
07:39.06*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
07:44.28CIA-43BRL-CAD: 03brlcad * r42222 10/brlcad/trunk/src/ (27 files in 12 dirs): a smaller conversion from strcmp()!=0 to rossberg's newly added bu_strcmp() via the related BU_STR_EQUAL() macro. improved readability and consistency. 70+ calls.
07:56.47CIA-43BRL-CAD: 03brlcad * r42223 10/brlcad/trunk/src/ (9 files in 7 dirs): even smaller conversion from strcmp()==0 to rossberg's newly added bu_strcmp() via the related BU_STR_EQUAL() macro. improved readability and consistency. 20+ calls.
07:58.38CIA-43BRL-CAD: 03brlcad * r42224 10/brlcad/trunk/src/mged/tedit.c: what the hell.. !(!(!(really???)))
08:09.53CIA-43BRL-CAD: 03brlcad * r42225 10/brlcad/trunk/src/ (17 files in 6 dirs): more conversion from !strcmp() to rossbergs new bu_strcmp() func via the related BU_STR_EQUAL() macro. improved readability and consistency. 30+calls.
08:22.45CIA-43BRL-CAD: 03brlcad * r42226 10/brlcad/trunk/src/ (12 files in 8 dirs): handle a few more strcmp cases where the value returned is indeed important, so convert to bu_strcmp() intead of macro.
08:33.56CIA-43BRL-CAD: 03brlcad * r42227 10/brlcad/trunk/src/ (38 files in 14 dirs): and yet even more. set !BU_STR_EQUAL() for handling a few remaining strcmp cases used to test for non-matching.
08:36.12CIA-43BRL-CAD: 03brlcad * r42228 10/brlcad/trunk/HACKING: prevent null crashes and improve readability. strcmp() gets added to the avoidance list.
08:40.17CIA-43BRL-CAD: 03brlcad * r42229 10/brlcad/trunk/TODO: add distribution test for the HACKING-listed functions/globals to be avoided in favor of bu_* routines
08:44.14CIA-43BRL-CAD: 03brlcad * r42230 10/brlcad/trunk/src/other/ (Makefile.am fonts/):
08:44.15CIA-43BRL-CAD: might as well disable the fonts for now until it's time for them to be actively
08:44.15CIA-43BRL-CAD: worked on. hopefully by then cmake system will be up and running and we won't
08:44.16CIA-43BRL-CAD: have to fix the distcheck failure due to spaces in names. otherwise, revision
08:44.16CIA-43BRL-CAD: history will hold them in trust even if their web sources asplode.
08:54.30*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
08:59.54*** join/#brlcad mafm (~mafm@27.Red-83-45-72.dynamicIP.rima-tde.net)
10:45.02*** join/#brlcad mafm_ (~mafm@27.Red-83-45-72.dynamicIP.rima-tde.net)
12:38.25*** join/#brlcad mafm (~mafm@27.Red-83-45-72.dynamicIP.rima-tde.net)
13:34.09*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:36.21d_rossbergcompiler error on debian squeeze: primitives/arbn/arbn.c:1026: error: format '%lu' expects type 'long unsigned int', but argument 3 has type 'size_t'
13:41.23starseekeranybody know if we can convert cline primitives to something else?
13:47.34brlcadd_rossberg: short fix is just to cast since %z isn't really portable
13:49.50d_rossbergstarseeker: cmake's INSTALL ignores BRLCAD_PREFIX, CMAKE_INSTALL_PREFIX is empty
13:50.26brlcadd_rossberg: or --disable-warnings if you have other things to deal with :)
14:06.04brlcadlooks like I did quite a bang-up job last night .. and now I can reproduce erik's failures on linux (had to be optimized, I think)
14:06.20brlcadkicks CIA-43
14:06.21CIA-43ow
14:06.49brlcadat least a dozen commits its not reporting
14:12.30d_rossbergit looks like CIA-43 is still asleep
14:12.38brlcaddoing a review on all of the %lu's now
14:13.10starseekerbrlcad: what about incorporating some printing logic that does handle %z into libbu?
14:13.25brlcadstarseeker: we already handle %z in libbu
14:13.57brlcadI really don't want to wrap every single call to scanf/sscanf/printf/fprintf/...
14:14.07starseekerah
14:33.22CIA-43BRL-CAD: 03brlcad * r42231 10/brlcad/trunk/src/libpkg/pkg.c: libpkg doesn't depend on libbu
14:44.49CIA-43BRL-CAD: 03brlcad * r42232 10/brlcad/trunk/include/bu.h: error: macro bu_strcmp passed 2 arguments, but takes just 1. now it takes 2.
14:47.57CIA-43BRL-CAD: 03brlcad * r42233 10/brlcad/trunk/src/conv/fast4-g.c: oops, there is no bu_strlen()
14:50.52CIA-43BRL-CAD: 03brlcad * r42234 10/brlcad/trunk/src/irprep/irdisp.c: need bu.h
14:51.05CIA-43BRL-CAD: 03brlcad * r42235 10/brlcad/trunk/src/gtools/g_diff.c: renamed everyone except the first, ret_eq.
14:53.54CIA-43BRL-CAD: 03brlcad * r42236 10/brlcad/trunk/src/sig/ (d-a.c dwin.c ihist.c): more that need bu.h
14:54.27CIA-43BRL-CAD: 03brlcad * r42237 10/brlcad/trunk/src/util/pixrect.c: helps to actually set the variable.
14:54.37brlcadheh, cia must be really overloaded
14:55.39brlcadyeah, looks like someone rebased a git repo (it ends up replaying all commits)
14:57.04starseekerow
14:58.18brlcadah, fork of mandriva linux
15:03.06CIA-43BRL-CAD: 03d_rossberg * r42238 10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: export the new bu_strcmpm() too
15:06.01*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
15:07.53CIA-43BRL-CAD: 03d_rossberg * r42239 10/brlcad/trunk/src/libbu/CMakeLists.txt: fixed CMake configuration for library-testing tools
15:31.24brlcadstarseeker: I just noticed your changes to the mged/bwish startup .. remind me what was the issue was there?
15:33.00starseekerbasically I did a fair bit of reworking of how libtclcad was setting paths - I don't know that I did the right thing, but the upshot for mged was I made changes to bwish to accomidate my changes to tclcad but never went back around and did it for mged
15:33.13CIA-43BRL-CAD: 03starseeker * r42240 10/brlcad/branches/cmake/ (374 files in 75 dirs): Update cmake branch to trunk r42239
15:33.21brlcadreason I ask is because setting tclcad_auto_path() is a crutch, one that shouldn't be needed, so the code was trying to start without it before, then retrying if that fails -- new code seems to just punt
15:34.00starseekeruh.  maybe I'm abusing the mechanism, but package require mechanisms need the extra paths...
15:34.48starseekerexcept for archer, it's working pretty reliably now
15:34.56brlcadpackage require needs them because they've not been setup correctly
15:34.59CIA-43BRL-CAD: 03starseeker * r42241 10/brlcad/branches/cmake/src/tclscripts/CMakeLists.txt: nirt subdirectory is no more.
15:35.32starseekerby "set up correctly" do you mean placed where Tcl will seem them by default?
15:35.53brlcadsomething to that effect, but not necessarily a system installed path
15:36.20brlcadusing one of tcl's various searching rules, a means to specify beyond auto_path
15:36.40starseekerwhere are those rules defined?
15:36.54starseekerI had a heck of a time trying to figure out what governed search paths
15:36.58brlcadtechnically, we should be able to get away with one init_mged.tcl and with the right pkgIndex.tcl and tclIndex files, everything is found
15:37.29brlcadtclcad_auto_path() is the painful way to do all that in C code
15:37.51brlcadembedding search dirs into C code isn't a good idea
15:38.28starseekersure - I thought about just having tclcad_autopath point to one guaranteed to be there tcl file to do all the path extensions...
15:38.56starseekerbut figured I'd stay as close as i could to our current setup while doing what I wanted to do with it
15:41.00brlcadas close to current would have left the two-pass loop -- that seems unrelated to any changes made in tclcad_auto_path()
15:41.42brlcadwhy was mged failing as it was written?
15:41.56brlcad(that prompted r42244)
15:49.56starseekerwithout tclcad_auto_path, auto_path had only the install directories
15:50.56starseekerit got as far as trying to load libitcl.dylib from the install directory and wiped out
15:52.07starseekerhowever those initial pre-tccad_auto_path paths are being set, even running from the build dir it was picking up the installed directory's paths
15:53.40starseekerthat's why it succeeds if I remove the install dir - without the install dir in place, auto_path ends up populated with the build dir paths
15:55.38starseekerrather than depend on the black magic that seems to be the Tcl paths, I used the tclcad_auto_path mechanism to always ensure it was looking where it needed to look, based on current conditions
15:57.26starseekerthe question of course is how a build dir execution of ./bin/mged was getting the install paths - I've been searching
15:58.46starseekermy best guess is the Tcl_FindExecutable("mged") line - if that's picking up the system path mged, it's pulling in the wrong lib paths
15:59.22CIA-43BRL-CAD: 03starseeker * r42242 10/brlcad/branches/cmake/src/conv/fast4-g.c: bu_strlen undefined, not seeing it in libbu - probably something going on, use strlen for now in cmake branch.
16:02.05brlcadstarseeker: but there's part of my confusion -- if init failed without tclcad_auto_path() (e.g. libitcl.dylib not loading), the very next thing it should have been trying was to run tclcad_auto_path() to try again -- or are you saying the second pass also failed?
16:02.46starseekerI'm saying the first pass crashed - it never got to the second pass.  It crashed somewhere in Tcl itself
16:03.55brlcadthat sounds familiar, there was a bug in earlier versions of tcl that necessitated a private Tcl library call in order to not crash
16:05.43brlcadmy biggest concern is complacency because if it works, nobody is going to go back and look at the init code until something breaks yet again
16:06.21brlcadI don't have a big problem with the change, but do want to make sure we are moving closer towards no tclcad_auto_path and no btclsh/bwish .. not tighter assumed/required coupling
16:06.23starseekerthat's why I thought the tclcad_auto_path approach might be worthwhile - then we don't care what Tcl is doing, because we're feeding it exactly what we know it needs
16:06.32starseekeroh
16:07.07brlcadwhat you mentioned about calling a tcl init and having all the logic there would be a great decoupling
16:07.30brlcadtheoretically, we could embed a generic Tcl_Interp(), load that file, and have everything we need
16:07.40brlcadthat's the cleanliness goal
16:07.40starseekernods
16:08.00starseekerOK, that's probably doable - I had assumed there were reasons we weren't trying that
16:08.23starseekerBu_Init, Bn_Init and friends are definitely C...
16:08.43starseekeralthough even there we could probably make a package require mechanism that would work
16:08.47brlcadthose are one step closer towards "package require bu", "package require bn"
16:08.50starseekerdid it for isst after all
16:08.55starseekernods
16:09.10starseekerI can work towards package require bu if that's the goal - I'd vastly prefer that
16:09.12brlcadI believe they're actually sufficient, they just don't have a pkgIndex.tcl file
16:09.19starseekermessing with the C underbelly of Tcl is nasty
16:10.42brlcadmged should just "package require brlcad" or something similar, and have our core libs load up as sub-packages including bu, bn, rt, wdb, ged
16:12.02starseekeryeah, $5 that's it - bu_getprogname is returning mged, which in turn is causing Tcl_FindExecutable to find the installed mged (which is in the path) and populate based on the installed exe name, not the local one
16:12.53starseekerif mged isn't installed, Tcl_FindExecutable isn't coming back with anything usable (or possibly it's finding /usr/brlcad/bin/mged and is smart enough not to use that, not sure which)
16:13.29starseekersince there's nothing, Itcl fails to load and it comes back around for the auto_path enhancements (which does work)
16:15.57starseekerbingo.  If I force-feed Tcl_FindExecutable the full path to the build-dir mged, it works
16:22.38CIA-43BRL-CAD: 03starseeker * r42243 10/brlcad/branches/cmake/src/ (gtools/g_diff.c tclscripts/archer/LoadArcherLibs.tcl): Restore some CMake branch tweaks I wiped out with the previous update.
16:40.57brlcadstarseeker: there's a separate bu routine to get the full path so perhaps the bug is calling bu_getprogname()
16:41.42brlcadbu_argv0_full_path()
16:42.50brlcadI believe bu_getprogname() was set up to mirror what getprogname() returns, which is just the name instead of the full path
16:47.00brlcad<PROTECTED>
16:47.00brlcad<PROTECTED>
16:47.01brlcadFailures:  95595 NMG, 99486 BoT
16:47.01brlcadNMG conversion:  84.2%  (508474 of 604069 objects)
16:47.01brlcadBoT conversion:  83.5%  (504583 of 604069 objects)
16:47.03brlcad<PROTECTED>
16:47.07brlcadhehe, that's just terrible :)
17:00.14CIA-43BRL-CAD: 03starseeker * r42244 10/brlcad/branches/cmake/src/mged/setup.c:
17:00.14CIA-43BRL-CAD: <smack> why'd I fix the bwish startup to account for the changes to the
17:00.15CIA-43BRL-CAD: libtclcad logic but not mged? Make mged init look more like the bwish init -
17:00.15CIA-43BRL-CAD: this whole setup probably needs review but mged should at least behave better
17:00.16CIA-43BRL-CAD: now. Archer still isn't happy yet.
17:10.25brlcadpoor CIA
17:11.10brlcadan hour and a half behind
17:34.32*** join/#brlcad Elrohir (~kvirc@p5B14B2AE.dip.t-dialin.net)
17:39.10brlcaddownloads 7.0.2
18:05.06CIA-43BRL-CAD: 03starseeker * r42245 10/brlcad/branches/cmake/src/mged/setup.c: OK, revert to the previous two pass code, but use bu_argv0_full_path instead of bu_getprogname to prevent the build dir mged from getting the path info from the installed mged.
18:07.04starseekerreturns from lunch
18:07.28starseekerbrlcad: yeah, stumbled onto argv0 and tested - works
18:07.38starseekeroh, heh - there's the commit message
18:30.50CIA-43BRL-CAD: 03brlcad * r42246 10/brlcad/trunk/src/halftone/main.c: fb.h for fb_common_file_size()
18:44.51starseekerah, there we go - thanks Sean for the examples of how to do it right.  Archer now runs from the build dir
18:52.57brlcadawesome
19:04.20CIA-43BRL-CAD: 03starseeker * r42247 10/brlcad/branches/cmake/src/bwish/ (cadAppInit.c main.c):
19:04.24CIA-43BRL-CAD: Migrate the btclsh/bwish logic back closer to the trunk. Of course, if we get
19:04.24CIA-43BRL-CAD: proper package require handling working for all of BRL-CAD these may reduce
19:04.25CIA-43BRL-CAD: entirely to setting up tcl and loading one .tcl file, but that's for later.
19:05.52CIA-43BRL-CAD: 03starseeker * r42248 10/brlcad/branches/cmake/src/archer/ (CMakeLists.txt archer): Follow Sean's lead with making Archer better about looking for files - archer now runs successfully from the build dir.
19:14.34brlcadahh, I remember those days... 7.0 built in about 2 min :)
19:15.23CIA-43BRL-CAD: 03erikgreenwald * r42249 10/rt^3/trunk/src/other/sqlite_3_7_4/CMakeLists.txt: conditionalize libdl based on OS (should probably be an explicit test eventually)
19:24.41CIA-43BRL-CAD: 03brlcad * r42250 10/brlcad/trunk/NEWS:
19:24.42CIA-43BRL-CAD: myself, daniel, and cliff arrived at a(n unverified) fix for the mged crash
19:24.42CIA-43BRL-CAD: reported by tom browder on the devel mailing list where it'd crash if you didn't
19:24.43CIA-43BRL-CAD: have one of the default editors installed due to unreliable strcmp() behavior
19:24.43CIA-43BRL-CAD: when provided NULL arguments. fix was propagated throughout brl-cad code with
19:24.50CIA-43BRL-CAD: new bu_strcmp() interface from daniel.
19:39.18starseekerhmm... may have spoken too soon
19:40.57starseekerarcher is using /usr/brlcad/ files
19:52.46starseekerbrlcad: I must still be doing something wrong :-(
19:56.43brlcadstarseeker: you can verify before by kicking of btclsh and running the same commands, test bu_brlcad_data with the parameters provided, for example
19:58.53starseeker<PROTECTED>
19:58.54starseekerbtclsh> bu_brlcad_data tclscripts
19:58.54starseeker/usr/brlcad/share/tclscripts
19:58.54starseekerbtclsh> bu_brlcad_data src
19:58.54starseeker./src
19:59.13brlcadyeah, that's the issue
19:59.21brlcadbu_brlcad_data tclscripts on trunk doesn't do that
19:59.37brlcadso something's different
20:00.01starseekergotta be me messing with libtclcad
20:00.04brlcadsushi:~/brlcad morrison$ src/bwish/btclsh
20:00.04brlcadUsing Tcl library at /Users/morrison/brlcad/src/other/tcl/library
20:00.04brlcadbtclsh> bu_brlcad_data tclscripts
20:00.07brlcad./src/tclscripts
20:07.44brlcadstarseeker: you can set BU_DEBUG_PATHS to see the actual start-up search logic being used
20:08.14starseekeris that a compile flag?
20:08.26brlcadrun-time flag
20:09.16starseekerso just export it into the environment?
20:09.42brlcadbtclsh> set bu_debug 0x1000
20:09.42brlcad0x1000
20:09.42brlcadbtclsh> bu_brlcad_root .  
20:09.42brlcadbu_brlcad_root: searching for [.]
20:09.42brlcadDoes [/usr/brlcad/dev-7.18.1] exist? NO
20:09.44brlcadDoes [lt-btclsh] exist? NO
20:09.47brlcadDoes [/usr/brlcad] exist? YES
20:09.50brlcadDoes [/usr/brlcad/.] exist? YES
20:09.52brlcadFound: /usr/brlcad default path [/usr/brlcad/.]
20:09.55brlcad/usr/brlcad/.
20:09.57brlcadbtclsh>
20:10.12starseekerO.o - would never have thought of set bu_debug 0x1000
20:10.28brlcadall the bu_debug flags are listed in bu.h
20:10.47brlcadalmost every tool exposes debug flags through -x and -X command-line options
20:11.10starseekerthe 0x1000 is a hex value?
20:12.45brlcadyeah
20:12.57brlcad-\! for bu debugging on most commands
20:13.14starseekerbrlcad: what's the sequence in your build tree for the search?
20:13.29brlcadrt -\!0x1  sets coredumping, for example
20:13.39brlcadwhich search?
20:13.46starseekerthe bu_debug
20:13.52starseekerroot
20:14.22brlcadsequence for what though?
20:14.47starseekerI guess it finds lt-btclsh before /usr/brlcad?
20:15.18starseekernevermind - I'll build trunk
20:18.46brlcadhttp://pastebin.mozilla.org/937127
20:20.39starseekerthanks :-)
20:21.16starseekerah - it's using the version number of brlcad
20:21.36starseekerthat could be one of my problems
20:22.23starseekerchecks to see whether he incorporated version numbers into his data setup...
20:22.25brlcad/usr/brlcad/dev-7.18.1 is my prefix for that build, but other prefixes should work too iirc
20:23.12brlcadthe only version incorporation are the tests on lines 3 and 53
20:23.20brlcadthe rest of the version numbers are just part of prefix
20:24.48starseekerit's looking for share/brlcad/7.18.1 though, not share/brlcad
20:25.12brlcadright
20:25.43brlcadsrc/libbu/brlcad_path.c
20:27.52brlcaduses BRLCAD_DATA if set, or BRLCAD_ROOT/share/brlcad/VERSION if unset .. those two should match, though since BRLCAD_DATA == ${bc_prefix}/share/brlcad/${BRLCAD_VERSION}
20:27.58brlcadfrom m4/prefix.m4
20:28.53starseekerhere's what I'm seeing:
20:28.54starseekerhttp://pastebin.mozilla.org/937149
20:29.16brlcadremember intentionally configuring the search logic so that there was a highly minimized chance of getting the wrong install of something, unless there really was just nothing else left to try
20:31.48brlcadif you have a /usr/brlcad/share/tclscripts then that sounds like that's a problem -- it's already so far down the failure list that it thinks it found a usable install
20:32.47brlcads/a problem/the problem/ .. if you actually have an install in the standard install place, then it's going to prefer that before it attempts to fall back on source installations
20:33.06starseekergreat.  I can't do anything about that
20:33.09brlcadit has to do that for proper user behavior, their paths come first, then devs
20:33.21starseekerisn't sure he agrees
20:33.39starseekerwould expect to try local files first, then installed
20:33.43brlcadI'm not sure I understand why you have a /usr/brlcad/share/tclscripts in the first place..
20:34.24brlcadthat'd be a security vulnerability
20:34.35brlcadapplications that try local files first can be easily exploited
20:35.32starseekerbut if we're running from a build directory, isn't using files in that build directory first reasonable?
20:36.04starseekerI agree if the binary is installed that makes sense, but if it's not installed...
20:36.05brlcadsure, but there's no reliable way to tell you're running from a build directory or someone who actually installed into their build directory
20:36.21brlcadyour build directory is another person's home directory
20:37.13starseekerhuh?  I've never seen anyone build using their homem directory toplevel
20:37.32brlcadbuild *into* thier home somewhere
20:38.05starseekersure - but if the build path and the install path are both known to the program, it knows exactly when it is installed and when it isn't
20:38.07brlcadI've done that plenty of times, seen others do it where install dir is a subdir under brlcad/src or brlcad/ or somewhere else
20:39.04brlcadonly the compile-time install path is known
20:39.04brlcadwhere the application actually ends up is not known
20:39.25brlcadyou have absolutely no guarantee that it'll end up in the install location and that's desirable (to the user) -- application relocatability
20:39.38brlcadthat's what lets you drag a mac app all around and it just works
20:40.25brlcada lot of work went into the current setup so it similarly works in a deterministic safe manner too
20:40.46starseekerthat's really a problem for development though - you can't develop on a machine that has an installed BRL-CAD
20:41.02brlcadI do it all the time without problem... :)
20:42.02brlcadthe log I showed you has an existing install and /usr/brlcad/{bin|share|man|etc} symlinks
20:42.53brlcadso again, my claim is that you should not have a /usr/brlcad/share/tclscripts unless you modified the install paths from what autoconf does
20:44.52brlcadif you think the search logic should change, feel free to write it down .. but I can pretty much guarantee a use case exposed to exploit if you look for dev paths before the existing search ordering .. bu.h has the high-level ordering
20:46.10starseekerOK, I'll buy that
20:46.22starseekerbut it means I'm stymed for now
20:48.51brlcadnot necessarily
20:49.03brlcadthe search ordering provides several ways to override
20:49.30brlcadyou still haven't read the search ordering in bu.h yet have you? :)
20:49.47starseekerI know, the environment variables
21:09.40CIA-43BRL-CAD: 03starseeker * r42251 10/brlcad/branches/cmake/CMakeLists.txt: We need to append the BRL-CAD version to the data install dir.
21:14.42brlcadnot strictly necessary -- the only requirement I think is that BRLCAD_ROOT/share/* should not be the same as BRLCAD_DATA/*
21:15.02brlcadthough having the version does match the autotools build presently
21:15.47brlcadit's on the build-system-to-do list, though to sort out multi-version installs vs single-version install defaults.  right now it's a mix of the two.
21:17.40starseekerwell, if you have a scheme in mind now's the time :-)
21:17.51starseekeris about ready to rip his hair out
21:18.01brlcadhaving a build option so that it will default to /usr/brlcad/{rel|dev}-VERSION for ROOT with DATA being simple "ROOT/share/brlcad" ;; and another option that inverts the version so you can install into ROOT as /usr/brlcad with DATA as ROOT/share/brlcad/VERSION
21:18.58brlcadthe latter being the one that would allow multi-version installs into a /usr prefix for example
21:21.22starseekernods
21:23.50brlcadwould be nice to have a version management system like 'alternatives' where there's a base root (e.g. /usr or /usr/brlcad) that has symlinks IN /usr/bin or /usr/brlcad/bin to some other place like /usr/share/brlcad/rel-7.20.2/bin/ and you could toggle the symlinks to different versions installed in a given location
21:24.40starseekercould probably add an option to add or not add the symlinks
21:27.01starseekerbrlcad: if I may, a stupid question - why do the debug flags require setting via hex numbers?
21:30.41``Erikdebug flags are designed as bit masks, so it's easiest to refer to them in hex... dunno if the parser can take decimal, but bitwise ANDing 32768 and 256 can be a bit tedious
22:14.19CIA-43BRL-CAD: 03brlcad * r42252 10/brlcad/trunk/src/conv/nastran-g.c: replace commas with a #define COMMA since multichar string literals are not valid to the preprocessor and will be caught more easily during compilation if they get expanded with a space.
22:15.41brlcadstarseeker: they are scanf("%x") iirc
22:18.40brlcadplus they are recorded in bu.h and raytrace.h in hex format where they are compact and it's easy to make sure there is no bitwise overlap -- so what you see in the public header is what you can feed to the application
22:41.59starseekercombines environment variable overrides with a test of a local share directory and sees (mostly) success
22:42.32starseekerso be it - the build tree will become a duplicate of the install tree, insofar as it's possible/sensible
23:04.13brlcadawesome, that'll make it really easy to test out a BRL-CAD.app
23:31.28CIA-43BRL-CAD: 03brlcad * r42253 10/brlcad/trunk/src/fb/ (cat-fb.c fbcolor.c pl-fb.c): more COMMA preprocessor conversions for safety
23:32.19CIA-43BRL-CAD: 03brlcad * r42254 10/brlcad/trunk/src/ (21 files in 13 dirs): cast size_t's to unsigned long ints during printing, use %zu if it's a bu_log or other bu_* routine since they have support for the 'z' size_t specifier.
IRC log for #brlcad on 20110114

IRC log for #brlcad on 20110114

00:11.54starseekerO.o  http://vimperator.org/vimperator
00:14.05starseekeris torn between a desire to try that and fear that a random key combination or the cat walking on the keyboard would result in changing the entire internet :-P
00:24.58``Erikneat
00:53.43CIA-43BRL-CAD: 03brlcad * r42255 10/brlcad/trunk/ (2735 files in 155 dirs): all hail the International Year of Forests, plant ourselves nicely into 2011. tree you later!
01:02.20*** join/#brlcad crazy_imp (~mj@a89-182-210-95.net-htp.de)
02:54.44``Erikhttp://www.youtube.com/watch?v=Ex5dhhpSHCw O.O
02:55.47``Erikd'no how good the overlay matching is, but yowza
02:58.22RalithAnybody know what happened to jonored's toolpathing utility?
03:02.50*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
03:15.52*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
03:31.07RalithWhere's the specification for the current binary database file format stored?
03:33.00``Eriksrc/brlcad/librt/ O.o
03:35.20``Erikhttp://brlcad.org/wiki/Documentation has a link to an old draft doc, but it's incomplete (and might even be slightly wrong on some things)
03:35.27``Erik#13 on that page
03:57.00Ralithsuspected that was the case; thanks.
03:57.39Ralith``Erik: so there's no complete doc beyond the code?
04:06.38``Eriknot that I know of... there've been things added and I don't think any docs have been updated to reflect the changes
04:17.44Ralithah well.
04:18.02RalithI hope libwdb is being kept in sync, at least.
06:02.55CIA-43BRL-CAD: 03brlcad * r42256 10/brlcad/trunk/src/mged/mged.c: some cleanup, simplification, and documenting of f_opendb().
06:04.38*** join/#brlcad kanzure_1 (~kanzure@bioinformatics.org)
06:06.58CIA-43BRL-CAD: 03brlcad * r42257 10/brlcad/trunk/src/mged/mged.c: use bu_booleanize() to test the value (even though we only looked for ynYN just earlier in this func to pass arg validation.
06:09.52brlcadRalith: the draft spec is probably more than 99% accurate -- but most access is supposed to go through API instead of directly anyways
06:10.21brlcadlibwdb is 100% in sync, it calls through to librt which IS the implementation
06:10.52brlcadlibwdb is for write-only access, librt is for slightly lower-level read/write access
06:11.09brlcadlibged is for high level read/write access
06:15.08RalithI see; thanks.
06:44.28*** join/#brlcad Stattrav (~Stattrav@122.172.16.143)
06:44.28*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:13.27CIA-43BRL-CAD: 03d_rossberg * r42258 10/brlcad/trunk/src/libbu/timetester.c:
10:13.27CIA-43BRL-CAD: there is no inttypes.h in MSVC
10:13.27CIA-43BRL-CAD: however it should not be necessary anyway, int64_t has to be declared via bu.h
10:50.00*** join/#brlcad mafm (~mafm@17.Red-83-40-127.dynamicIP.rima-tde.net)
11:32.20DaveLoyawns
12:27.01CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2403 10/wiki/Geometry_Service_Project_Main: Cleaned up verbage, removed some vague hints to functionality now that we are more concrete in our vision.
12:28.06DaveLoQuestion to brlcad: is it possible to get a GS:: namespace on the wiki?
12:41.05*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:45.59starseekerhmm... libpng 1.5.0 is out
12:46.18starseekerwonder if it's worth trying to upgrade... bet it breaks things
13:10.42CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:Developer 128px.png]]"
13:10.43CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:Users 128px.png]]"
13:19.03CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2406 10/wiki/Geometry_Service_User_Main: New page: Place Holder
13:20.07CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2407 10/wiki/Geometry_Service_Dev_Main: New page: Subbed in!
13:24.53CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2408 10/wiki/Geometry_Service_Project_Main: Add in some purty images in prep for cleanup/reorg
13:36.07DaveLoHrm, seems the BRL-CAD.org wiki wont accept the syntax for making [[Image: tags accept the |link= override parameter :/
13:36.13DaveLothats kinda annoying!
13:37.22CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2409 10/wiki/Geometry_Service_Project_Main: Add some to open up the page a bit (Temporary)
13:44.11CIA-43BRL-CAD: 03starseeker * r42259 10/brlcad/branches/cmake/ (10 files in 10 dirs): Start updating the CMake logic to re-create the installed file layout, insofar as practical. First step - header placement (cause there are fewer of these).
14:11.55*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
14:49.17brlcadDaveLo: it's a wiki.. so any namespaces, categories, taggings .. if they make sense, then go for it
14:56.59CIA-43BRL-CAD: 03starseeker * r42260 10/brlcad/branches/cmake/misc/CMakeLists.txt: local copy logic for db and misc - just have db build straight into the share dir target instead of the local binary dir, since they're built targets.
14:57.33CIA-43BRL-CAD: 03starseeker * r42261 10/brlcad/branches/cmake/doc/html/CMakeLists.txt: Make local copies of the html docs.
15:02.45CIA-43BRL-CAD: 03starseeker * r42262 10/brlcad/branches/cmake/doc/docbook/ (10 files in 10 dirs): Get docbook generation working in such a way that it puts files in the proper places for build-dir hierarchy.
15:03.20brlcadDaveLo: it's also mediawiki 1.11 so link= just some features might require upgrading to the latest mediawiki
15:03.46brlcads/just some/and some other/
15:06.12``Erikcrit has 1.16.1 :D
15:07.10DaveLoWell I ask about the namespace because one must do some editing of LocalSettings.php
15:07.14DaveLo....which I cannot.
15:10.04brlcadtwo questions
15:10.30brlcad1) why does creating a namespace require editing LocalSettings (or more specifically, what edit is needed?)
15:10.38brlcad2) what makes you think you cannot?
15:11.04DaveLohttp://www.mediawiki.org/wiki/Manual:Using_custom_namespaces
15:11.14DaveLothats the answer to #1
15:11.35DaveLoand #2 is:  I have no idea where the wiki server 'ware is installed, let alone if I have write perms to it.
15:11.47DaveLootherwise, I'd have done it already :)
15:12.06CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2410 10/wiki/Geometry_Service_Project_Main: Move links to user pages.
15:12.15CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2411 10/wiki/Geometry_Service_User_Main: Moved links from main page
15:12.49brlcadwhat's the benefit of a namespace over a category?
15:12.54brlcadthere's at least one downside ;)
15:13.34brlcadas for 2) it's in the web root and all perms are shared via the www user: sudo -u www
15:15.22DaveLoheh, well i thought that categories == namespaces.... but guess that aint so =D  *reads more*
15:15.38brlcaddecent page: http://www.packtpub.com/article/mediawiki-content-organizing-features-namespaces-categories
15:16.15brlcadnamespace benefit would be to prevent name collisions or assign specific security roles
15:16.24brlcadwhich I'm not sure is relevant/useful here
15:17.42brlcadwith an expanded role, I could see there being a "Geometry" namespace .. looks like it's well-suited for differentiating types of content ala mime typing
15:18.47brlcadcategory is as simple as adding [[Category:Geometry Service]] to each GS page
15:19.08DaveLookie cool, I think category tagging will work just fine.  danke!
15:20.33CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2412 10/wiki/Geometry_Service_User_Main: Remove Design Doc tag
15:20.36CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2413 10/wiki/Geometry_Service_Project_Main: Remove Design Doc tag
15:21.21CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2414 10/wiki/Geometry_Service_User_Main: Fix Category Tag
15:21.25CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2415 10/wiki/Geometry_Service_Project_Main: Fix Category Tag
15:29.07CIA-43BRL-CAD: 03bob1961 * r42263 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Move raytracePlus to the public section.
15:31.33CIA-43BRL-CAD: 03erikgreenwald * r42264 10/brlcad/trunk/src/mged/mged.c: avoid redefine on windows
15:41.49*** part/#brlcad willdye (~willdye@fern.dsndata.com)
16:00.01*** join/#brlcad willdye (~willdye@fern.dsndata.com)
16:08.47CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:GS Symbol.png]]": (Very) Rough first draft of the Geometry Service logo
16:19.34CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2417 10/wiki/Geometry_Service_Project_Main: Add graphic and section titles. Rearrange a bit. Im thinking the Implementation Particulars could go elsewhere......
16:22.37CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2418 10/wiki/Geometry_Service_Project_Main: Hrm, looks like a width var on the table is neeed for InternetExplorer
16:23.25CIA-43BRL-CAD: 03starseeker * r42265 10/brlcad/branches/cmake/db/CMakeLists.txt: Hmm, missed db dir in that commit.
16:24.33CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[IBME Main]]": Antiquated page. Superseded buy the Geometry Service pages
16:34.38DaveLolol, s/buy/by/
16:36.08CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2419 10/wiki/Geometry_Service_User_Main: Add graphic + table
16:37.58CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2420 10/wiki/Geometry_Service_Dev_Main: Add graphic + table + links
16:41.09CIA-43BRL-CAD: 03bob1961 * r42266 10/brlcad/trunk/ (18 files in 5 dirs): Mods for overriding the display manager's auto font selection mechanism. Implemented for ogl and wgl.
16:45.04*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
16:56.11CIA-43BRL-CAD: 03Dloman 07http://brlcad.org * r2421 10/wiki/URL_URI_URN_Implimentations: Updated URL page with current information
17:14.54*** join/#brlcad mafm_ (~mafm@17.Red-83-40-127.dynamicIP.rima-tde.net)
17:31.09DaveLohttp://www.youtube.com/watch?v=kKrtbUinWOU
17:47.12brlcadstarseeker: https://sourceforge.net/projects/brlcad/forums/forum/362510/topic/4053804
18:38.42CIA-43BRL-CAD: 03starseeker * r42267 10/brlcad/branches/cmake/ (12 files in 12 dirs): More logic for building up the share dir in the build tree.
18:41.48starseekerlooks like a bug in ted
18:42.14starseekerdoggone it, I'm sick of ted and red
18:55.25brlcadthe user might just be running an old buggy version, or it's still busted
18:56.04starseekerit's busted in 16.8 - I don't have a newer workign compile at the moment
18:56.54brlcadcan at least ask that user which version they're using since it "should" be fixed with the latest, then you can have them test if they're not on the latest
19:00.21starseekernods
19:02.11brlcadhas apparently worked more than 65 hours this week, and there's still more to go!
19:02.28starseekereeep!
19:06.35starseekerlooks forward to archer/mged making ted obsolete
19:10.49brlcadthat's a tough proposition even for archer/mged
19:11.14brlcadimplies some seriously well thought out usability and performance efficiency
19:12.35brlcadthere's ways to do everything ted can do now without a text editor, even bulk processing tools, but they're still just not as efficient as what an editor will let you do, in bulk, and programmably
19:12.53brlcadjust "ted" isn't the best way to do it
19:13.06CIA-43BRL-CAD: 03starseeker * r42268 10/brlcad/branches/cmake/ (5 files in 5 dirs): Tweaks to accomidate changes resulting from the new logic - get us building again.
19:26.36CIA-43BRL-CAD: 03brlcad * r42269 10/brlcad/trunk/ (5 files in 2 dirs): separate out the v4 database conversion routines that were oddly in tree.c out into their own db_float.c (since they mostly deal with converting to/from the dbfloat_t type).
19:45.35starseekeryeah, it's a current ted bug
19:47.53CIA-43BRL-CAD: 03starseeker * r42270 10/brlcad/branches/cmake/ (3 files in 3 dirs): Few more fixes to CMake logic.
19:50.12CIA-43BRL-CAD: 03erikgreenwald * r42271 10/rt^3/trunk/src/ (6 files in 3 dirs): start stubbing in stuff for a client side lib jar
19:50.24starseekerinteresting - ted is still in mged
20:02.10CIA-43BRL-CAD: 03brlcad * r42272 10/brlcad/trunk/ (5 files in 2 dirs): separate out rt_rpp_region() and rt_bound_tree() into bbox.c so we can consolidate bounding box routines into one place.
20:07.38CIA-43BRL-CAD: 03brlcad * r42273 10/brlcad/trunk/ (BUGS TODO): ted command needs fixing.
20:08.27CIA-43BRL-CAD: 03brlcad * r42274 10/brlcad/trunk/TODO: ability to open binary-incompatible v4 databases
20:08.57CIA-43BRL-CAD: 03brlcad * r42275 10/brlcad/trunk/src/librt/ (bbox.c shoot.c): move rt_in_rpp() into bbox.c given the related functionality, remove the rt_DB_rpp() debugging function.
20:10.43CIA-43BRL-CAD: 03starseeker * r42276 10/brlcad/trunk/ (NEWS src/mged/tedit.c):
20:10.43CIA-43BRL-CAD: editit in mged is returning TCL_OK, so check for that when using it in ted;
20:10.44CIA-43BRL-CAD: without that check, if statement was failing and readsolid was never being
20:10.44CIA-43BRL-CAD: called - this fixes issue reported by ogloth on the sourceforge forums.
20:11.32brlcadthat was quick
20:12.04starseekerluckly, the backtrace was easy to follow on that one :-)
20:13.02starseekerwas afraid it would turn into another red-command style rewrite...
20:15.28CIA-43BRL-CAD: 03brlcad * r42277 10/brlcad/trunk/ (BUGS TODO): ted was fixed quick by starseeker
20:17.20CIA-43BRL-CAD: 03johnranderson * r42278 10/jbrlcad/trunk/ (124 files in 26 dirs): jbrlcad is now a maven project.
20:19.49CIA-43BRL-CAD: 03johnranderson * r42279 10/jbrlcad/trunk/src/test/resources/ (. ktank.g logging.config test.asc test.g): Added test/resources.
20:25.55CIA-43BRL-CAD: 03johnranderson * r42280 10/jbrlcad/trunk/ (5 files in 5 dirs): Eliminated test and lib directories.
21:16.09CIA-43BRL-CAD: 03starseeker * r42281 10/brlcad/branches/cmake/src/libtclcad/tclcadAutoPath.c:
21:16.09CIA-43BRL-CAD: May be a few stray files remaining (need a systematic diff) but this is the last
21:16.10CIA-43BRL-CAD: major piece to create a duplicate of the installed share directory in the build
21:16.10CIA-43BRL-CAD: dir. tclcadAutoPath simpilfies down to a question of where the root and data
21:16.11CIA-43BRL-CAD: dirs are, if I'm understanding their usage correctly - I don't think I've got it
21:16.43CIA-43BRL-CAD: right yet but clearly this should simplify things dramatically.
22:10.49CIA-43BRL-CAD: 03erikgreenwald * r42282 10/brlcad/trunk/misc/win32-msvc8/libbu/libbu.vcproj: add booleanize
23:42.22*** join/#brlcad kanzure2 (~kanzure@131.252.130.248)
23:46.39CIA-43BRL-CAD: 03tbrowder2 * r42283 10/brlcad/trunk/src/libged/attr.c: sort attribute-value set array by attribute name
23:50.55CIA-43BRL-CAD: 03tbrowder2 * r42284 10/brlcad/trunk/NEWS: updated NEWS for adding sort to mged attr show command
IRC log for #brlcad on 20110115

IRC log for #brlcad on 20110115

00:01.49starseekerOooo http://www.mail-archive.com/pdcurses-l@lightlink.com/msg00129.html
00:02.04starseekerhttp://www.projectpluto.com/win32a.htm
00:04.53CIA-43BRL-CAD: 03tbrowder2 * r42285 10/brlcad/trunk/AUTHORS: added my name and details to developer list
00:06.31CIA-43BRL-CAD: 03brlcad * r42286 10/brlcad/trunk/NEWS:
00:06.32CIA-43BRL-CAD: tom added sorting to the mged attr show command so that attributes are now
00:06.32CIA-43BRL-CAD: displayed in alphabetical order instead of unsorted creation order. should
00:06.33CIA-43BRL-CAD: improve readability. rewording NEWS line to fit on one line (two line comments
00:06.33CIA-43BRL-CAD: are the exception when there are multiple authors) and moving to top of stack so
00:07.03CIA-43BRL-CAD: it's in proper chronological order.
00:08.33brlcadstarseeker: give it a try, pick one of the curses apps and try to compile against it by hand
00:09.00starseekernods
00:09.34starseekerwonders... if that works, why not combine it with something like the netbsd curses library to have one portable curses
00:10.13brlcadbecause we don't really use curses.. :)
00:10.35starseekerour build requires curses.h though
00:10.45brlcadwe use the predecessor that was absorbed into curses
00:11.02brlcadstrictly speaking, we don't need curses.h
00:11.10starseekerblinks
00:11.13brlcadit's sufficient, not required
00:11.22brlcadso we look for it
00:11.36starseekerwhat do we do if it isn't found?
00:11.58brlcadwe look for all the other various alternatives
00:12.06brlcadsurely you reviewed that part of configure.ac
00:12.17brlcadcmake needs the same logic
00:12.45starseekeryeah - I think I just call the find_package(Curses) logic
00:13.32brlcadwe have four main sections in configure.ac written for the search logic needed to do it right
00:14.00brlcadit's not equivalent to just search for curses by any stretch
00:14.09starseekermutter...
00:14.22starseekervotes we stuff curses in src/other and call it done
00:15.04brlcadif that's less work than adding in the header/lib checks, then the build system has something wrong with it
00:15.23brlcadcurses is way overkill
00:15.32brlcadwe already have libtermlib which is sufficient for all but windows
00:15.54starseekerah, so libtermlib is the fallback if all else fails?
00:16.13brlcadyou really should be more familiar with the configure.ac
00:16.15brlcadlocig
00:16.19brlcadlogic!
00:16.25starseekerthat part had me somewhat confused
00:16.42brlcadfour big sections, follow "curses"
00:18.56starseekersomething's gummed up then, 'cause I did a build on Linux with trunk (autotools) and it died due to not having any of the term related headers (iirc)
00:20.05starseekerah - both HAVE_NCURSES_H and HAVE_TERM_H were not defined
00:22.21brlcadnow if you could get *one* curses impl that was cross-platform, that might be a contender for replacing termlib, but it'd need to be small and basically portable to everything
00:22.28brlcadright now, windows is the only odd-ball out
00:22.35starseekernods
00:23.14brlcadpulling in that win32-specific pdcurses and pdcurses would be a bit ridiculous
00:24.00starseekershakes his head - pdcurses doesn't sound very good for unix/linux terminals
00:24.05brlcadsince termlib is already sufficient, already managed, and has been trivial to maintain
00:24.43starseekerperhaps we can bolt the win32 parts of that win32 native pdcurses onto libtermlib
00:25.23starseekerhrm - libcursor is failing because both of those two HAVE_* defines aren't set
00:25.32brlcadpossible, but it'd likely amount to a good bit of libtermlib work -- don't see it just dropping in
00:26.03brlcadlibcursor is ours
00:26.26starseekerright, but shouldn't it be falling back on libtermlib in the absence of the other two?
00:30.48starseekerO.o
00:30.51brlcadit does
00:30.58starseekernot here - build haulted
00:31.16brlcadwhich build?
00:31.22starseekertrunk, autotools
00:31.57brlcadyou have to look at the configure testing results
00:32.33brlcadwhether it thinks there's a usable library, headers, etc
00:33.18brlcadhow it ended up enabling/disabling termblib building
00:33.28starseekeroh, it's enabled
00:33.59brlcadit's got the most complex testing logic because it's the oldest dependency
00:34.48brlcadhuh, looks like a HAVE_TERMLIB_H define was removed at some point
00:35.31brlcadah, no I'm wrong -- it's still there
00:35.42starseekerbut am I understanding correctly that with libtermlib enabled, ncurses.h and term.h are not required?
00:35.53brlcadright
00:36.02starseekerso something is haywire
00:36.23brlcadit should be hitting line 3380, which turns on libtermlib aka termcap
00:37.26brlcadeverything you need should to figure it out should be in the config log
00:43.04starseekerthe termlib functionality tests failed, and libtermlib is enabled
00:45.00starseekerit's almost as if it's only looking at HAVE_NCURSES_H and HAVE_TERM_H without going to the else case on the HAVE_NCURSES_H test
00:49.12starseekerbrlcad: it IS turning on libtermlib, and building it.
00:50.08brlcadI presume you mean curses.c is failing compilation?
00:50.19starseekerhere's the failed configure test that turned it on:  http://pastebin.mozilla.org/941860
00:50.26starseekercursor.c
00:50.32starseekerin libcursor
00:50.35brlcadright, that's what I meant
00:51.16brlcadwell that error is certainly informative
00:51.44brlcadit's exactly why one should never ignore warnings
00:52.16*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
00:52.17brlcadit's directly reporting no less than two bugs, possibly more
00:52.26starseekeris the problem using if instead of ifdef?
00:59.10starseekerbingo
01:00.00starseekershakes his head - I thought perhaps you could get away with if or ifdef...
01:02.43*** join/#brlcad crazy_imp (~mj@a89-182-28-13.net-htp.de)
01:03.27CIA-43BRL-CAD: 03starseeker * r42287 10/brlcad/trunk/src/ (burst/Sc.c libcursor/cursor.c): Fixes to ifdef in cursor.c, expand the logic for Sc.c in burst.
01:04.57CIA-43BRL-CAD: 03starseeker * r42288 10/brlcad/trunk/configure.ac: fix if->ifdef in configure.ac too...
01:11.24starseekerO.o - that line in libcursor dates back to 2005... apparently a long time since someone's had a system config that hit that case
01:11.42starseekergets outta here before he gets in any worse trouble...
01:16.53brlcadyeah, that's very VERY curious that the preprocessor skips both the if AND the else clause because it's not defined
01:17.06brlcadbut then it warned about it too ;)
01:18.05brlcadthat's the first I've seen a preprocessor do that actually.. usually "if empty" will hit the else, that's probably why it never got caught
01:40.26``Erikinteresting, those metaball type errors I was seeing only show up in --enable-optimized
01:49.31*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:26.57brlcadyeah, all the uninitialized use warnings only occur during optimized too
02:54.52Ralithhm
02:54.56Ralithcan't seem to compile latest svn
03:09.45CIA-43BRL-CAD: 03tbrowder2 * r42289 10/brlcad/trunk/doc/docbook/system/mann/en/oed.xml: add note about using in a script
03:31.26CIA-43BRL-CAD: 03brlcad * r42290 10/brlcad/trunk/AUTHORS: rewrite the introduction with more details on the purpose and content of the authorship file.
03:39.14CIA-43BRL-CAD: 03brlcad * r42291 10/brlcad/trunk/AUTHORS:
03:39.14CIA-43BRL-CAD: not quite so fast... :) getting listed as a developer is reflective not
03:39.15CIA-43BRL-CAD: prospective. generally takes several hundred commits over sustained effort.
03:39.15CIA-43BRL-CAD: you can track progress at http://www.ohloh.net/p/brlcad/contributors in the
03:39.16CIA-43BRL-CAD: meantime (and you're already credited under code contributors).
03:39.31brlcadRalith: you have the power to fix that ;)
03:39.44Ralithbrlcad: yep, 'cept it didn't seem to be giving me an error O.o
03:39.48Ralithdoes make redirect stdout/stderr?
03:40.07brlcadmake doesn't, but gcc sends different messages to each
03:45.56CIA-43BRL-CAD: 03brlcad * r42292 10/brlcad/trunk/doc/docbook/system/mann/en/oed.xml: the 'e' command is discouraged in documentation, instead referring to its synonym, 'draw'
03:52.29Ralithwell, make was failing with no obvious output whatsoever :/
03:52.40Ralithis GBS still supported?
03:53.21CIA-43BRL-CAD: 03starseeker * r42293 10/brlcad/branches/cmake/ (CMakeLists.txt db/CMakeLists.txt doc/CMakeLists.txt): Few left over updates that didn't get committed from the home machine.
03:59.10starseekerwoot - broke into top 5 on ohloh
03:59.24starseekerdid they start tracking the CMake branch or something? :-P
04:09.02Ralithdebug mode didn't compile either O.o
04:20.34brlcadRalith: --disable-warnings
04:20.45brlcador fix whatever warning is halting the build
04:21.36brlcadstrict build is now enabled on several more directories so it'll be a little while as platforms we don't regularly test on get weeded out
04:27.47starseekerloooves merging in date changes...
04:28.04starseekerone at work apparently didn't go through, trying again
05:03.55CIA-43BRL-CAD: 03starseeker * r42294 10/brlcad/branches/cmake/ (2749 files in 159 dirs): Update cmake branch to trunk r42293. Also got some preliminary efforts at improving the libtermlib handling in the mix, but they aren't ready yet (probably don't work.)
05:08.11Ralithah.
05:29.26*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
06:09.14*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
06:09.14*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
07:10.37*** join/#brlcad PrezKennedy (MK@whitecalf.net)
08:34.30*** join/#brlcad WhiteCalf (~MK@whitecalf.net)
08:41.45*** join/#brlcad PrezKennedy (~MK@whitecalf.net)
08:53.40*** join/#brlcad WhiteCalf (MK@whitecalf.net)
08:58.52*** join/#brlcad WhiteCalf (MK@whitecalf.net)
09:18.51*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:42.28CIA-43BRL-CAD: 03tbrowder2 * r42295 10/brlcad/trunk/doc/docbook/articles/en/oed.xml: add info on used of oed when scripting
12:44.20CIA-43BRL-CAD: 03tbrowder2 * r42296 10/brlcad/trunk/doc/docbook/system/mann/en/qorot.xml: correct typo
12:50.22CIA-43BRL-CAD: 03tbrowder2 * r42297 10/brlcad/trunk/src/burst/Hm.c: quell warning about unused function HmPrntLList
12:58.09CIA-43BRL-CAD: 03tbrowder2 * r42298 10/brlcad/trunk/src/fb/cat-fb.c: remove duplicate assignment (which also quells compiler warning)
12:59.32CIA-43BRL-CAD: 03tbrowder2 * r42299 10/brlcad/trunk/src/librt/tree.c: correct typo
13:00.51CIA-43BRL-CAD: 03tbrowder2 * r42300 10/brlcad/trunk/src/util/bwcrop.c: add cast to unsigned to quell compiler warnings
13:02.11CIA-43BRL-CAD: 03tbrowder2 * r42301 10/brlcad/trunk/HACKING: correct typo; add missing word
13:04.18CIA-43BRL-CAD: 03tbrowder2 * r42302 10/brlcad/trunk/INSTALL: correct typo; grammar
13:50.39CIA-43BRL-CAD: 03tbrowder2 * r42303 10/brlcad/trunk/src/conv/g-xxx_facets.c: change main to standard form; add informative output about tesselation parameters
15:50.55CIA-43BRL-CAD: 03brlcad * r42304 10/brlcad/trunk/src/burst/Hm.c: dead code can be eliminated. revision control has our back.
15:51.13brlcadawesome browder :)
19:06.45CIA-43BRL-CAD: 03starseeker * r42305 10/brlcad/branches/cmake/src/other/CMakeLists.txt: That's not the way to handle libtermlib.
19:09.04starseekeris going to have to face the fact that he has at least one more major piece of work ahead of him for CMake...
19:14.56starseekerbrlcad: I've been studying the termlib logic, and one thing puzzles me a bit - why does the term.h header test need the other headers included?
19:50.18CIA-43BRL-CAD: 03erikgreenwald * r42306 10/brlcad/branches/bottie/ (3115 files in 225 dirs): MFC 42305
20:36.05*** join/#brlcad waprat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
20:42.05*** join/#brlcad epileg1 (~epileg@188.119.210.222)
21:08.08*** join/#brlcad CIA-29 (~CIA@208.69.182.149)
22:41.20*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
23:44.08*** join/#brlcad mafm_ (~mafm@12.Red-80-26-128.dynamicIP.rima-tde.net)
23:47.35*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20110116

IRC log for #brlcad on 20110116

00:12.45starseekerauuuuugh
00:12.58starseekersomehow the cmake tclscripts stuff didn't get committed
01:03.05*** join/#brlcad crazy_imp (~mj@a89-182-201-14.net-htp.de)
01:38.25CIA-29BRL-CAD: 03starseeker * r42307 10/brlcad/branches/cmake/src/other/libtermlib/CMakeLists.txt: Put etc/termcap in the BRL-CAD data dir, not a toplevel etc - remains to be seen if this will work, but if it can work it's the way to go.
01:39.10CIA-29BRL-CAD: 03starseeker * r42308 10/brlcad/branches/cmake/src/vfont/CMakeLists.txt: For completeness, duplicate vfont data in build tree.
01:40.58CIA-29BRL-CAD: 03starseeker * r42309 10/brlcad/branches/cmake/src/tclscripts/ (17 files in 17 dirs): Gah. Committed the libtclcad change, but didn't commit any of the CMakeLists.txt files that might have made it work. Change where things are put in the build tree for tcl scripts.
04:42.29CIA-29BRL-CAD: 03starseeker * r42310 10/brlcad/branches/cmake/CMakeLists.txt: For now we need Curses in the CMake build, but that needs to be fixed.
05:07.17*** join/#brlcad recyclops (~erin@cpe-024-163-114-145.nc.res.rr.com)
05:29.03CIA-29BRL-CAD: 03starseeker * r42311 10/brlcad/branches/cmake/src/tclscripts/geometree/CMakeLists.txt: Whoops, spelling error.
05:34.19CIA-29BRL-CAD: 03starseeker * r42312 10/brlcad/branches/cmake/src/libtclcad/tclcadAutoPath.c:
05:34.19CIA-29BRL-CAD: Have tclcadAutoPath look for share/brlcad/ - should have the same impact as
05:34.19CIA-29BRL-CAD: using bu_brlcad_root in the tcl scripts. This has the drawback of only allowing
05:34.19CIA-29BRL-CAD: the build dir executables to run when run from the build toplevel, so perhaps
05:34.19CIA-29BRL-CAD: the share/brlcad path should be augmented by knowledge based on the executable
05:34.19CIA-29BRL-CAD: path and the current working dir...
05:40.23CIA-29BRL-CAD: 03johnranderson * r42313 10/jbrlcad/trunk/ (4 files in 3 dirs): Runner script now uses maven dependency plugin to construct classpath.
06:02.16CIA-29BRL-CAD: 03brlcad * r42314 10/brlcad/trunk/BUGS: g2asc+asc2g of .g with colortable fails.
07:23.03CIA-29BRL-CAD: 03brlcad * r42315 10/brlcad/trunk/configure.ac:
07:23.03CIA-29BRL-CAD: really can't think of a better way to do this. suggestions? still need to
07:23.03CIA-29BRL-CAD: verify, but different versions of Mac OS X use different debug symbols types and
07:23.03CIA-29BRL-CAD: are not in sync with gdb (i.e., -ggdb3 doesn't work across library boundaries on
07:23.03CIA-29BRL-CAD: 10.4). cheat and call the sw_vers command to get the system version, used that
07:23.03CIA-29BRL-CAD: to test for a debug debug flag type.
07:34.04CIA-29BRL-CAD: 03brlcad * r42316 10/brlcad/trunk/ (BUGS src/libged/wdb_obj.c):
07:34.04CIA-29BRL-CAD: apply a fix for sf bug 3159020 reported by jra regarding asc2g's failure to
07:34.04CIA-29BRL-CAD: recognize the 'color' command. this was due to libged refactoring where 'db
07:34.04CIA-29BRL-CAD: color' was no longer valid. this fix restores the migrated commands as
07:34.04CIA-29BRL-CAD: subcommands of db, iterating over the list and running the command against the
07:34.05CIA-29BRL-CAD: current wdbp nad stashing the result. should once again be able to successfully
07:34.06CIA-29BRL-CAD: run: g2asc ktank.g new.asc && asc2g new.asc newtank.g
07:48.20CIA-29BRL-CAD: 03brlcad * r42317 10/brlcad/trunk/NEWS:
07:48.20CIA-29BRL-CAD: fixed asc2g color command lines. this is a fix for sf bug 3159020 reported by
07:48.20CIA-29BRL-CAD: jra where he showed g2asc + asc2g on ktank resulted in an error message. bug
07:48.20CIA-29BRL-CAD: was due to libged refactoring where 'db color' was no longer valid. the fix
07:48.20CIA-29BRL-CAD: restored several migrated commands as subcommands of db, iterating over the list
07:48.20CIA-29BRL-CAD: and running the command against the current wdbp nad stashing the result.
08:25.48CIA-29BRL-CAD: 03brlcad * r42318 10/brlcad/trunk/src/gtools/g_diff.c:
08:25.48CIA-29BRL-CAD: seems over-complicated, simplify. just compare the first to the second, and the
08:25.48CIA-29BRL-CAD: second to the first since all we do is print both if there's a difference. fix
08:25.48CIA-29BRL-CAD: two bugs in the process, one that caught colortable changes with g2asc + asc2g
08:25.48CIA-29BRL-CAD: of ktank when there were none due to resetting the wrong found1 var to zero in
08:25.48CIA-29BRL-CAD: the found2's loop. the second was printing color commands if we're v4.
08:28.31CIA-29BRL-CAD: 03brlcad * r42319 10/brlcad/trunk/NEWS:
08:28.32CIA-29BRL-CAD: discovered a bug in g_diff during the testing of jra's g2asc+asc2g ktank bug
08:28.32CIA-29BRL-CAD: report on colortables. it reported differences where there were none due to
08:28.32CIA-29BRL-CAD: resetting the wrong variable. also fixed a bug printing color lines for v4, but
08:28.33CIA-29BRL-CAD: much less noticable.
08:41.16Ralithhacking machine
08:44.12*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
09:49.46*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:09.34*** join/#brlcad mafm (~mafm@32.Red-83-49-86.dynamicIP.rima-tde.net)
14:22.58*** join/#brlcad electioneered (~erin@cpe-024-163-114-145.nc.res.rr.com)
15:05.01*** join/#brlcad electioneered_ (~erin@cpe-024-163-114-145.nc.res.rr.com)
15:50.20starseekerbrlcad: Can I suggest one file thing for bu_brlcad_root to try?  If a path is supplied and not found in the current dir, what about looking in bu_argv0_full_path() - bu_getprogname + ../ ?
15:51.12starseeker(i.e. if the invocation binary is /usr/weirdpath/bin/bwish, the last rule would look in /usr/weirdpath/bin/../
15:53.15starseekerthis would result in a build-dir BRL-CAD being runnable from anywhere the binary is invoked (if I'm thinking about this right) and offhand I'm not seeing how it's any more of a security problem than checking in the current dir after everything has failed.
15:53.58starseekerI'm willing to take a stab at implementing it, but wanted to run it by you first
16:17.26brlcadstarseeker: it already does that
16:17.34brlcadthird search
16:26.10starseekerbrlcad: that's only using bu_getprogname()
16:27.56brlcadnot exactly
16:31.03brlcadhm, actually you might have caught something there
16:31.12brlcadgetprogname used to return the full path
16:32.43brlcadso when the whereis search moved to a different function, bu_getprogname() isn't the right call any more
16:32.51brlcadroot is probably no longer became relocatable
16:33.01brlcadneeds some testing
16:34.41starseekerthis works for me:
16:34.43starseeker<PROTECTED>
16:34.43brlcadbecause what you suggest is the third (and most important) search path -- so need to verify what it's actually searching now and what that'll look like with a bu_argv0_full_path() replacement
16:34.43starseeker<PROTECTED>
16:35.59starseekerbu_argv0_full_path will return "." if you invoke in the same dir as the binary, which doesn't help
16:36.27brlcadthat sounds like a bug then, doesn't it?
16:36.35starseekerwas devoutely hoping so :-P
16:37.43starseekerwould be nice if I'm actually beginning to understand this...
16:38.06brlcadlike I said, have to diagnose exactly what it's doing presently before changing it in case the code is being misread
16:38.21brlcadspecifically, what that third test path looks like
16:40.07starseekerwhen I debug, it's always just the name of the program (bwish, mged, etc.)
16:43.42brlcadthat doesn't sound right
16:43.54brlcadwhat does the argv0 variable end up being?
16:44.29CIA-29BRL-CAD: 03starseeker * r42320 10/brlcad/branches/cmake/src/libbu/brlcad_path.c:
16:44.29CIA-29BRL-CAD: Have bu_brlcad_root take advantage of realpath - bu_getprogname returns no path
16:44.29CIA-29BRL-CAD: information now, and so is almost completely useless for this purpose. This
16:44.29CIA-29BRL-CAD: needs more testing and may not be the final 'approved' way to get this working,
16:44.29CIA-29BRL-CAD: so it's only going into CMake branch for now, but it works in every case tried
16:44.30brlcadthe bu_find_path for search 3
16:44.30CIA-29BRL-CAD: so far for both installed and build dir.
16:44.48starseekeruh, hang on - I'll revert back and try it
16:48.40brlcadthe path searching is critical to understand and get right, not just find something that seems to work
16:50.20brlcadsounds like you have a possible fix, just needs to be validated
16:51.10brlcadone problem though, is that you've added a memory leak
16:51.51starseekerargv0 as fed to bu_find_path for case 3 when starting bwish is:
16:51.53starseekerargv0: bwish
16:54.07brlcadokay, I can see that
16:54.22brlcadnever did like that manual trimming off of the binary name
16:56.06brlcaddo you see the memory leak?
16:56.46starseekeris looking
16:57.00starseekerchecking bu_dirname and realpath to see how they work...
16:57.07starseekeror is it more obvious than that?
16:57.25brlcadalso, no need to add another array
16:58.18brlcadahh, you removed argv0
16:58.49brlcadthe localized array fits the context better since it's just for that tests
16:59.12brlcadbu_dirname returns managed memory, so yeah, that's the problem
16:59.50brlcadcan do something similar to what the previous was doing, print into argv0, free the dirname, print into argv0, free the dirname
17:00.44brlcadhave to check whether bu_argv0_full_path() is managed memory or not too
17:03.09starseekerwait, if I don't have the real_path array where did you want to return the realpath results to?
17:03.52brlcad"ahh, you removed argv0"
17:04.11brlcadso you really just renamed the array and moved it to the top of the scope
17:04.40brlcaddon't care what it's named, but probably doesn't make sense at the top scope
17:05.21starseekeroh, got it
17:05.47starseekerthink I stuck it up there 'cause of some C90 complaint about having it lower
17:06.20brlcaddude, you are too funny
17:07.01brlcadyour knowledge is getting broad enough to be dangerous but only 2 inches deep  ;)
17:07.11brlcad"some c90 complaint" heh
17:08.07brlcaddon't fall victim to cargo cult programming: http://en.wikipedia.org/wiki/Cargo_cult_programming
17:09.20starseekerthe specific error was forbidding mixed declarations and code
17:09.31brlcadwhich means what? :)
17:09.52starseekerI had assumed it didn't like the array being declared in the middle of the function
17:10.07brlcadwell strictly speaking, that is true
17:10.28brlcadwhy didn't it complain about the previous argv0 array then?
17:10.38starseekerit was inside an if statement
17:11.34brlcadwhich is the start of a new scope, so you just need a new scope -- which you should have again if you check your return values
17:11.47brlcador you could have manually added a new scope even
17:14.41starseekernods
17:15.17starseekerdidn't think it made much of a difference (and I suppose if I'm honest I recall Bob moving a bunch of things to the top to make Windows happy...)
17:15.21brlcadraises another question -- is bu_dirname() or bu_argv0_full_path() capable of returning NULL?
17:15.47starseekerwill look - hang on, trying to rework to avoid the memory leak
17:15.51brlcadthey're moved to top of scopes, not arbitrary
17:16.23brlcaddeclarations after logic code will kick off an error only when compiling in strict c90 mode, which we don't so it'd even work for linux/mac
17:16.51brlcadbut now that warnings are errors, you can't ignore gcc (which was at least reporting the potential issue)
17:17.04starseekerright
17:17.30brlcadafter curlies, even mid-function, declarations are perfectly fine
17:17.34starseekerI knew it was top of scope, I just didn't attach enough importantce to keeping the declaration close to where it was used
17:18.17starseeker(and again to be honest, declaring a new scope mid-code was not something I would have thought of...)
17:18.21brlcadlocalized data is one of the best changes c++ made
17:18.43brlcadit usually doesn't matter
17:19.44brlcadit's when they're containers for data, particularly buffers of memory, that you run the risk of reuse bugs and memory management problems
17:20.07CIA-29BRL-CAD: 03starseeker * r42321 10/brlcad/branches/cmake/src/libbu/brlcad_path.c: Localize the real_path var, free bu_dirname results - still need to see if bu_argv0_full_path needs memory management help.
17:21.43starseekerbu_argv0_full_path will not return null (returns "(unknown)" if the header's got it right)
17:24.47brlcadokay, the header is the contract
17:24.50brlcadso you're good there
17:25.30starseekerI don't believe bu_dirname will return NULL - it's not documented as such, but looking at the code I'm not seeing where it would return NULL
17:25.56starseekerI can check for the NULL case regardless, but perhaps bu_dirname should be guaranteed not to return NULL?
17:26.25brlcadlooks like it can to me
17:26.47brlcadmaybe at least, since it calls getprogname
17:27.12starseekerbu_dirname?
17:27.14brlcadbut since it does a null check after, should fall back to (unknown) as well
17:27.28brlcadoh, dirname
17:27.43starseekerwhich ones did you ask about?
17:27.48starseekerscrolls up...
17:27.51brlcadthat's fine
17:28.46brlcadI think you're right
17:29.03starseekershould that be documented in the header then?
17:29.33brlcadsure
17:29.42brlcadlooks like the header also fails to mention memory management
17:30.24starseekeris that implied in "returns a pointer to dynamic string"?
17:30.29brlcadespecially since it deviates from dirname(2)'s behavior in that regard
17:30.35brlcadahh, yeah
17:31.09brlcadshould probably be more obvious, heh
17:31.21brlcad"Free your memoriees!!!11!"
17:31.40starseekernods
17:34.50brlcadbu_basename is wrong!
17:35.19starseekerwhat'd I do?
17:35.20CIA-29BRL-CAD: 03starseeker * r42322 10/brlcad/branches/cmake/include/bu.h: Clarify the documentation for bu_dirname, explicitly mention no NULL and responsibility to free memory.
17:35.35brlcadyou didn't do anything
17:35.38brlcadjust saying
17:35.45brlcadbu_basename is wrong :)
17:35.55starseekeroh, I see it
17:36.02starseekerbasename.c ?
17:37.14starseekeruh... will that work on Windows?
17:37.26brlcadwhat?
17:37.35starseekerexplicitly uses '/'
17:37.43starseekerisn't there a BU_DIR_SEPARATOR or some such?
17:38.38brlcadit should probably check BU_DIR_SEPARATOR, but didn't have windows to test it out on when it was being written
17:38.55starseekerah.  I take it you saw another problem?
17:39.12brlcadyeah
17:39.24brlcadbu_brlcad_root looks much better now
17:40.14brlcadyou going to fix bu_brlcad_data next? :)
17:41.07brlcad(just kidding)
17:41.18starseekerheh
17:41.40starseekerwas hoping bu_brlcad_data would follow once root was behaving
17:41.58brlcaddata calls root for that case
17:42.13starseekerI see one problem with bu_basename, I think - a/ won't return a
17:42.19brlcadbingo
17:42.54starseekerwill sync trunk then with the libbu cmake changes
17:43.28starseekerarguably, is a/ -> a expected?
17:43.33starseekerI suppose it is
17:44.11brlcadit's a drop-in replacement for basename(3), so it should
17:44.47brlcadI think the intent was even supporting cross-platform and no-NULL returns
17:45.13brlcadI have trouble believing that the code was originally written the way it is now..
17:46.04starseekerheh - well, since it explicitly returns NULL in once case that kinda nullfiies the non-NULL returns
17:46.29brlcadintent, not action :)
17:47.08brlcadbu_basename(NULL) is kind of weird
17:49.19brlcadbut sure enough, seems to have been originally written that way
17:49.50CIA-29BRL-CAD: 03starseeker * r42323 10/brlcad/trunk/ (include/bu.h src/libbu/brlcad_path.c): Fix the behavior of bu_brlcad_root for run-time path identification - was calling bu_getprogname, which no longer returns path information. Also expand header documentation for bu_dirname.
17:50.19starseekerbrlcad: does that fall into the user visible category?  It's kinda borderline
17:51.53CIA-29BRL-CAD: 03brlcad * r42324 10/brlcad/trunk/TODO: bu_basename() needs some love
18:00.11CIA-29BRL-CAD: 03brlcad * r42325 10/brlcad/trunk/include/bu.h: minor rewording since the type of free matters. plus remove the warning since it conflicts with the need to free the memory.
18:00.26brlcadstarseeker: I don't think so
18:01.12brlcadit fixes a bug, but not likely one that would have been noticed, and more importantly not a bug with the default install into a specified path
18:01.23starseekerthat's what I figured
18:01.48brlcadtechnically borderline, in that sense you're right, but not practically
18:03.05brlcadhttp://code.google.com/p/brl-cad-packages/
18:03.11starseekerby the way - there's a lot of logic in tclcadAutoPath specifically looking at either *_LIBRARY variables or hunting for tcl files - is that due to not being able to rely on the package require mechanism or are there users who actually override that stuff?
18:03.36brlcadyes
18:03.54starseekerheh
18:04.34brlcadand 3) different versions of *tcl behaving differently with how well they use auto_path, tcl var, or env(var)
18:04.57brlcadthe snippet I just added a few days ago for archer is a prime example
18:05.21brlcadtcl is ignoring auto_path AND tcl_library during "interp create"
18:05.27brlcadbut would respect TCL_LIBRARY
18:06.17brlcada bug only because it goes through really low-level init routines in tcl that bypass the usual stuff
18:06.45starseekerah - so if we did our stuff in a .tcl file that was loaded normally, we wouldn't see those issues?
18:07.09brlcadactually, for that particular case, I'm not so sure
18:07.41brlcadarcher uses sub-interpreters for some command processing, which gets tricky
18:08.27brlcadif it was system tcl, sure -- because the default low-level searching is basically looking where it was supposed to be installed
18:09.21brlcadsimilar to our bu_brlcad_* routines actually -- just it was failing to perform a few searches that their docs say it should be performing
18:09.37brlcadgood stuff: http://code.google.com/p/brl-cad-packages/downloads/list
18:09.58starseekerhah, sweet
18:11.21starseekercan we at least either ditch the tclcad_tcl_library function or rework it somehow?
18:12.06starseekerit looks like with that bu_brlcad_root fix I might be able to just use the existing logic from trunk, except for that function
18:14.13brlcadcan give it a try
18:14.20starseekerponders... hmm, I wonder if we really need those internal C calls...
18:14.38starseekerto the Tcl docs
18:16.28brlcadif mged runs and starts cleanly from a variety of installs, we're probably good -- the only thing I'd worry about is relying on 8.6 behavior for something that might not work in 8.5
18:16.37brlcadright now 8.5 is our minimum req
18:16.56brlcadupgrading that to 8.6 might take us out of some package management systems
18:18.37starseekeruh... does tclcad_tcl_library help us avoid requiring 8.6?
18:19.09starseekerhas never actually had a successful BRL-CAD run with tcl/tk 8.6, actually
18:19.19starseekers/never actually/never
18:23.01starseekerhmm, actually I may stand corrected - it's using Tcl internals, but the real trouble might have been the itcl/itk headers
18:23.15starseekerdoes some experiments in trunk
18:25.13starseekerriping out supports to see how the bridge crashes down...
19:29.52starseekeryeah, still valid concern on the use of internal functions but the build-haulting issues were due to itcl/itk header inclusion
19:31.27CIA-29BRL-CAD: 03starseeker * r42326 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: Tweak includes for tclcadAutoPath.c - I think this may be a version both the CMake build and autotools build can live with, but needs more testing.
19:33.10CIA-29BRL-CAD: 03starseeker * r42327 10/brlcad/branches/cmake/src/libtclcad/tclcadAutoPath.c: Sync tclcadAutoPath.c with trunk's version - trying to get a version both can live with/use.
20:49.34CIA-29BRL-CAD: 03starseeker * r42328 10/brlcad/branches/cmake/ (17 files in 12 dirs): Update cmake branch to trunk r42327
20:53.36*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
20:53.36*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
20:56.32CIA-29BRL-CAD: 03starseeker * r42329 10/brlcad/branches/cmake/src/other/libtermlib/CMakeLists.txt: Put the termcap stuff where it belongs.
21:11.00CIA-29BRL-CAD: 03starseeker * r42330 10/brlcad/branches/cmake/ (930 files in 930 dirs):
21:11.00CIA-29BRL-CAD: Sure as heck don't want to merge THIS change into trunk, but in principle the
21:11.00CIA-29BRL-CAD: CMake branch should be leaving a pristine tree behind it. Set all svn ignore
21:11.00CIA-29BRL-CAD: properties to empty - if I got this right we should see ANY files that appear in
21:11.00CIA-29BRL-CAD: the source branch after a build.
21:14.24CIA-29BRL-CAD: 03brlcad * r42331 10/brlcad/trunk/AUTHORS: special thanks to jordi sayol for making 32-bit and 64-bit .deb files for release 7.18.0
21:18.36CIA-29BRL-CAD: 03starseeker * r42332 10/brlcad/trunk/misc/enigma/ (Makefile.am crypt.c enigma.c):
21:18.36CIA-29BRL-CAD: The enigma stuff from CMake should be harmless - trunk doesn't build enigma on
21:18.36CIA-29BRL-CAD: Windows, and it would need the stuff if it did - even though this isn't working,
21:18.36CIA-29BRL-CAD: it's at least a start. Sync it to bring the two branches closer.
21:20.22brlcado.O ... brlcad_config.h ?
21:20.43brlcadshouldn't ever be including that file directly
21:20.51brlcaddistcheck should have caught that
21:22.40starseekerah, my bad
21:24.10CIA-29BRL-CAD: 03starseeker * r42333 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: Whoops - don't include brlcad_config.h directly.
21:34.21CIA-29BRL-CAD: 03starseeker * r42334 10/brlcad/branches/cmake/ (5 files in 4 dirs): Sync cmake to trunk r42333.
21:36.05CIA-29BRL-CAD: 03starseeker * r42335 10/brlcad/branches/cmake/AUTHORS: Hmm, AUTHORS wasn't fully synced. fix
21:48.17CIA-29BRL-CAD: 03starseeker * r42336 10/brlcad/branches/cmake/src/tclscripts/ (23 files in 12 dirs): Add canned pkgIndex.tcl files and tclIndex files from trunk - won't need them for CMake (if the generation routines work correctly) but trunk needs 'em.
21:51.28CIA-29BRL-CAD: 03starseeker * r42337 10/brlcad/branches/cmake/src/util/pixrect.c: pixrect.c change slipped through.
21:52.15CIA-29BRL-CAD: 03starseeker * r42338 10/brlcad/branches/cmake/src/other/libz/ (12 files): No significant differences here, but sync to avoid cluttering diffs.
21:59.20CIA-29BRL-CAD: 03starseeker * r42339 10/brlcad/branches/cmake/src/other/libz/contrib/minizip/Makefile: Add file present in trunk
22:02.36CIA-29BRL-CAD: 03starseeker * r42340 10/brlcad/branches/cmake/src/other/libz/contrib/iostream2/zstream.h: another minor sync from libz
22:18.41CIA-29BRL-CAD: 03starseeker * r42341 10/brlcad/trunk/ (7 files in 7 dirs): Put iwidgets in the incrTcl subdirectory, since they're associated with that proejct.
22:21.17CIA-29BRL-CAD: 03starseeker * r42342 10/brlcad/trunk/src/other/incrTcl/Makefile.am: Whoops, use the variable.
22:24.00CIA-29BRL-CAD: 03starseeker * r42343 10/brlcad/trunk/src/other/ (Makefile.am incrTcl/Makefile.am): Move itcl into the incrTcl subdir as well.
22:25.09CIA-29BRL-CAD: 03starseeker * r42344 10/brlcad/trunk/src/other/incrTcl/Makefile.am: change ITCLDIR to actually be the itcl dir.
22:31.34CIA-29BRL-CAD: 03starseeker * r42345 10/brlcad/branches/cmake/ (6 files in 6 dirs): Grab some of the changes from trunk - incrTcl is hopelessly messed up between cmake and trunk, so will probably have to script out CMake's and put trunk's in place.
22:34.42CIA-29BRL-CAD: 03starseeker * r42346 10/brlcad/branches/cmake/src/other/incrTcl/iwidgets/.cvsignore: stray .cvsigonre file
22:40.29RalithIs there some way to get a sketch corresponding to the intersection between a plane and a region?
22:43.36brlcadRalith: depends what kind of sketch
22:43.48starseekerum... intersect a thin arb8 with the region and use rtedge?
22:43.49brlcadyou can get a cross-section hidden-line rendering very easily
22:44.31brlcadstarseeker: curious move with iwidgets...
22:44.45starseekerit's associated with the incrtcl project on sourceforge
22:44.47brlcadthey're certainly related, but iwidgets isn't part of incrTcl
22:45.05Ralithbrlcad: I mean as in a sketch primitive
22:45.26brlcadRalith: then no, not outside of manual methods
22:45.31Ralith:/
22:45.39brlcadhttp://incrtcl.cvs.sourceforge.net/incrtcl/
22:45.42brlcadseparate module
22:46.01brlcadwould be like putting rt^3 underneath a brlcad checkout
22:46.10brlcadthey're related, but not in that way
22:46.18starseekerhmm.
22:46.31brlcadno biggie either way, just odd
22:46.48brlcadsrc/other/incrTcl is no longer the incrTcl source tarball
22:47.05starseekerour trunk incrTcl hasn't been for a long time, as understand it
22:47.11starseeker``Erik made a lot of changes
22:47.30brlcadquantify "a lot"
22:47.54starseekerI'd have to do diffs - was based on conversation with him at work about it
22:47.55brlcadwe have a Makefile.am, and maybe a dozen lines
22:48.04starseekerhe said he pulled stuff out of cvs
22:48.09starseekernot just the tarballs
22:48.36starseekerCMake branch does use the vanilla source - that's what prompted the itk_defines.tcl file for archer
22:48.38brlcadthat's not a lot of mods then
22:49.03brlcadsource tarball == source checkout in this particular instance, doesn't matter that the .tar.gz is out of date
22:49.11brlcadtheir code vs our code
22:49.52brlcador if it suits the conversation better, "our trunk incrTcl is no longer an incrTcl source checkout (+ our Makefile.am)"
22:50.08starseekerok
22:50.56brlcadlike I said, minor point, I don't care strongly on it
22:50.57starseekerso do I have your OK to make incrTcl a vanilla cvs checkout/tarball + Makefile.am?  That's what I'd prefer to do, and then work around issues using itk_defines.tcl and the like
22:51.34brlcadthat's close to what it is now
22:51.56brlcadif it's not, sure
22:52.00starseekersweet
22:52.07starseekerI'll revert back to the original structure then
22:53.54brlcadlooking through the logs, the only recent mod I see other than our Makefile.am, was to make it work with tcl/tk 8.4 out of the box, 8.4 compat headers
22:54.22brlcadrequirement is since upped to 8.5, so no longer relevant
22:54.27starseekernods
22:55.41brlcaderik's upgrade to cvs was in 2007
22:56.24starseekeralrightie
22:56.53starseekergiven a choice between tarballs and cvs, do you have a preference?
22:57.04brlcadcvs
22:57.23brlcadunless they updated the tarball recently
22:57.58starseekernot really - 2009 for itcl
22:58.16brlcadso it's at least a tarball 2 years newer, but still 2 years behind
22:58.39brlcadnot beenmany commits since then
22:58.54starseekernope - what new work has been going on I think is in the 4.0 branch
22:58.54brlcadbut does have an updated TEA
22:59.02brlcadhttp://www.ohloh.net/p/incrtcl/commits
22:59.11brlcad5 commits
22:59.35brlcadcould ask them which they recomment
22:59.37brlcadcould ask them which they recommend
22:59.47brlcadbut I suspect 4.0 is going to req. 8.6
22:59.52starseekeryes
23:00.02starseekeruses the new tclOO setup, iirc
23:01.45brlcadif it gave us some benefit, I'd say go for it .. but i'm not sure there is any yet
23:01.59brlcadby the time they're done, it might just get absorbed
23:02.35starseekerwhich, 4.0?
23:02.43brlcadhmmm... this one might need to be kept or pushed upstream:  svn log -r27960:27959 src/other/incrTcl
23:02.47brlcad4.0
23:03.44starseekeryeah, I don't think we're ready for 8.6 yet
23:04.09starseekerwould vastly prefer to not be using the C itcl/itk api for the next run at 8.6
23:05.12brlcadwow .. I apparently made that change, but totall don't remember it
23:05.51brlcadthe crash I vaguely recall, and it was hard -- so should be easy to see if the patch is still needed
23:06.52starseekerhas half a notion to ditch the mess for tkpng in LoadArcherLibs.tcl and require that package require tkpng Just Work... ick
23:07.25brlcadthat's how it should be
23:07.34brlcadthe loading of the .so directly was just a halfassing
23:09.46starseekerbrlcad: do you recall if we tried to push the itcl patch upstream at the time?
23:21.27CIA-29BRL-CAD: 03starseeker * r42347 10/brlcad/trunk/ (687 files in 19 dirs): Put iwidgets back - might as well match the incrTcl cvs project hierarchy.
23:33.06starseekermutter - looks like we still need that patch
23:33.54starseekerbrlcad: it wasn't something about the way we were doing itcl/itk logic that could be changed?
23:34.26starseekermust admit it doesn't look like it based on C patches
23:36.41CIA-29BRL-CAD: 03starseeker * r42348 10/brlcad/trunk/src/tclscripts/archer/LoadArcherLibs.tcl: Use package require tkpng. If it's not working, let's figure out why.
23:38.42CIA-29BRL-CAD: 03starseeker * r42349 10/brlcad/branches/cmake/ (6 files in 6 dirs): Put itcl/itk logic back, pull in trunk's LoadArcherLibs.tcl.
23:40.49starseekerOdd... I'm using system tcl/tk and itcl/itk here, and Archer is coming up and will bring up the preferences dialog... I think we took out the comb editor in its old form, so probably can't test that...
23:42.06starseekerah, mged
23:47.54starseekerwith system itcl/itk and tcl/tk on gentoo combination editor comes up, but of course they may be patched
23:49.08starseekerhuh, weird
23:55.01starseekerdon't see a patch specific to that issue... may be missing it
23:55.14starseekergoes on dinner run
IRC log for #brlcad on 20110117

IRC log for #brlcad on 20110117

01:03.27*** join/#brlcad crazy_imp (~mj@a89-182-3-165.net-htp.de)
01:05.27CIA-29BRL-CAD: 03johnranderson * r42350 10/brlcad/trunk/src/util/Makefile.am: bwhist needs libbu.
01:09.46CIA-29BRL-CAD: 03johnranderson * r42351 10/brlcad/trunk/ (26 files in 5 dirs): fixed a bunch of size_t issues.
01:55.21CIA-29BRL-CAD: 03johnranderson * r42352 10/brlcad/trunk/src/conv/asc/g2asc.c:
01:55.21CIA-29BRL-CAD: The region color table is no longer output as part of the GLOBAL object.
01:55.21CIA-29BRL-CAD: If no attributes of the GLOBAL object are output, the GLOBAL object itself is not output.
01:55.21CIA-29BRL-CAD: fixed some size_t issues.
02:37.41CIA-29BRL-CAD: 03starseeker * r42353 10/brlcad/branches/cmake/ (30 files in 8 dirs): Update cmake to trunk r42352
02:44.15brlcadstarseeker: I don't remember what the problem was beyond what's in the commit log
02:44.32brlcadvague recollection that tcl/tk had to be patched too so there might be a commit log message there with more info
03:52.51CIA-29BRL-CAD: 03johnranderson * r42354 10/brlcad/trunk/doc/docbook/log4j.properties: Added a configuration for log4j to stop the constant blather about it not being configured.
04:49.52CIA-29BRL-CAD: 03starseeker * r42355 10/brlcad/trunk/src/other/incrTcl/ (4 files in 4 dirs): Tcl 8.4 doesn't cut it anymore, so we shouldn't need the compat headers.
04:53.49CIA-29BRL-CAD: 03starseeker * r42356 10/brlcad/trunk/src/other/incrTcl/makefile.bc: makefile.bc isn't present in cvs incrtcl anymore.
05:23.33CIA-29BRL-CAD: 03starseeker * r42357 10/brlcad/trunk/src/other/incrTcl/ (13 files in 5 dirs): Start merging in changes from latest cvs incrTcl - will try to do this carefully, as there are a few changes that will need to be preserved.
05:27.58starseekerhah - itcl/itk upstream DID take the patch
05:28.01starseekerhttp://incrtcl.cvs.sourceforge.net/viewvc/incrtcl/incrTcl/itcl/generic/itcl_methods.c?r1=1.20&r2=1.21
05:28.13starseekersweet
05:34.13CIA-29BRL-CAD: 03starseeker * r42358 10/brlcad/trunk/src/other/incrTcl/itcl/ (14 files in 5 dirs): Remainder of changes from itcl subdir - itcl/itk upstream applied changes made to itcl_methods.c, so they are no longer a local BRL-CAD mod.
05:35.35CIA-29BRL-CAD: 03starseeker * r42359 10/brlcad/trunk/src/other/incrTcl/itcl/doc/Makefile.am: Add new man pages to makefile.am
05:37.18CIA-29BRL-CAD: 03starseeker * r42360 10/brlcad/trunk/src/other/incrTcl/itk/ (4 files in 3 dirs): Just a few changes in the itk subdir
05:42.32CIA-29BRL-CAD: 03starseeker * r42361 10/brlcad/trunk/src/other/incrTcl/ (9 files in 2 dirs): Most of the remaining changes should be captured here.
05:45.53CIA-29BRL-CAD: 03starseeker * r42362 10/brlcad/trunk/src/other/incrTcl/ (4 files in 4 dirs): Files not present in cvs incrTcl
05:48.49CIA-29BRL-CAD: 03starseeker * r42363 10/brlcad/trunk/src/other/incrTcl/itk/library/pkgIndex.tcl: Probably need this pre-generated file for our current Windows build...
05:55.48starseekerthat must be why my system setup is working...
05:56.24CIA-29BRL-CAD: 03starseeker * r42364 10/brlcad/trunk/src/other/iwidgets/ (246 files in 11 dirs): Sync iwidgets with latest cvs - mostly whitespace in this one.
05:59.02CIA-29BRL-CAD: 03starseeker * r42365 10/brlcad/trunk/src/other/iwidgets/pkgIndex.tcl.in: Ah, right - use our variable.
06:01.02CIA-29BRL-CAD: 03starseeker * r42366 10/brlcad/trunk/src/other/iwidgets/iwidgets.tcl.in: Use our version of iwidgets.tcl.in too
06:03.25CIA-29BRL-CAD: 03starseeker * r42367 10/brlcad/trunk/src/other/iwidgets/ (Makefile.am tcl.m4): Remove tcl.m4 - no longer in cvs.
06:09.55CIA-29BRL-CAD: 03starseeker * r42368 10/brlcad/branches/cmake/src/other/incrTcl/ (8 files in 6 dirs): Wipe the incrTcl slate clean in CMake branch. Need to get trunk's version in here and working.
06:18.25CIA-29BRL-CAD: 03starseeker * r42369 10/brlcad/trunk/src/other/incrTcl/itcl/generic/itclInt.h: We still need common.h in itclInt.h
06:24.20CIA-29BRL-CAD: 03starseeker * r42370 10/brlcad/branches/cmake/src/other/incrTcl/ (189 files in 22 dirs): Put trunk's version of incrTcl in cmake - need to add back in CMake logic.
06:29.36CIA-29BRL-CAD: 03starseeker * r42371 10/brlcad/branches/cmake/src/other/incrTcl/ (15 files in 4 dirs): Restore old CMake logic
06:32.33CIA-29BRL-CAD: 03starseeker * r42372 10/brlcad/trunk/src/util/bw-imp.c: Cast size_t to int for printing.
06:37.08CIA-29BRL-CAD: 03starseeker * r42373 10/brlcad/trunk/src/other/incrTcl/ (Makefile.am itk/Makefile.am): Update incrTcl makefiles
06:42.49CIA-29BRL-CAD: 03starseeker * r42374 10/brlcad/branches/cmake/src/other/ (346 files in 15 dirs): Add iwidgets dir from trunk
06:50.05CIA-29BRL-CAD: 03starseeker * r42375 10/brlcad/branches/cmake/src/other/incrTcl/itcl/CMakeLists.txt: Mutter - need the brlcad include dir due to common.h inclusion
06:58.31CIA-29BRL-CAD: 03starseeker * r42376 10/brlcad/branches/cmake/src/other/incrTcl/itk/CMakeLists.txt: itk needs common.h too
07:04.00CIA-29BRL-CAD: 03starseeker * r42377 10/brlcad/branches/cmake/ (6 files in 6 dirs): Update cmake branch to trunk r42376
07:27.22*** join/#brlcad WhiteCalf (MK@whitecalf.net)
07:33.24CIA-29BRL-CAD: 03starseeker * r42378 10/brlcad/trunk/ (4 files in 3 dirs): autotools build needs a pkgIndex.tcl for tkpng, provide it.
07:35.34CIA-29BRL-CAD: 03starseeker * r42379 10/brlcad/branches/cmake/ (6 files in 4 dirs): Sync cmake to trunk r42378
07:39.01CIA-29BRL-CAD: 03starseeker * r42380 10/brlcad/trunk/ (configure.ac src/other/tkpng/generic/tkImgPNGInit.c): Go with 0.8, since that was what was in the source file - bit confusing, since the ChangeLog seems to have tagged 0.9?
07:40.39CIA-29BRL-CAD: 03starseeker * r42381 10/brlcad/branches/cmake/ (4 files in 3 dirs): sync cmake to r42380
07:46.07CIA-29BRL-CAD: 03starseeker * r42382 10/brlcad/branches/cmake/AUTHORS: Thought I got this - sync CMake copy of AUTHORS file.
07:56.16CIA-29BRL-CAD: 03starseeker * r42383 10/brlcad/branches/cmake/src/gtools/g_diff.c: Put the trunk version of g_diff back, now that we're using trunk's tclcad
07:57.01starseekerah, getting down to the last pieces, mostly having to do with config header files and using package require Itcl instead of C apis
09:10.04*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
09:57.50*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
11:55.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:33.49*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
12:38.48*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
12:41.12*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
12:45.48*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
12:47.44*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
12:50.59*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
12:56.06*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
12:58.39*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:05.04*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:06.51*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:09.19*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:10.27*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:12.41*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:17.22*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:21.58*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:25.23*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:31.54*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
13:31.59*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:35.03*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:39.22CIA-29BRL-CAD: 03starseeker * r42384 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c: Typo.
13:40.40*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:44.39*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:44.53CIA-29BRL-CAD: 03starseeker * r42385 10/brlcad/branches/cmake/src/mged/setup.c: Try to move mged's setup.c closer to trunk version.
13:50.13*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
13:54.50*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
14:00.25*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
14:07.06*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
14:08.19CIA-29BRL-CAD: 03starseeker * r42386 10/brlcad/trunk/src/mged/ (attach.c cmd.c setup.c): Try using the package require statements for itcl/itk in MGED.
14:09.42CIA-29BRL-CAD: 03starseeker * r42387 10/brlcad/trunk/doc/docbook/Makefile.am: Add log4j.properties to EXTRA_DIST
14:10.25*** join/#brlcad mafm (~mafm@215.Red-88-18-68.staticIP.rima-tde.net)
14:14.05CIA-29BRL-CAD: 03starseeker * r42388 10/brlcad/trunk/src/other/ (4 files in 4 dirs): Changes to allow CMake + Visual C++ to work on Windows - should have zero impact on any build except CMake.
14:15.02CIA-29BRL-CAD: 03starseeker * r42389 10/brlcad/branches/cmake/src/other/ (6 files in 6 dirs): Wrap the CMake generated headers in a define that is only set in the CMake build.
14:28.02CIA-29BRL-CAD: 03starseeker * r42390 10/brlcad/branches/cmake/src/bwish/main.c: Tweaks
14:29.52CIA-29BRL-CAD: 03starseeker * r42391 10/brlcad/trunk/src/bwish/ (cadAppInit.c main.c): Try using package require for itcl/itk in bwish
14:31.11CIA-29BRL-CAD: 03starseeker * r42392 10/brlcad/trunk/src/libtclcad/tclcad.c: Same deal for tclcad.c - try using package require.
14:35.40CIA-29BRL-CAD: 03starseeker * r42393 10/brlcad/branches/cmake/src/ (5 files in 2 dirs): Put itk_redefines.tcl with the other archer tcl scripts
14:37.37CIA-29BRL-CAD: 03starseeker * r42394 10/brlcad/branches/cmake/src/tclscripts/archer/CMakeLists.txt: Put lower case at end, bit easier to find things.
14:38.28CIA-29BRL-CAD: 03starseeker * r42395 10/brlcad/trunk/src/ (3 files in 2 dirs): Put itk_redefines.tcl into trunk version of archer
14:49.10*** join/#brlcad Stattrav (~Stattrav@117.202.27.44)
14:49.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:49.58CIA-29BRL-CAD: 03starseeker * r42396 10/brlcad/trunk/include/ (Makefile.am config_win_cmake.h): Add a config_win header that will work with cmake - for now this looks like the simplest way to make both systems happy, but eventually config_win_cmake.h will become config_win.h
14:50.46CIA-29BRL-CAD: 03starseeker * r42397 10/brlcad/branches/cmake/ (4 files in 2 dirs): Use config_win_cmake.h for CMake build.
14:54.03CIA-29BRL-CAD: 03starseeker * r42398 10/brlcad/branches/cmake/ (6 files in 6 dirs): Update cmake to trunk r42397
15:01.00CIA-29BRL-CAD: 03starseeker * r42399 10/brlcad/trunk/include/common.h: Tweak common.h from CMake and add to trunk.
15:03.30CIA-29BRL-CAD: 03starseeker * r42400 10/brlcad/branches/cmake/ (. CMakeLists.txt include/common.h src/other/tkhtml/): Hopefully this will allow the same common.h to be used in both cmake and autotools.
15:05.41starseekerand if everything's working, that should do it
15:06.00starseekerexcept for the CMake logic, that ought to sync both trees
15:06.11starseekernow for distcheck, etc.
15:34.29CIA-29BRL-CAD: 03starseeker * r42401 10/brlcad/trunk/src/tclscripts/archer/Makefile.am: need file extension
15:50.25CIA-29BRL-CAD: 03d_rossberg * r42402 10/brlcad/trunk/ (configure.ac src/libbu/brlcad_path.c): there is no realpath() in MSVC, so replaced it by a trivial string-copy then
16:03.37brlcadre 42382 -- you did get it but then you undid it with a subsequent commit saying you didn't match trunk
16:03.52brlcadyour diff was probably not against an up-to-date checkout
16:07.12CIA-29BRL-CAD: 03brlcad * r42403 10/brlcad/trunk/src/util/bw-imp.c: keep the cast size as large as possible, fix the format
16:08.34starseekerah, whoops
16:12.52starseekergrowls... apparently there is no good solution for something like realpath on Windows
16:16.08starseekeroh well
16:19.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:19.26starseekeryeah, these guys pretty much punt:  https://www.securecoding.cert.org/confluence/display/seccode/FIO02-C.+Canonicalize+path+names+originating+from+untrusted+sources
16:20.20starseekerand the closest thing isn't recommended for use in multithreaded applications or shared library code by Microsoft: http://msdn.microsoft.com/en-us/library/aa364963%28VS.85%29.aspx
16:20.21``Eriklooks like there's a com idl for it
16:20.34starseekerhmm?
16:20.34``ErikIShellLink
16:20.57``Erikhas a GetPath() method, dunno what the C approach is
16:22.23``ErikI'm seeing c# and delphi ways to do it without the com bridge to the 'power shell' thingie
16:23.03starseekergive the issue mainly shows up when running build dir binaries and that other fallbacks should (mostly) cover the Windows cases, I'm thinking a huge effort is probably not needed
16:23.32starseekercygwin command line might be the main issue, and I would guess they have a realpath?
16:24.13``Erikthere was a patch to try to give it a better approach I saw googling, under the mingw32 set I think
16:28.07CIA-29BRL-CAD: 03starseeker * r42404 10/brlcad/branches/cmake/ (7 files in 5 dirs): Update cmake branch to r42403, add realpath check to CMakeLists.txt
16:35.39starseekerhmm... http://msdn.microsoft.com/en-us/library/aa364962%28v=VS.85%29.aspx
16:38.19starseekeror perhaps http://msdn.microsoft.com/en-us/library/aa364966%28v=VS.85%29.aspx
16:39.36starseekerwell, if we need to we'll go there
16:39.41starseekerbut only if we need to
16:42.27brlcadyou could implement a bu_normalize() function
16:42.53brlcadwhich could call realpath() or implement it if unavailable
16:43.23starseekernods - that would be the way to go, if it's needed
16:43.56starseekergive we were surviving without the rule working at all, I'm thinking we should expend that effort only when there's a clear need
16:44.15brlcadsure
16:44.31brlcaddidn't know if you were addressing an issue by adding realpath() in the first palce
16:44.59starseekerwas addressing the "I can't run my build dir archer script in the CMake build" issue :-P
16:45.27brlcadhow does realpath fix that?
16:45.47brlcadgets the absolute path of something?
16:45.52brlcadthat was relative
16:45.56starseekeryes
16:46.17starseekerif I ran (say) ../../bin/bwish, the argv0 full path was that
16:46.34brlcadbu_argv0_full_path() shouldn't have been that
16:48.06brlcadif it was, it's a bug that needs to be fixed
16:48.17starseekerchecks...
16:49.53brlcadnow, bu_argv0_full_path() could/should be calling realpath() in its implementation, but it just appends relative to pwd now (punts, but a valid absolute path)
16:50.34starseekeryeah, launching "../../bin/bwish", bu_argv0_full_path returns "../../bin/bwish"
16:50.49brlcadwow
16:51.36starseekerhad figured getprogname was just "bwish", and argv0 was the full string that invoked bwish, and if I wanted a canonical path it was up to me to use argv0's results
16:52.10brlcadnot sure how that's even possible
16:52.22brlcadnah, that bu function is specifically to get an absolute path
16:54.11starseekerso then the realpath logic, if it really is needed, probably belongs there and not in bu_brlcad_root
16:57.02brlcadprobably, or possibly both depending on which path is being tested (e.g., do we support relative paths in BRLCAD_ROOT)
16:57.42starseekerwhat the...
16:57.58brlcadinclination is probably not support them
16:58.02starseekerin gdb, it DOES look like it's returning full path
16:58.18starseekerwhat the *BLEEP* was bu_log printing?
17:01.38starseekerO.O
17:02.02starseekerthe result changes depending on whether I'm launching bwish from within gdb
17:02.30starseekerlooks for a handy wall to bash his head into...
17:06.03starseekeroh, looks like gdb is expanding out the path before running it
17:06.05starseekercute
17:15.20starseekerbrlcad: as near as I can trace this back, the sequence is:
17:15.51starseekerbwish/tcl.c - bu_setprogname takes argv[0] and assignes it to bu_progname
17:16.11starseekerargv[0] at that time is ../../bin/bwish
17:17.51starseekerbu_argv0_full_path calls three functions: _bu_argv0, _bu_ipwd and bu_which
17:18.29starseekerthey return, respectively, ../../bin/bwish    .    ../../bin/bwish
17:21.07starseekerbecause the which result from bu_which is non-null and _bu_argv0's result does not appear to be a full path, the which result is the returned value
17:21.19starseekerthere is no check on whether which is a full path
17:27.12starseekerlooking over bu_which, it doesn't seem to be designed to return a full path...
17:29.02starseekeryeah, once that relative argv[0] was put into bu_progname, I don't see any logic that would make it a full path...
17:33.03starseekerif the which thing hasn't stopped the logic, it would have tried to use ipwd
17:33.19starseekerbut ipwd was "."
17:34.22starseekerso I don't think that would have worked even if which hadn't short circuited the processs
17:40.51*** join/#brlcad Elrohir (~kvirc@p5B14A3BB.dip.t-dialin.net)
18:09.33*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
18:47.41brlcadlooks like ipwd is wrong
18:50.01brlcad"." as an initial (full) path to the current working directory sounds like a fall-back path
18:51.30brlcadyeah, looks like getenv() was probalby empty and HAVE_POPEN was not defined
18:52.04brlcadrealpath would probably be good there
18:53.17brlcadrealpath(getenv("PWD")) or even realpath(".")
19:31.01*** part/#brlcad crazy_imp (~mj@a89-182-3-165.net-htp.de)
20:09.23*** join/#brlcad Ralith (~ralith@d142-058-094-139.wireless.sfu.ca)
20:14.37Ralithbrlcad: do you know anything about how jonored's gcode generator was going to work, or where I could read up on that?  Since he appears to have disappeared for good, I may try to pick up where he left off.
20:16.04Ralithhm, probably should have asked that when I wasn't about to disconnect.
20:25.57*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
20:30.05*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
20:56.15*** join/#brlcad mafm (~mafm@171.Red-83-37-177.dynamicIP.rima-tde.net)
21:13.20CIA-29BRL-CAD: 03brlcad * r42405 10/brlcad/trunk/TODO: preliminary stab at current/next release plans: temp rt/rtedge/rtwizard colors, upgrade repo, and more
21:21.16starseekerbrlcad: what about bu_which?  that's the one that was actually responsible for the bwish path I saw, although it looked like none of the possible paths would actually have gotten us there...
21:22.20starseekerdoesn't look like most of these functions could have returned a full path if a relative path was specified...
22:08.38brlcadstarseeker: bu_which attempts to mimic the 'which' command-line too
22:08.55brlcadwhich has nothing to do with relative or absolute paths
22:09.07brlcadit attempts to find a path to the object specified
22:09.39brlcade.g. if you run "mged" .. it does the search across the dirs in PATH to find it (which can be relative dirs) and returns the match
22:51.17*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
22:51.22Ralithokay, back for the day
22:56.35starseekerbrlcad: then for the purposes of bu_argv0_full_path the which results should be wrapped in realpath too
23:02.46*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
23:28.37*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
23:45.43*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
23:50.04Ralithbrlcad: you didn't answer while I was pinging out, did you?
23:54.55starseekerno, he didn't
IRC log for #brlcad on 20110118

IRC log for #brlcad on 20110118

00:01.15Ralithokay
03:33.38*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
04:56.44*** join/#brlcad Stattrav (~Stattrav@122.172.16.143)
04:56.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:55.10brlcadRalith: was waiting since you were gone and not away -- he didn't write up any of his plans or work from anything written up
07:55.38brlcadif he made any progress, it wasn't made publicly available that I'm aware of
07:56.10Ralithbrlcad: just got ahold of him after a month of trying, actually.  Will be resuming his work.
07:56.17Ralithhe sent me his full git repo
07:56.58brlcadexcellent
07:57.07brlcadI have a copy of some python code he wrote
07:57.20brlcaddon't know if it's the same as what was in his repo
07:57.35Ralithnope, this is C
07:57.38brlcadbut at a glance, it was mainly a way to do in python some of the things you can do in mged
07:57.45brlcadk
07:57.57Raliththis is a partly complete slicer based on the raytracer
07:58.06Ralithnot sure how partly; I suspect mostly.
07:58.08brlcadthat's good
07:58.20Ralithoutputs a sequence of line segments and circular arcs
07:58.24brlcadthat's one of two respectable approaches, the easier of the two
07:58.33Ralithwhat's the other, out of curiosity?
07:59.09brlcadwe'll, you're either using ray-tracing and sampling the space to determine an approximation for toolpaths
07:59.57brlcador you're projecting a contour image to 2D (either sampled or in parametric form) and using that for toolpaths
08:00.46Ralithcontour image being something along the lines of the sketch-from-plane-region-intersection thing I was asking about earlier?
08:00.54Ralithprojected contour image*
08:01.13brlcadbasically
08:01.26brlcadthat'd be one way to attempt it
08:01.54Raliththat was what I was planning on doing had I not been able to recover this code.
08:02.04brlcadthree or four come to mind but they all involve projecting an object onto a viewing plane, not a simple thing to do
08:02.05Ralithlooks like that will be unnecessary, though
08:02.28brlcadthe sampled approach is MUCH much easier and doable today
08:02.35Ralithnod
08:02.37Ralithgood to know
08:02.45brlcadand only limited by the resolution you're willing to sample
08:03.05Ralithand I have a concrete upper limit to that: the precision of the target machine.
08:03.19Ralithtypically worse than 0.1mm.
08:03.32brlcadyou can probably even sample below some specified machining tolerance and it'd never matter
08:03.37brlcadyeah
08:03.48Ralithand a typical build volume of 20cm means quite reasonable sample counts, I believe.
08:04.22brlcadyeah, that'd just be a 2k x 2k sample grid
08:04.34Ralithtrickier on ultraprecise CNC lathes and such, but my first priority is reprap support, which means relatively low-res additive.
08:04.42brlcadthat'd take just a second or two to calculate them all
08:04.47Ralithsweet
08:05.08Ralithif the line/arc approximation math jonored's already finished isn't too heavy, this'll easily outstrip everything else people are using
08:05.29Ralithall of which are improvised STL processors
08:05.54brlcadcrank that up to a 200cm piece or 20cm at a 0.01mm tolerance, and you jack up the grid to 20k x 20k
08:06.11brlcadwhich would be a couple minutes (10x order of mag. increase)
08:06.55Ralithjonored also mentioned that he was put off by some bug wherein the second derivative of toroids was mis-reported?
08:06.59Ralithknow anything about that?
08:07.14brlcadnope
08:07.41Ralithokay, will see about hunting it down if/when I encounter it myself
08:07.41brlcadfirst I've heard of toroids having a problem
08:08.03Ralithit sounded like a minor one:
08:08.16Ralith19:56:53 <jonored> Yep. Either puts them in the wrong slots, or gives a direction of the larger curvature at right angles to what it should,  don't recall which.
08:08.44brlcadthere is one thing that comes to mind, but it's not second-derivative related.  it's failure to converge on a hit/miss if you perfectly graze a torus under certain math conditions
08:08.52brlcadbut then it just counts it as a miss
08:09.04Ralithseems like a pretty minor issue, at least for my purposes
08:09.16brlcadah, curvature is a different routine
08:09.46Ralithhe referred to it as having the "curvature flipped"
08:09.51brlcadnot used by much, so that would be a little less surprising -- but also trivial to investigate -- one tiny func
08:09.58Ralithokay then
08:10.10Ralithwill mention it if I find anything
08:10.28Ralithhopefully with a patch in tow, though I'm still a bit worried about my ability to keep up with the math
08:10.35brlcadsrc/librt/primitives/tor/tor.c:831
08:10.39brlcadrt_tor_curve()
08:10.45Raliththanks :)
08:10.52brlcadif there's a curvature bug, that's where it'd be
08:11.45brlcadit'd be easy to get a sign wrong
08:12.32Ralithlooks like this might well be pretty straightforward.
08:14.29brlcad"rt -l4 -s1024 file.g object" will render 'object' in 'file.g' to a window 1024x1024 with a curvature visualization lighting model, so you can see them in an image
08:14.52Ralithooh, fun!
08:17.49Ralithhm, behaves oddly.
08:17.54Ralithperhaps I should install a stable version
08:18.50Ralithframe buffers are hanging around and not responding to close requests, and display sharply skewed output despite it appearing normal mid-render
08:19.17brlcadare you (or your window manager) resizing the window?
08:19.24Ralithwindow manager is.
08:19.42brlcadthat'd be a problem
08:19.58Ralithtiling wm; tends to be more forceful about that than much code expects
08:20.05Ralithnot a very well behaved tiling wm, though.
08:20.20brlcadfb windows aren't resizable unfortunately
08:20.23Ralithwill switch to something more compliant and with float support in the near future
08:20.28brlcadsucks, but nobody has fixed
08:20.31brlcadtry fbserv instead
08:20.39brlcadfbserv 0 /dev/X &
08:20.49brlcadrt -F0 -s1024 file.g object
08:21.35Raliththat works nicely!
08:21.36Raliththanks :)
08:22.47brlcadmanpage shows other options if the need arises
08:22.50Ralithnod
09:43.04*** join/#brlcad mafm (~mafm@5.Red-83-45-73.dynamicIP.rima-tde.net)
10:38.21CIA-29BRL-CAD: 03tbrowder2 * r42406 10/brlcad/trunk/src/libged/attr.c: modify and rename attr sort comp function for extern use
10:40.01CIA-29BRL-CAD: 03tbrowder2 * r42407 10/brlcad/trunk/src/libged/ged_private.h: add extern for attr comp function; add flags for extension of mged tree command args
10:42.17CIA-29BRL-CAD: 03tbrowder2 * r42408 10/brlcad/trunk/src/libged/ls.c: cast to int to quell compiler warnings about signed/unsigned comparison
10:44.21*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
11:13.47*** join/#brlcad mafm (~mafm@5.Red-83-45-73.dynamicIP.rima-tde.net)
11:14.02CIA-29BRL-CAD: 03tbrowder2 * r42409 10/brlcad/trunk/HACKING: list extensions for Perl code
11:44.18DaveLoMernin all
12:32.38CIA-29BRL-CAD: 03Dloman 07http://brlcad.org * r2422 10/wiki/GeometryServiceNetworkProtocol:
13:07.39*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:37.10DaveLoopens a new can of Photoshop-fu. Will need lots today.
13:38.50CIA-29BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:GSNetProtocol.png]]"
13:55.05CIA-29BRL-CAD: 03Dloman 07http://brlcad.org * r2424 10/wiki/GeometryServiceNetworkProtocol: Added in specifics about GSNet Header stufff. WIP still.
13:57.11CIA-29BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:GSNetMsgBreakdown.png]]"
13:59.45CIA-29BRL-CAD: 03Dloman 07http://brlcad.org * r2426 10/wiki/GeometryServiceNetworkProtocol: New image name, down size a bit.
14:03.33starseekeris probably going to end up volunteering to maintain a few Find*.cmake modules
14:09.06DaveLothat'll be fun!
14:10.03starseekerapparently back in 07 they switched to a system where people volunteer to maintain specific modules, on the (quite reasonable) theory that Kitware didn't have the resources to properly test them all
14:10.59*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
14:11.04starseekersubmitted patches for Tcl, OpenGL and X11 anyway on the theory that Kitware probably wouldn't want to trust them to a 3rd party maintainer, give how core they were
14:11.07starseekersilly me
14:11.17*** join/#brlcad kanzure (~kanzure@131.252.130.248)
14:11.20*** join/#brlcad 15SABD4WY (~CIA@208.69.182.149)
14:12.26starseekerin one sense though it's not too big a deal, since I'll either be maintaining our local copy of those files as a "mini-fork" or doing it for CMake proper
14:13.28*** join/#brlcad CIA-38 (~CIA@208.69.182.149)
14:13.32*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
14:13.48starseekerX11 and OpenGL should be pretty mature anyway, but the FindTCL module is a radical departure
14:14.42DaveLoHows the roads down there?
14:15.45CIA-38BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:GSNet Symbol.png]]"
14:15.53*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
14:15.53*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
14:17.59*** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net)
14:18.33*** join/#brlcad epileg1 (~epileg@188.119.210.222)
14:20.36*** join/#brlcad mafm (~mafm@5.Red-83-45-73.dynamicIP.rima-tde.net)
14:21.53starseekergrits his teeth and does a reboot into Windows for another test round...
14:22.49CIA-38BRL-CAD: 03Dloman 07http://brlcad.org * r2428 10/wiki/GeometryServiceNetworkProtocol: Add in GSnet graphic and align.
14:23.13DaveLostarseeker: Hows the roads down there?  made the trek in to work yet?
14:24.11*** join/#brlcad Elrohir (~kvirc@p5B14977D.dip.t-dialin.net)
14:27.59starseekerno, not yet - they plowed but there is a lot of slush in our area
14:28.13starseekerjust got done scraping the driveway
14:29.16CIA-38BRL-CAD: 03Dloman 07http://brlcad.org * r2429 10/wiki/GSNet_String: Stub in GSNet String page.
14:31.33starseekerwill head in once he sees what happens on Windows...
14:33.09starseekeroooo - lot of updates to pull
14:37.44*** join/#brlcad Elrohir (~kvirc@p5B14977D.dip.t-dialin.net)
14:59.43DaveLolotsa ice up here as well.
15:00.00DaveLojust called in to leave a telework notice.  Heh, no one answered! =D
15:06.09*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:10.43``Erik_snow line said post was closed until 9
15:13.05CIA-38BRL-CAD: 03erikgreenwald * r42410 10/brlcad/trunk/src/librt/Makefile.am: move nmg_junk to EXTRA_DIST
15:28.03CIA-38BRL-CAD: 03starseeker * r42411 10/brlcad/branches/cmake/src/CMakeLists.txt: Put the CMAKE_HEADERS variable in the src add_definitions (Windows seems to like this better, needs more testing.)
15:36.01DaveLo``Erik: righto, but I called at 10 and still no answer :)
15:39.33CIA-38BRL-CAD: 03erikgreenwald * r42412 10/brlcad/trunk/src/libged/ged.c: type fix
15:44.38*** join/#brlcad Stattrav (~Stattrav@117.202.19.46)
15:44.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:22.12CIA-38BRL-CAD: 03starseeker * r42413 10/brlcad/branches/cmake/CMakeLists.txt:
16:22.12CIA-38BRL-CAD: Successfully generate an NSIS installer, although it doesn't work yet due to
16:22.12CIA-38BRL-CAD: src/other libraries being installed to the wrong dir - need to correct the CMake
16:22.12CIA-38BRL-CAD: files in question or add additional logic in src/other/CMakeLists.txt, whichever
16:22.12CIA-38BRL-CAD: makes sense.
18:03.41DaveLowhoooo doggy.  There's some serious ice out there!  Im still chipping away at getting clear.
18:03.49CIA-38BRL-CAD: 03starseeker * r42414 10/brlcad/branches/cmake/ (11 files in 11 dirs): Make the CMake library target logic a bit more generic. A lot of these files should probably be worked into being proper stand-alone CMakeLists.txt files.
18:03.56DaveLolooks like two layers of ice then snow.  Blech
18:04.12starseekernods - I'll be heading in soon, but yeah - figured the more melted the better
18:04.21starseekerat least it's above freezing, or moving would be out of the question
18:04.37DaveLoTemps up here are cycling above then below here.
18:04.45starseekerah, we're a few degrees above
18:04.59DaveLohalf the stuff that melted and ran off the jeep refroze on the ground :/
18:05.18DaveLoWe're getting more this evening, right?  i havent checked the forecast in a bit.
18:05.27starseekerstill had to shovel - if it had re-frozen tonight, would have had 3/4 inch or better of ice all over the driveway
18:05.42starseekerdunno - haven't seen any indications of more, but perhaps that's changed
18:06.09starseekermakes one file stab at Windows before heading in
18:07.02DaveLochecks forecast
18:07.56DaveLoheh, yeah.  Starting around 10pm, more ice and snow... at least up here.
18:08.40DaveLolooks like mostly rain down your way, with temps never dipping below freezing.
18:08.53DaveLohave a nice day at work!  muwahahaha =P
18:09.35CIA-38BRL-CAD: 03Dloman 07http://brlcad.org * r2430 10/wiki/GeometryServiceNetworkProtocol: Change links to start eliminating the iBME references.
18:10.01CIA-38BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[IBME NETWORKPROTO STRING]]": iBME references are antiquated and being updated.
18:20.41*** part/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
18:20.53*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
18:49.54*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
19:24.53CIA-38BRL-CAD: 03Dloman 07http://brlcad.org * r2431 10/wiki/GeometryServiceNetworkProtocol: Spacing
19:30.10CIA-38BRL-CAD: 03Dloman 07http://brlcad.org * r2432 10/wiki/GeometryServiceNetworkProtocol: Specifics about the libPKG header implementation
19:48.20brlcadstarseeker: note that the current nsis installer is "wrong" in several aspects as to where files are placed
19:49.22brlcadyou don't need to accommodate the existing mistakes -- keep the install tree like it is supposed to be so it's the same on all platforms
19:49.25brlcadthe nsis installer can be fixed to accomodate
19:52.00CIA-38BRL-CAD: 03Dloman 07http://brlcad.org * r2433 10/wiki/GeometryServiceNetworkProtocol: Use CSS to make the table purty.
19:55.41CIA-38BRL-CAD: 03brlcad * r42415 10/brlcad/trunk/src/libged/ (attr.c ged.c ged_private.h):
19:55.41CIA-38BRL-CAD: private functions used across commands should be in the _ged_ namespace,
19:55.41CIA-38BRL-CAD: otherwise, they don't need to be declared in ged_private.h and can remain HIDDEN
19:55.41CIA-38BRL-CAD: _cmd_ prefixed. rename _attr_cmpstringp() to _ged_cmpattr() to reflect that it
19:55.41CIA-38BRL-CAD: specifically compares bu_attribute_value_pair objects.
20:12.27CIA-38BRL-CAD: 03brlcad * r42416 10/brlcad/trunk/src/libged/ (attr.c ged.c ged_private.h): ws consistency update, elim forward decls
20:15.04starseekernods
20:15.30starseekertrying to figure out why mged isn't finding anything on Windows...
20:15.47starseekerneeds to generalize the pkgIndex.tcl files a bit, doing that first
20:19.42CIA-38BRL-CAD: 03brlcad * r42417 10/brlcad/trunk/src/libged/ (ged_private.h ls.c): convert up to size_t instead of down to int.
20:56.07CIA-38BRL-CAD: 03brlcad * r42418 10/brlcad/trunk/src/librt/parse.c: quell warnings, size_t upconversions
20:58.54CIA-38BRL-CAD: 03brlcad * r42419 10/brlcad/trunk/src/librt/Makefile.am:
20:58.55CIA-38BRL-CAD: compile parse.c and nmg_junk.c so we make sure that they keep compiling as the
20:58.55CIA-38BRL-CAD: library evolves. they don't need to be installed, but they should still be
20:58.55CIA-38BRL-CAD: maintained until they're integrated or removed. (alas, they both have useful
20:58.55CIA-38BRL-CAD: routines that should be integrated)
20:59.38brlcadstarseeker: be wary of #ifdef _WIN32 and if {$platform == "windows"} statements in C/Tcl code that Bob added to override search paths
21:00.33brlcadsome of them are sprinkled in unsuspecting places, have to trace the logic when something fails to load that should be loading to make sure it's not a hack job screwing things up
21:00.54starseekernods - will do
21:22.42CIA-38BRL-CAD: 03starseeker * r42420 10/brlcad/branches/cmake/src/other/ (6 files in 6 dirs): Fix/generalize pkgIndex.tcl logic, make incrTcl libs follow convention.
21:40.08CIA-38BRL-CAD: 03brlcad * r42421 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c:
21:40.09CIA-38BRL-CAD: not entirely clear what the compiler is complaining about here with the two
21:40.09CIA-38BRL-CAD: (const point_t *) parameters to rt_metaball_find_intersection(). the problem
21:40.09CIA-38BRL-CAD: has something to do with point_t being an array typedef. instead of getting the
21:40.09CIA-38BRL-CAD: address during the call, get the point_t address beforehand with an explicit
21:40.09CIA-38BRL-CAD: cast to keep things quiet. (gcc 4.2.1)
21:49.15``Erikhm, I disabled nmg_junk.c last week due to 'defined but not used' warnings stopping the compile
22:08.28brlcadeverything in librt_xxx.la is not used, so maybe it'll be quiet -- seems to work here with 4.2.1
22:08.46brlcadotherwise, I can add some extern decls
22:08.54brlcadthat'll definitely make it shut up
22:15.54CIA-38BRL-CAD: 03starseeker * r42422 10/brlcad/branches/cmake/src/libbu/brlcad_path.c:
22:15.54CIA-38BRL-CAD: Interesting... when launching bwish from the root install dir (e.g. ./bin/bwish)
22:15.54CIA-38BRL-CAD: the return of bu_brlcad_data was not a full path (or even strictly speaking a
22:15.54CIA-38BRL-CAD: relative path unless you add an implicit '.') and archer didn't start. This is
22:15.54CIA-38BRL-CAD: a bit of a corner case, but still should work - try to make it more robust.
22:29.09CIA-38BRL-CAD: 03starseeker * r42423 10/brlcad/branches/cmake/src/archer/plugins/Utility/botUtilityP.tcl: shouldn't need brlcadDataPath variable here.
22:38.48CIA-38BRL-CAD: 03starseeker * r42424 10/brlcad/branches/cmake/src/libbu/brlcad_path.c: Whoops, try to do snprintf right
22:47.42starseekermutter... bwish starts, but it's auto_path is rather underpopulated
22:50.13starseekerand bu_brlcad_data doesn't know what's up on Windows (at least from build-dir, which I suppose isn't too surprising)
23:06.08*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
23:46.11brlcadstarseeker: that could be related to path separator, or trying to mix one style of separator with another
IRC log for #brlcad on 20110119

IRC log for #brlcad on 20110119

00:09.53``Erikvotes for '>' :D (vms)
00:11.25CIA-38BRL-CAD: 03brlcad * r42425 10/brlcad/trunk/BUGS: rt crashes when it shouldn't
00:41.22*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
00:44.36``Erikhttp://brlcad.org/~erik/codenorris.jpg
00:52.49CIA-38BRL-CAD: 03starseeker * r42426 10/brlcad/branches/cmake/src/libbu/dirname.c: Don't hardcode '/' into bu_dirname, it's wrong on Windows
00:53.52*** join/#brlcad merzo (~merzo@94-43-108-20.dsl.utg.ge)
01:20.56CIA-38BRL-CAD: 03brlcad * r42427 10/brlcad/trunk/ (4 files in 4 dirs):
01:20.56CIA-38BRL-CAD: enable a test for -std=c99 since we cannot compile glx/gl.h-using code on Mac OS
01:20.56CIA-38BRL-CAD: X 10.6 with -pedantic due to // comments in the gl.h header. use the flag in
01:20.56CIA-38BRL-CAD: the dirs where we interface with glx (src/mged src/libdm src/libfb)
01:29.14*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
01:37.47CIA-38BRL-CAD: 03starseeker * r42428 10/brlcad/branches/cmake/src/ (libbu/brlcad_path.c mged/mged.c mged/setup.c): Use GetFullPathName on Windows, and remove a couple of the Win32 specific bits in mged - this results in mged launching successfully. Still a lot more to do, including figuring out why archer silently crashes.
01:48.41starseekerhmm - I wonder if the itcl/itk upgrade did something, or if it's just how I'm building them with CMake
02:01.23brlcad<windows.h> .. system header
02:52.34starseekerin common.h then?
03:17.28starseekerhuh - maxima is in the top 25 projects on sourceforge
03:31.13Ralithdidn't know it was that active
03:31.14Ralithneat
03:38.47starseekerhuh - another cad project based on opencascade:  http://sourceforge.net/projects/narocad/
03:41.44starseekerwoot - someone is porting qcad to qt4
03:51.51starseekerhttp://sourceforge.net/projects/librecad/
03:51.56starseekereven builds
05:10.26CIA-38BRL-CAD: 03brlcad * r42429 10/brlcad/trunk/include/raytrace.h: remove duplicate rt_dirbuild declaration
06:01.42Ralithopencascade gets all the attention ._.
07:48.02CIA-38BRL-CAD: 03brlcad * r42430 10/brlcad/trunk/ (include/raytrace.h src/librt/db5_scan.c src/librt/db_open.c): rename db_get_version() to simply db_version(). there's no need for the getter name convention (inconsistent with api), especially when there's no putter.
07:59.23CIA-38BRL-CAD: 03brlcad * r42431 10/brlcad/trunk/src/libged/ (draw.c erase.c): upcast argc iteration comparisons to size_t
08:07.45CIA-38BRL-CAD: 03brlcad * r42432 10/brlcad/trunk/doc/deprecation.txt: renamed db_get_version() to db_version() as a minimally impacting change.
08:10.55CIA-38BRL-CAD: 03brlcad * r42433 10/brlcad/trunk/ (6 files in 4 dirs): rename db_get_directory_size() to just db_directory_size() for similar motivations. there is no corresponding put routine, so simplify.
08:27.59*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
08:27.59*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
08:27.59*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
08:27.59*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
08:27.59*** join/#brlcad kanzure (~kanzure@131.252.130.248)
08:28.01CIA-38BRL-CAD: 03brlcad * r42434 10/brlcad/trunk/ (doc/deprecation.txt include/raytrace.h src/librt/db_lookup.c): db_get_directory() renamed to db_alloc_directory() to be a little more consistent with other (non-macro) routines that don't do much except allocate memory.
08:29.27CIA-38BRL-CAD: 03brlcad * r42435 10/brlcad/trunk/src/librt/ (db_alloc.c db_lookup.c): move the allocation routine into db_alloc.c
08:32.51CIA-38BRL-CAD: 03brlcad * r42436 10/brlcad/trunk/ (doc/deprecation.txt include/raytrace.h src/librt/db_alloc.c): be more specific. match the resource struct member name, allocating more than one directory.
08:35.03CIA-38BRL-CAD: 03brlcad * r42437 10/brlcad/trunk/include/raytrace.h: make it clear that these affect one global timer
08:41.10CIA-38BRL-CAD: 03brlcad * r42438 10/brlcad/trunk/ (doc/deprecation.txt include/raytrace.h src/librt/storage.c): rename rt_get_set() similarly to rt_alloc_seg_block() since it doesn't actually get andthing or have an equivalent put/set. it's purpose is to allocate a block of segs so just say that.
08:46.17CIA-38BRL-CAD: 03brlcad * r42439 10/brlcad/trunk/include/raytrace.h: declare db_alloc_directory_block() properly according to the rename.
08:49.15CIA-38BRL-CAD: 03brlcad * r42440 10/brlcad/trunk/include/raytrace.h: move the related decls closer to each other for the two rt/db_alloc routines
08:50.33CIA-38BRL-CAD: 03brlcad * r42441 10/brlcad/trunk/src/librt/ (db_alloc.c storage.c): move rt_alloc_seg_block from storage.c to db_alloc.c so db_alloc_directory_bloc() doesn't get lonely.
08:51.55CIA-38BRL-CAD: 03brlcad * r42442 10/brlcad/trunk/ (4 files in 2 dirs): storage.c is no longer needed.
08:57.36RalithI'd like to find a series of line segments along a given line, within the inside of a region, such that no point on any line segment is closer than a certain to the surface.  Anyone have any thoughts on how this might be done?
08:58.18Ralithsomething like the intersection between a line and a verison of the object slightly shrunk along all surface normals, I think
09:17.31*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
09:38.57CIA-38BRL-CAD: 03d_rossberg * r42443 10/brlcad/trunk/src/librt/CMakeLists.txt:
09:38.58CIA-38BRL-CAD: synced with Makefile.am: removed nmg_junk.c from the actual build
09:38.58CIA-38BRL-CAD: nmg_junk.c is a resting place for unfinished subroutines that are not a part of the current NMG library
09:56.06*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
10:29.43*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
10:44.58*** join/#brlcad mafm (~mafm@62.Red-81-32-105.dynamicIP.rima-tde.net)
11:18.32*** join/#brlcad juanman (~quassel@201.255.21.86)
11:18.35*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:03.48DaveLoMernin all!
13:06.33CIA-38BRL-CAD: 03ronaldbowers * r42444 10/jbrlcad/trunk/src/main/java/org/brlcad/geometryservice/: Making an interface
13:08.03``Eriknow what the heck is ron up to? I've been putting that in rt^3
13:09.32DaveLotee hee
13:39.02brlcad<PROTECTED>
13:39.26*** join/#brlcad Stattrav (~Stattrav@117.202.19.79)
13:39.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:55.11*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:00.35CIA-38BRL-CAD: 03brlcad * r42445 10/brlcad/trunk/src/librt/db5_scan.c: if the database version has already been calculated, don't bother recalculating it. avoids rewind+fseek.
14:03.22CIA-38BRL-CAD: 03brlcad * r42446 10/brlcad/trunk/src/librt/db_open.c: make sure db_version() calculates the version during db_open(), init to zero.
14:08.51CIA-38BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Image:GSNetProtocol.png]]": Incorrectly named image. Should have been named GSNetMsgBreakdown
14:29.48CIA-38BRL-CAD: 03davidloman * r42447 10/rt^3/trunk/docs/ (GS_Symbol.png GS_Symbol.psd): Add in rough draft of GS graphic.
14:37.47CIA-38BRL-CAD: 03Dloman 07http://brlcad.org * r2434 10/wiki/Geometry_Service_Project_Main: Update definitions
14:38.26CIA-38BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[IBME GeometryEngine]]": Dropping antiquated definition as well as eliminating an iBME reference.
14:38.46CIA-38BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[IBME GeometryService]]": Dropping antiquated definition as well as eliminating an iBME reference.
15:10.15*** join/#brlcad Elrohir (~kvirc@p5B14BCFC.dip.t-dialin.net)
15:11.21CIA-38BRL-CAD: 03brlcad * r42448 10/brlcad/trunk/include/raytrace.h: move the alloc functions down with the other alloc functions
15:25.37starseekerO.O  http://www.40fires.org/Wiki.jsp?page=Hyrban%20CAD%20models
15:26.54starseekerhttp://www.40fires.org/Wiki.jsp?page=TermsOfUse
15:27.09``Erikneat
15:28.13starseekerI thinke we just found a test case for our iges convertor :-P
15:28.55starseekerwaits for his headache to subside so he can go in...
15:30.22``Erikhm, from their blog, 9/10/09, "One day we'll have a wonderful, open source, free or nearly free, collaborative, version controlling 2D/3D CAD system (any suggestions?) and a wiki that you can all contribute to but it's still early days."
15:32.55``Erikcan't find what CAD system they're using, and don't know 'nuff to guess from the pictures
15:33.19starseekerCATIA, I think
15:33.24starseekernewest blog entry mentions it
15:33.29``Erikthat was my gut feeling heh
15:33.46``Erikthe blue gradient background in some p ics is catia style
15:35.22``Erikhm, shuttleworth has talked to 'em
15:45.00CIA-38BRL-CAD: 03brlcad * r42449 10/brlcad/trunk/src/ (52 files in 9 dirs): put db_version() to use, particularly for callers outside of librt since it's a private API member that isnt' supposed to be directly accessed. this sets the stage for using dbi_version in other ways.
15:57.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:11.00CIA-38BRL-CAD: 03brlcad * r42450 10/brlcad/trunk/src/conv/dbupgrade.c: get the version number just once, then reference it
16:19.18DaveLoHrm, might be a decent idea: http://www.cnn.com/2011/TECH/innovation/01/19/smart.roads/index.html?eref=mrss_igoogle_cnn
16:19.53CIA-38BRL-CAD: 03ronaldbowers * r42451 10/jbrlcad/trunk/src/main/java/org/brlcad/geometryservice/GeometryServiceSPI.java: - Version 0.1 of the GeometryServiceSPI. Implementations should match the behavior defined here.
16:32.24CIA-38BRL-CAD: 03brlcad * r42452 10/brlcad/trunk/src/librt/db5_scan.c: idiot
16:32.45CIA-38BRL-CAD: 03brlcad * r42453 10/brlcad/trunk/src/librt/db5_io.c: can't call db_version because the dbip is const
16:37.09CIA-38BRL-CAD: 03brlcad * r42454 10/brlcad/trunk/src/ (10 files in 5 dirs): improve consistency on how the version numbers are checked. avoiding <= and >= where unnecessary.
17:26.43CIA-38BRL-CAD: 03brlcad * r42456 10/brlcad/trunk/src/mged/ (cmd.c mged.c): rename db_warn, db_upgrade, and db_version to have an mged_ prefix so they don't collide with librt db_*() functions (e.g., db_version())
18:02.35CIA-38BRL-CAD: 03bob1961 * r42458 10/brlcad/trunk/src/tclscripts/lib/RtControl.tcl: Added a configbody for the -color option.
18:02.35CIA-38BRL-CAD: 03bob1961 * r42457 10/brlcad/trunk/src/tclscripts/lib/TkTable.tcl: Tweaked cadwidgets::TkTable::toggleSelect to behave better after a <Button-1> event occurs in a different cell.
18:03.07CIA-38BRL-CAD: 03bob1961 * r42459 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Added a preference for the framebuffer's background color.
18:31.12starseekerDaveLo: problem with solar powered roads is 1) cost and 2) keeping 'em clean
18:31.58DaveLoWell if a state manages to get a leader in place that actually has LONG term planning skills, cost may be less of a problem.
18:32.17DaveLoas for cleaning, just wrap swiffer pads around tires :)
18:32.24starseekerheh
18:33.14starseekermight be more workable to have the sides of the road be solar panels
18:33.41starseekerno car oil and crap being dropped on them (or less, anyway) and they'll be exposed to the sun more
18:33.45CIA-38BRL-CAD: 03brlcad * r42460 10/brlcad/trunk/ (NEWS m4/patch.m4): (log message trimmed)
18:33.45CIA-38BRL-CAD: wow, now that I can finally reproduce and investigate ... FIX the
18:33.45CIA-38BRL-CAD: several-year-old bug where compilation would fail on some Mac OS X systems
18:33.45CIA-38BRL-CAD: (10.6+?) with a 'dyld: Library not loaded:
18:33.45CIA-38BRL-CAD: /usr/brlcad/dev-7.18.1//lib/libwdb.19.dylib' message (and subsequent crash
18:33.46CIA-38BRL-CAD: report). the problem is actually due to a bug in libtool where their temp_rpath
18:33.47CIA-38BRL-CAD: variable was getting appended to another path variable but without a : between
18:34.52starseekeralso would avoid the concerns mentioned about glass strength and traction
18:34.58brlcadit's only a matter of time, I can see it easily being cost effective for cities
18:36.57brlcadvery 'spensive to have a fleet of trucks rolling through city streets scooping up snow and ice, took hundreds of trucks nearly a month to clear baltimore last year working 24/7
18:37.30starseekernods - cities could also heat the roads using solar panels on buildings and such (or even other sources of heat, once the heating element infrastructure itself was in place)
18:38.34brlcadthat's easily a couple million in annual expenses just to cover salary, double/triple to cover equipment, maintenance, supplies, insurance
18:39.38brlcadcity streets get repaved regularly (there are just so many), so they'd just need to be installable in sections as upgrades occur and be fault tolerant to big trucks, pot holes, etc
18:41.10starseekerbrlcad: regarding windows.h - ``Erik was saying including it at the common.h level causes conflicts
18:41.51``Erikmay cause
18:42.12``Erikmany annoying things come from windows.h, like #define near and #define far for example
18:42.26``Erikand #define DELETE more recently
18:42.54``Erikisn't happy about the #ifdef WIN32 #undef symbol #endif pattern we have a few places :/
18:46.37starseekerunless I'm missing something, wouldn't the only way forward be to include windows.h up front in config_win, and then undef everything that may cause us trouble later?
18:49.04``Erikor rename our stuff
19:06.06brlcadnow with that old bug fixed.. time for lunch!
19:18.49*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
19:18.49*** join/#brlcad kanzure (~kanzure@131.252.130.248)
19:18.50*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
19:18.50*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
19:18.50*** join/#brlcad DaveLo (~claymore@BZ.BZFLAG.BZ)
19:18.50*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
19:18.50*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
19:18.50*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
19:57.19DaveLoheh, forgot about this one: http://www.youtube.com/watch?v=u-6ph7NWoBM
21:04.13starseekerbrlcad: thath BU_STR_EQUAL thing seems to have broken search
21:11.17Ralithbrlcad: that's good for entry/exit points, but doesn't account for points when a surface passes very close to but does not intersect the ray while it's inside the region
21:30.55CIA-38BRL-CAD: 03starseeker * r42461 10/brlcad/trunk/src/other/tkpng/Makefile.am: I doubt we need the -module flag here - CMake build doesn't need it, so try it without
21:31.35``Erikhah, now it fails with the expected issue
21:31.41``Eriksrc/other/tkpng/Makefile.am:8: `tkpng.la' is not a standard libtool library name
21:31.41``Eriksrc/other/tkpng/Makefile.am:8: did you mean `libtkpng.la'?
21:32.49starseekerbah
21:32.52CIA-38BRL-CAD: 03erikgreenwald * r42462 10/brlcad/trunk/src/other/tkpng/Makefile.am: tkpng -> libtkpng
21:34.48CIA-38BRL-CAD: 03erikgreenwald * r42463 10/brlcad/trunk/configure.ac: tkpng -> libtkpng
21:36.08brlcadstarseeker: okay, I'll look into it (search)
21:44.48starseekertried to include bu.h in search.c, but so far that doesn't seem to have done it...
21:46.58brlcadincluding a header won't usually change behavior ... just declarations and defines
21:49.05brlcadah, that's what did it
21:49.26brlcadtypecompare() is a callback, e.g. for qsort()
21:49.56brlcadneeds to return >=< 0, not boolean
22:04.49CIA-38BRL-CAD: 03brlcad * r42464 10/brlcad/trunk/src/libged/search.c: the typecompare() callback passed to bsearch() needs to return value <0, ==0, >0 depending on the comparison, not just a boolean. use bu_strcmp() instead of !BU_STR_EQUAL()
22:07.50CIA-38BRL-CAD: 03erikgreenwald * r42465 10/brlcad/trunk/src/burst/prnt.c: #ifdef, not #if DEBUG
22:32.57*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
22:32.57*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
22:32.58*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
22:32.58*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
22:32.58*** join/#brlcad DaveLo (~claymore@BZ.BZFLAG.BZ)
22:38.18CIA-38BRL-CAD: 03brlcad * r42466 10/brlcad/trunk/src/libwdb/Makefile.am: libwdb seems to be compiling cleanly on mac and linux, so enable enforcement of strict build
22:43.49*** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl)
22:51.40*** join/#brlcad mafm (~mafm@62.Red-81-32-105.dynamicIP.rima-tde.net)
22:56.57CIA-38BRL-CAD: 03brlcad * r42467 10/brlcad/trunk/src/libged/attr.c: er, so soon? use the new bu_strcmp() function so we properly handle null strings.
23:03.26CIA-38BRL-CAD: 03brlcad * r42468 10/brlcad/trunk/configure.ac: er, STRICT_FLAGS should match the flags we actually tested for.
23:25.09CIA-38BRL-CAD: 03brlcad * r42469 10/brlcad/trunk/src/libged/search.c: ws
23:25.50CIA-38BRL-CAD: 03brlcad * r42470 10/brlcad/trunk/src/ (8 files in 4 dirs):
23:25.50CIA-38BRL-CAD: more cases similiar to the search failure (affecting a bunch of commands
23:25.50CIA-38BRL-CAD: including the likes of ls, the tedit commands, tops, and others) where we cannot
23:25.50CIA-38BRL-CAD: use BU_STR_EQUAL since we actually need to use the real return value from
23:25.50CIA-38BRL-CAD: bu_strcmp() instead of !BU_STR_EQUAL(). nice early catch.
IRC log for #brlcad on 20110120

IRC log for #brlcad on 20110120

00:59.18CIA-38BRL-CAD: 03brlcad * r42471 10/brlcad/trunk/src/libgcv/Makefile.am: seems to build clean here, turn on strict
01:00.22CIA-38BRL-CAD: 03brlcad * r42472 10/brlcad/trunk/src/libanalyze/Makefile.am: another dir that compiles clean, strictify
01:09.19CIA-38BRL-CAD: 03brlcad * r42473 10/brlcad/trunk/ (3 files in 2 dirs): there doesn't seem to be any clear reason why load_dynamic_shader() takes the length of the shader name given it only prints the length for diagnostic purposes. remove the mlen parameter.
01:41.12CIA-38BRL-CAD: 03brlcad * r42474 10/brlcad/trunk/src/liboptical/ (38 files): ws indent comment consistency update
01:45.26CIA-38BRL-CAD: 03erikgreenwald * r42475 10/brlcad/trunk/src/libged/search.c: fix some... "creative" punctuation
01:51.13*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
02:43.48*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
03:39.44CIA-38BRL-CAD: 03brlcad * r42476 10/brlcad/trunk/src/libged/ (Makefile.am dg_obj.c): save another curtree from clobberage by encapsulating the BU_SETJUMP/BU_UNSETJUMP logic into separate functions.
03:39.45CIA-38BRL-CAD: 03brlcad * r42477 10/brlcad/trunk/src/libged/Makefile.am: not so fast
03:45.35CIA-38BRL-CAD: 03brlcad * r42478 10/brlcad/trunk/src/libged/dg_obj.c: stash the return value so we clean up properly
03:48.24CIA-38BRL-CAD: 03brlcad * r42479 10/brlcad/trunk/src/libged/draw.c: bom bom bom, and another one bites the dust. quell warning about curtree getting clobbered due to longjmp by breaking jumping out into separate frames.
03:54.00CIA-38BRL-CAD: 03brlcad * r42480 10/brlcad/trunk/src/libged/facetize.c: sometimes the fix is simple. making three vars static made the compiler sufficiently happy.
04:01.46CIA-38BRL-CAD: 03brlcad * r42481 10/brlcad/trunk/src/libged/human.c:
04:01.46CIA-38BRL-CAD: heh, some seriously sketchy string initialization in here, but punt on cleaning
04:01.46CIA-38BRL-CAD: it up. keep the compiler happy, though, by making the initialization explicit
04:01.46CIA-38BRL-CAD: with a strlcpy. other %lf and 509 string limit quellage too. untested.
04:04.36CIA-38BRL-CAD: 03brlcad * r42482 10/brlcad/trunk/src/libged/preview.c: eliminate non-c90 // comments
04:05.20CIA-38BRL-CAD: 03brlcad * r42483 10/brlcad/trunk/src/libged/mirror.c: gcc is lazy. be explicit about setting up the argv array.
04:05.48CIA-38BRL-CAD: 03brlcad * r42484 10/brlcad/trunk/src/libged/inside.c: make sure we init our vectors before using them.
04:18.38CIA-38BRL-CAD: 03brlcad * r42485 10/brlcad/trunk/src/libged/select.c: more var init before use.
04:24.32CIA-38BRL-CAD: 03brlcad * r42486 10/brlcad/trunk/src/libged/ (ps.c qray.c rect.c tire.c wdb_qray.c): more quelling compilation woes due to string lengths exceeding c90's 509 char limit, break em up.
04:27.06CIA-38BRL-CAD: 03brlcad * r42487 10/brlcad/trunk/src/libged/wdb_obj.c: woo hoo, this makes for the last strict quellage in libged. another longjmp protection, fortunately made very simple since they're just flags that get initialized every time and can just be made static.
04:27.17CIA-38BRL-CAD: 03brlcad * r42488 10/brlcad/trunk/src/libged/Makefile.am: turn on ... STRICT!
04:28.20CIA-38BRL-CAD: 03brlcad * r42489 10/brlcad/trunk/src/libfb/fb_generic.c: need strings.h, not the older string.h for strcasecmp()
04:39.10CIA-38BRL-CAD: 03brlcad * r42490 10/brlcad/trunk/src/liboptical/ (photonmap.c sh_plastic.c): remove two trailing unused parameters to IrradianceEstimate(), mark unused params, shine light onto the shadows.
04:59.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:23.40CIA-38BRL-CAD: 03brlcad * r42491 10/brlcad/trunk/src/libfb/ (fb_generic.c fb_obj.c tcl.c): need string.h from some things, strings.h for others. likely needs revisiting for windows
05:24.19brlcadfg
05:24.40CIA-38BRL-CAD: 03brlcad * r42492 10/brlcad/trunk/src/libfb/if_X24.c: ftruncate is not available during posix-compliant complication, so just settle for (untested) lseeking.
05:30.15CIA-38BRL-CAD: 03brlcad * r42493 10/brlcad/trunk/src/libged/ (dg_obj.c draw.c): these are supposed to be static
05:31.36CIA-38BRL-CAD: 03brlcad * r42494 10/brlcad/trunk/src/liboptical/Makefile.am: oops, didn't mean to enable strict here just yet
05:37.47CIA-38BRL-CAD: 03brlcad * r42495 10/brlcad/trunk/include/photonmap.h: sync missing update for liboptical
05:39.19*** join/#brlcad Stattrav (~Stattrav@122.172.31.168)
05:39.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:55.04CIA-38BRL-CAD: 03brlcad * r42496 10/brlcad/trunk/src/libdm/dm-plot.c: define __USE_POSIX2 so we get a declaration of popen() on Linux.
08:10.34*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
08:44.05*** join/#brlcad mafm (~mafm@234.Red-81-43-146.staticIP.rima-tde.net)
08:56.45*** join/#brlcad Stattrav (~Stattrav@122.172.31.168)
08:56.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:06.17*** join/#brlcad mafm (~mafm@234.Red-81-43-146.staticIP.rima-tde.net)
09:31.07*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
09:47.45*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
11:17.29*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
11:21.04*** join/#brlcad Elrohir (~kvirc@p5B149C53.dip.t-dialin.net)
11:46.14*** join/#brlcad mafm (~mafm@239.Red-83-49-86.dynamicIP.rima-tde.net)
12:54.35CIA-38BRL-CAD: 03d_rossberg * r42497 10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: added db_version() for some conversion programs
16:10.29CIA-38BRL-CAD: 03erikgreenwald * r42498 10/rt^3/trunk/ (6 files in 6 dirs): use FindTCL before FindBRLCAD
16:18.49CIA-38BRL-CAD: 03starseeker * r42499 10/brlcad/branches/cmake/src/other/ (3 files in 3 dirs): Make a stab at better build logic for itcl/itk on Windows, although this does not yet get Archer running
16:59.20*** join/#brlcad Stattrav (~Stattrav@117.202.22.82)
16:59.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:00.07CIA-38BRL-CAD: 03brlcad * r42500 10/brlcad/trunk/include/raytrace.h: clarify that db_version() only returns 4 or 5 presently, though callers shouldn't assume support for newer or older versions won't be added.
17:01.33CIA-38BRL-CAD: 03brlcad * r42501 10/brlcad/trunk/src/liboptical/ (30 files):
17:01.33CIA-38BRL-CAD: quell all verbose compilation warnings within liboptical, enable strict mode
17:01.33CIA-38BRL-CAD: compilation. this adds missing initializer values, marks unused params,
17:01.33CIA-38BRL-CAD: addresses exact floating point comparisons, and eliminates unused variables.
17:04.30*** join/#brlcad piksi (piksi@pi-xi.net)
17:04.57*** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl)
17:27.07*** join/#brlcad Stattrav_ (~Stattrav@117.192.132.186)
17:58.25*** join/#brlcad PrezWhiteCalf (MK@whitecalf.net)
18:04.45*** join/#brlcad Stattrav (~Stattrav@117.192.128.94)
18:04.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:14.13CIA-38BRL-CAD: 03brlcad * r42502 10/brlcad/trunk/configure.ac: add another section to force 32-bit compilation flags if 64-bit build is specifically disabled. undoubtedly more needed, but this moves us forward.
18:28.07*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
18:40.00CIA-38BRL-CAD: 03erikgreenwald * r42503 10/rt^3/trunk/tests/libpkgcpp/CMakeLists.txt: add TCL include path
18:44.55*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
18:45.13*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ)
18:45.42*** join/#brlcad DaveLo (~claymore@BZ.BZFLAG.BZ)
19:06.29CIA-38BRL-CAD: 03erikgreenwald * r42504 10/brlcad/trunk/src/libfb/ (fb_generic.c fb_obj.c tcl.c): wrap #include <strings.h> in #ifdef HAVE_STRINGS_H, since msvc does not.
19:23.39RalithO.o
19:23.44RalithMSVC doesn't have strings.h?
19:23.51Ralithisn't that required by the standard?
19:41.00brlcadmsvc is not c99 compliant (they only care about c++)
19:41.16Ralith:/
19:41.58CIA-38BRL-CAD: 03brlcad * r42505 10/brlcad/trunk/src/librt/CMakeLists.txt: ignore nmg_junk.c
19:43.15CIA-38BRL-CAD: 03brlcad * r42506 10/brlcad/trunk/configure.ac: mac wants i386 for universal binaries
20:05.26*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
20:21.27CIA-38BRL-CAD: 03starseeker * r42507 10/brlcad/branches/cmake/src/other/incrTcl/ (itcl/CMakeLists.txt itk/CMakeLists.txt): Try using STUBS, looking at the makefile.vc files... still not functioning
20:37.44CIA-38BRL-CAD: 03starseeker * r42508 10/brlcad/branches/cmake/doc/html/CMakeLists.txt: Put the archer ico file where it is expected - this probably belongs in tclscripts with the other archer image files.
21:43.24CIA-38BRL-CAD: 03starseeker * r42509 10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: Try using TK_VERSION here, not the two individual numbers
21:56.54*** part/#brlcad epileg (~epileg@unaffiliated/epileg)
22:30.26*** join/#brlcad mafm_ (~mafm@239.Red-83-49-86.dynamicIP.rima-tde.net)
22:42.20starseekerhmm - if I manually redefine itk::Toplevel, archer loads
22:42.27starseeker<PROTECTED>
23:16.56CIA-38BRL-CAD: 03starseeker * r42510 10/brlcad/branches/cmake/src/tclscripts/archer/itk_redefines.tcl:
23:16.56CIA-38BRL-CAD: This is NOT the solution to Archer not starting up on Windows - there is
23:16.56CIA-38BRL-CAD: something fundamentally wrong with the Itk that bwish reports as loaded with a
23:16.56CIA-38BRL-CAD: 'package require Itk'. This appears to work, so add it primarily to identify
23:16.56CIA-38BRL-CAD: the nature of the issue.
23:57.26CIA-38BRL-CAD: 03starseeker * r42511 10/brlcad/branches/cmake/src/tclscripts/archer/itk_redefines.tcl:
23:57.26CIA-38BRL-CAD: It's the quantum bug, when you look at it it changes. A recompile now produces
23:57.26CIA-38BRL-CAD: a whole new problem - Splash is not recognized as a command despite (apparently)
23:57.26CIA-38BRL-CAD: it being in the path, and despite running successfully with the old compile.
23:57.26CIA-38BRL-CAD: Commenting out the splash screen results in a series of Archer errors. Auuuugh.
IRC log for #brlcad on 20110121

IRC log for #brlcad on 20110121

01:44.26*** join/#brlcad packrat (~sierpinsk@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
03:03.37*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
04:47.48CIA-38BRL-CAD: 03brlcad * r42512 10/brlcad/trunk/src/libbu/brlcad_path.c: realpath() may return an error, have to test for it. fall back to bu_strlcpy() if it does.
04:49.51brlcadsounds like you need to control for more variables in your build/runtime environment
04:50.58brlcade.g., compiling on a machine with no previous version compiled or installed, running and installing fully and running from specified install dir so behavior is well-defined, etc
04:51.31brlcadif that's not repeatable after taking those measure, you're probably not accounting for something or simply doing something wrong
05:36.48*** join/#brlcad Stattrav (~Stattrav@122.172.31.168)
05:36.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:03.56*** join/#brlcad Stattrav (~Stattrav@122.172.31.168)
06:03.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:08.27*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
08:36.34*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
10:11.41*** join/#brlcad mafm_ (~mafm@72.Red-83-49-86.dynamicIP.rima-tde.net)
10:51.43CIA-38BRL-CAD: 03LanderCardenasumf 07http://brlcad.org * r2435 10/wiki/User:LanderCardenasumf: New page: ===cool wiki site=== Love watching the [http://www.bbc.co.uk/ '''bbc''']
11:37.36*** join/#brlcad Elrohir (~kvirc@p5B14B475.dip.t-dialin.net)
12:26.33CIA-38BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:LanderCardenasumf]]": content was: '===cool wiki site===Love watching the [http://www.bbc.co.uk/ '''bbc''']' (and the only contributor was '[[Special:Contributions/LanderCardenasumf|LanderCardenasumf]]')
12:27.05CIA-38BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:LanderCardenasumf]] with an expiry time of infinite (account creation disabled): Spamming links to external sites
12:46.01*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:21.51CIA-38BRL-CAD: 03starseeker * r42513 10/brlcad/branches/cmake/src/other/incrTcl/ (itcl/CMakeLists.txt itk/CMakeLists.txt): old Windows build didn't use the STUB flags but did have dllEntryPoint.c - try that.
15:42.39CIA-38BRL-CAD: 03tbrowder2 * r42514 10/brlcad/trunk/src/libged/attr.c: ensure avpp is initialized in for loops (also tidy formatting)
16:17.53CIA-38BRL-CAD: 03starseeker * r42515 10/brlcad/branches/cmake/src/ (2 files in 2 dirs): Well, not doing the stubs builds gets us back to the itk Toplevel not being defined right in some subtle way. Probably should test an installed version, as all this has been running from build dir only.
16:28.08``Erikweee, slip&slide O.O
16:40.35CIA-38BRL-CAD: 03starseeker * r42516 10/brlcad/branches/cmake/src/conv/ (6 files): Hmm, latest visual studio refuses to accept the extra . in its output name even with an explicit OUTPUT_NAME setting in CMake - it is a rather odd name so go with a dash
16:41.48CIA-38BRL-CAD: 03starseeker * r42517 10/brlcad/branches/cmake/src/conv/ (g-shell-rect.1 g-shell-rect.c): rename command in files too.
16:42.11``Erikweeeee, ice, snow, slicks, power, ... slip&slide!
16:42.38``Erikoversteer once, a couple dozen understeers, a lot of idling in first to navigate, ... stupid weather, stupid gubmint
16:44.28``Erik(ok, most of the understeers were on purpose... a little fun)
16:44.53``Erikstarseeker: when're you revamping the FindBRLCAD.cmake file?
16:45.17starseekerI had figured next week - you can hit it earlier if you like?
16:46.07``ErikI added an explicite FindTCL.cmake to GS
16:46.29``Erikum, GS nees the QT network stuff, not just the base QT stuff, that's the hostaddress issue I was seeing
16:46.30starseekernods - probably a good idea
16:46.46starseekerwe're using the Qt networking layer?
16:46.56``Erikyes
16:47.00starseekerthought we were using libpkg...
16:47.09``ErikQtHostAddress
16:47.21starseekerah
16:47.25``ErikI'd be more than happy to migrate that to straight libpkg and *nix structs
16:47.39``Erikbut that's what dave put in... I do tend to be the most brutal acid test for these things :D
16:47.39starseekernods
16:48.03starseekerwas probably the simplest way to get what he needed at the time - i'd say go for it
16:48.37``Erik*shrug* I'm not going to concern myself until monday... have lots of other projects to busy me
16:49.43``Erikthe mac bundle issue, for example... the bzflag solution is inadequate, so'z I'll be nose deep in that kinda stuff, trying to figure out how to make it appealing to the sbcl guys
16:50.44``Erikif I get teh sbcl distributable approach down in a clean way... I think that'll be big stuff, like, ... huge... muves3 in a week big
16:57.34starseekersweet
17:17.50``Erikgorram
19:28.36*** join/#brlcad stevegt` (~stevegt@cislunar.TerraLuna.Org)
19:49.58*** join/#brlcad Stattrav (~Stattrav@117.192.133.29)
19:49.58*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:53.25CIA-38BRL-CAD: 03starseeker * r42518 10/brlcad/trunk/src/conv/ (5 files): change g-shell.rect to g-shell-rect in trunk too.
20:09.46brlcadstarseeker: nice update/fix on g-shell.rect, but should probably at least document the change as a minimally impacting change (probably doesn't need news given how minor, but should be documented somewhere)
20:36.08starseekerhmm... doc/deprecation.txt maybe?
20:37.36CIA-38BRL-CAD: 03starseeker * r42519 10/brlcad/trunk/doc/deprecation.txt: Make a note of g-shell.rect rename
21:12.08*** join/#brlcad mafm (~mafm@72.Red-83-49-86.dynamicIP.rima-tde.net)
22:21.46CIA-38BRL-CAD: 03brlcad * r42520 10/brlcad/trunk/src/libbu/vls.c: (log message trimmed)
22:21.46CIA-38BRL-CAD: fix a bug tom found where a '-' left-justify specifier was getting ignored if
22:21.46CIA-38BRL-CAD: the value was positive. the code already supported negative lengths for
22:21.46CIA-38BRL-CAD: left-justified printing, so the fix is really trivial to just record the flag
22:21.46CIA-38BRL-CAD: and justify accordingly. interestingly enough, at least with the bsd libc on
22:21.47CIA-38BRL-CAD: mac os x 10.6, -* with a negative length (i.e., a double-negative) also
22:21.48CIA-38BRL-CAD: left-justifies, so we match that behavior here as well. technically not user
22:32.15``Erikbrlcad: ya testing on bz or crit, as well?
22:32.34``Erikthose'll probably be some of the more pedantic os's
22:33.51CIA-38BRL-CAD: 03bob1961 * r42521 10/brlcad/trunk/src/tclscripts/lib/RtControl.tcl: Modified RtControl::raytrace to honor the subwindow if active (.i.e. use rt's -j option).
22:34.57CIA-38BRL-CAD: 03bob1961 * r42522 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Updated Ged::init_button_no_op_prot to not disable rect draws.
IRC log for #brlcad on 20110122

IRC log for #brlcad on 20110122

00:04.15*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
01:29.57CIA-38BRL-CAD: 03bob1961 * r42523 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Added a preference to Archer for setting the display font size.
01:44.12*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
03:11.48CIA-38BRL-CAD: 03tbrowder2 * r42524 10/brlcad/trunk/src/libged/attr.c: initialize len at declaration
03:23.36CIA-38BRL-CAD: 03tbrowder2 * r42525 10/brlcad/trunk/src/libged/attr.c: improve (and simplify) format of attr show after bu_vsl_printf bug fix
05:59.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:09.44*** join/#brlcad Stattrav (~Stattrav@122.172.47.92)
07:09.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:05.10*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:01.21*** join/#brlcad mafm (~mafm@144.Red-88-23-77.staticIP.rima-tde.net)
10:33.22*** join/#brlcad mafm (~mafm@144.Red-88-23-77.staticIP.rima-tde.net)
11:43.13*** join/#brlcad mafm (~mafm@144.Red-88-23-77.staticIP.rima-tde.net)
12:50.06CIA-38BRL-CAD: 03tbrowder2 * r42526 10/brlcad/trunk/src/libged/ged.c: update preferred macro names; titdi code format
12:58.58CIA-38BRL-CAD: 03tbrowder2 * r42527 10/brlcad/trunk/src/libged/ged.c: complete missing brace for putting for loop in a block; add comment
14:20.06CIA-38BRL-CAD: 03Tbrowder 07http://brlcad.org * r2436 10/wiki/Contributor_Quickies:
15:30.57*** join/#brlcad yagami_i (~yagami_i@FL1-119-244-163-89.okn.mesh.ad.jp)
16:07.05CIA-38BRL-CAD: 03tbrowder2 * r42528 10/brlcad/trunk/src/libged/tree.c: prepare tree to use a new '-a' option;\nchanging to a flags variable to allow multiple flag args
16:07.42CIA-38BRL-CAD: 03tbrowder2 * r42529 10/brlcad/trunk/src/libged/ged.c: prepare tree to use a new '-a' option;\nchanging to a flags variable to allow multiple flag args
16:18.51CIA-38BRL-CAD: 03tbrowder2 * r42530 10/brlcad/trunk/src/libged/ged.c: added '-a' option to mged tree command: lists attributes
16:23.42CIA-38BRL-CAD: 03tbrowder2 * r42531 10/brlcad/trunk/NEWS: mged 'tree -a' option lists object attributes and is a user visible change
16:35.35CIA-38BRL-CAD: 03tbrowder2 * r42532 10/brlcad/trunk/doc/docbook/system/mann/en/tree.xml: update docs for the mged tree command for the new '-a' option
17:52.17*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
18:32.11CIA-38BRL-CAD: 03johnranderson * r42533 10/brlcad/trunk/ (3 files in 3 dirs): dbconcat now has additional options to process the title, units, and color table from the incoming database.
19:10.22*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
19:10.22*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
19:16.19CIA-38BRL-CAD: 03brlcad * r42534 10/brlcad/trunk/src/libdm/dm-X.c: leave a note where mac apps often crash if you end up linking against the system Tcl/Tk frameworks. should convert to funcs instead of calling macros so the crash can be avoided.
19:20.46CIA-38BRL-CAD: 03brlcad * r42535 10/brlcad/trunk/include/bu.h:
19:20.46CIA-38BRL-CAD: fix a compilation warning where gcc 4.2+ warns about using void*'s in
19:20.46CIA-38BRL-CAD: arithmetic. intel compiler did the same thing and the change made was to simply
19:20.46CIA-38BRL-CAD: assume that the pointer address is the memory offset. not a great assumption,
19:20.46CIA-38BRL-CAD: but go with that for now.
19:37.32CIA-38BRL-CAD: 03brlcad * r42536 10/brlcad/trunk/ (187 files in 26 dirs):
19:37.32CIA-38BRL-CAD: eat our own dogfood. all of the DIR_* macros were deprecated a couple years ago
19:37.32CIA-38BRL-CAD: in r32755 and renamed to include an RT_ prefix. even though this is a minimally
19:37.32CIA-38BRL-CAD: impacting change according to our present-day deprecation rules, continue with
19:37.32CIA-38BRL-CAD: the deprecation since this will likely affect third-party code. update all of
19:37.32CIA-38BRL-CAD: our uses to use RT_DIR_*.
20:14.04CIA-38BRL-CAD: 03brlcad * r42537 10/brlcad/trunk/NEWS:
20:14.04CIA-38BRL-CAD: john anderson added support to the mged dbconcat command for improting title,
20:14.04CIA-38BRL-CAD: units, and color tables from the _GLOBAL attribute object via -t, -u, -c options
20:14.04CIA-38BRL-CAD: respectively. this lets you import a .g database and bring those values in to
20:14.04CIA-38BRL-CAD: the current database.
21:06.41CIA-38BRL-CAD: 03brlcad * r42538 10/brlcad/trunk/src/liboptical/photonmap.c: clean up function sig decl, style consistency
21:13.11CIA-38BRL-CAD: 03brlcad * r42539 10/brlcad/trunk/src/liboptical/photonmap.c: reorder to avoid forward decls
23:03.36CIA-38BRL-CAD: 03starseeker * r42540 10/brlcad/branches/cmake/ (298 files in 48 dirs): Update cmake branch to trunk r42539
23:26.11CIA-38BRL-CAD: 03brlcad * r42541 10/brlcad/trunk/src/liboptical/ (photonmap.c wray.c): check the return values of fwrite() and fread() for failures.
23:31.36CIA-38BRL-CAD: 03brlcad * r42542 10/brlcad/trunk/src/conv/step/ (4 files): initialize values that might otherwise get accessed unintentionally.
23:33.51CIA-38BRL-CAD: 03brlcad * r42543 10/brlcad/trunk/src/libged/ (10 files): check a slew of return values for libc i/o functions that warrant checking including fscanf, scanf, system, dup, pipe, read, write, fread, and fwrite.
23:45.19CIA-38BRL-CAD: 03brlcad * r42544 10/brlcad/trunk/src/conv/iges/g-iges.c: untested fix for the problem of curtree being potentially clobbered during bu exception handling. separate jump logic out into a separate function frame.
23:52.47CIA-38BRL-CAD: 03brlcad * r42545 10/brlcad/trunk/src/conv/iges/g-iges.c: don't need to check curtree, db_free_tree accepts null trees.
IRC log for #brlcad on 20110123

IRC log for #brlcad on 20110123

00:16.47*** join/#brlcad DX^ (~DX@c-71-59-50-121.hsd1.ga.comcast.net)
00:21.43CIA-38BRL-CAD: 03tbrowder2 * r42546 10/brlcad/trunk/ (5 files in 3 dirs): change it's to its for proper spelling of possessive form of 'it'
00:42.39CIA-38BRL-CAD: 03brlcad * r42547 10/brlcad/trunk/include/vmath.h:
00:42.39CIA-38BRL-CAD: add four new macros: VINITALL(), VINIT_ZERO, MAT_INIT_IDN, and MAT_INIT_ZERO.
00:42.39CIA-38BRL-CAD: they create initialization statements suitable for declaration initialization so
00:42.39CIA-38BRL-CAD: you don't have to declare variables and then initialize them on separate lines
00:42.39CIA-38BRL-CAD: with corresponding VSETALL(), VSETALL(0.0), MAT_IDN(), and MAT_ZERO() calls.
00:42.39CIA-38BRL-CAD: this idea was prompted by former Joe Doliner (via an otherwise unusable patch
00:42.40CIA-38BRL-CAD: 2805742) for common vector/matrix initialization.
00:57.47CIA-38BRL-CAD: 03brlcad * r42548 10/brlcad/trunk/src/libged/tables.c: put MAT_INIT_ZERO to work
00:58.35CIA-38BRL-CAD: 03brlcad * r42549 10/brlcad/trunk/src/libbn/mat.c: a thing of beauty. reduction via MAT_INIT_IDN.
01:41.54CIA-38BRL-CAD: 03brlcad * r42550 10/brlcad/trunk/src/mged/tedit.c: er, there's not much value in comparing a pointer with a string literal for equality. probably meant compare the strings themselves.
03:00.17CIA-38BRL-CAD: 03tbrowder2 * r42551 10/brlcad/trunk/src/ (75 files in 41 dirs): change it's to proper spelling of its for possession
04:25.25CIA-38BRL-CAD: 03brlcad * r42552 10/brlcad/trunk/BUGS: mouse bindings on 10.6 are wrong. no zoom in?
04:26.52CIA-38BRL-CAD: 03brlcad * r42553 10/brlcad/trunk/src/libdm/dm-X.c: remove debug code
05:24.40*** join/#brlcad yagami_i (~yagami_i@FL1-119-244-163-89.okn.mesh.ad.jp)
05:29.31CIA-38BRL-CAD: 03brlcad * r42554 10/brlcad/trunk/src/rt/view_bot_faces.c: initialize all structparse fields
05:30.17CIA-38BRL-CAD: 03brlcad * r42555 10/brlcad/trunk/src/rt/ (hurt.c opt.c rtexample.c rtwalk.c sh_tcl.c): mark unused params, make get_args take a const char *[], eliminate some exact floating point comparisons.
05:35.16*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
05:40.07CIA-38BRL-CAD: 03brlcad * r42556 10/brlcad/trunk/include/rtprivate.h: rtprivate has a reference to get_args() so update with constness change.
05:40.17CIA-38BRL-CAD: 03brlcad * r42557 10/brlcad/trunk/src/ (21 files in 7 dirs): use the new vmath VINITALL(), VINIT_ZERO, MAT_INIT_IDN, MAT_INIT_ZERO macros pervasively for reduction refactor savings. reduced 160 initialization lines to less than 60.
05:40.47CIA-38BRL-CAD: 03brlcad * r42558 10/brlcad/trunk/src/proc-db/ (brep_cube.cpp brep_simple.cpp): quell warnings -- mark unused params and check init args.
05:46.48CIA-38BRL-CAD: 03brlcad * r42559 10/brlcad/trunk/src/ (10 files in 6 dirs):
05:46.49CIA-38BRL-CAD: quell verbose compilation warnings by checking the return status for libc i/o
05:46.49CIA-38BRL-CAD: functions like fread/fwrite/system. avoid clobbering variables due to bu
05:46.49CIA-38BRL-CAD: exception handling by marking variables static and moving the critical section
05:46.49CIA-38BRL-CAD: into its own function frame. make sure variables are initialized before use
05:46.49CIA-38BRL-CAD: (even when the compiler is wrong).
06:48.34CIA-38BRL-CAD: 03brlcad * r42560 10/brlcad/trunk/src/conv/ (17 files in 7 dirs): (log message trimmed)
06:48.34CIA-38BRL-CAD: slew of the remainder verbose compilation warnings for src/conv. ridiculous
06:48.34CIA-38BRL-CAD: repetition on the converters, yet frustratingly slightly inconsistent enough to
06:48.34CIA-38BRL-CAD: require careful manual review and tweaking. added process_boolean() and
06:48.34CIA-38BRL-CAD: sometimes process_triangulation() functions to all of the converters that
06:48.34CIA-38BRL-CAD: perform libbu exception handling so that we can quell warnings about data be
06:48.35CIA-38BRL-CAD: clobbered if an exception occurred. all of the process_boolean() functions are
06:48.55CIA-38BRL-CAD: 03brlcad * r42561 10/brlcad/trunk/src/conv/Makefile.am: all clear now compiling on mac and linux. woo hoo.
10:25.29*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
14:22.11brlcadwoo hoo! .. down to approximately 2000 warnings
14:23.18brlcadconsiderable considering we were at least high-five-digits to begin with
17:59.02*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
20:38.16Ralithhigh-five digits
20:38.16Ralithheh
21:10.17*** part/#brlcad CIA-38 (~CIA@208.69.182.149)
21:31.06*** join/#brlcad CIA-4 (~CIA@208.69.182.149)
21:33.02CIA-4BRL-CAD: 03starseeker * r42562 10/brlcad/branches/cmake/ (12 files in 9 dirs): Get the NSIS installer from CMake closer to the old BRL-CAD installer
21:35.40starseekerGetting much closer:  http://bzflag.bz/~starseeker/BRLCAD-7.18.1-win32.exe
21:36.44starseekerprobably some details to tweak, and need docbook docs, but at least here it launches MGED and Archer
21:37.24starseekerheads back to Linux...
21:39.37starseekerah, much better
22:25.26*** join/#brlcad CIA-58 (~CIA@208.69.182.149)
23:22.23*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
23:26.43*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
23:26.43*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
IRC log for #brlcad on 20110124

IRC log for #brlcad on 20110124

03:43.27*** join/#brlcad PrezKennedy (MK@whitecalf.net)
04:07.41brlcadRalith: even where we started from is still *way* better than most .. it was the extent at which warnings were enabled (basically almost everything gcc will report, far more than the default) ... plus the sheer size of the codebase
04:15.20Ralithnod
05:24.55RalithBRL-CAD can be built without X, right?
05:25.08Ralithor its underlying components, anyway
05:29.25*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:27.00brlcadRalith: yes, that's possible
06:27.35brlcadnot a frequently tested configuration, so there may be a minor edit you'll have to make here or there to make sure the x11 components are disabled
06:27.51brlcadbut it should be as simple as --without-x
06:28.24brlcadgets support for binary-incompatible v4 geometry database working
06:29.04Ralithgreat
07:03.34CIA-58BRL-CAD: 03brlcad * r42564 10/brlcad/trunk/ (11 files in 11 dirs): (log message trimmed)
07:03.35CIA-58BRL-CAD: implement initial support for reading in binary-incompatible v4 geometry
07:03.35CIA-58BRL-CAD: database files without the need for performing a dbupgrade on matching hardware.
07:03.36CIA-58BRL-CAD: user specifies a flip via a flag to opendb within mged that flips the version
07:03.36CIA-58BRL-CAD: number (i.e., dbi_version changes from 4 to -4), marks the database read-only
07:03.37CIA-58BRL-CAD: (mixed encodings would be disaster), and proceeds to flip the floating point
07:03.37CIA-58BRL-CAD: falues during import. possibly only works for arbs, halfspaces, tgc, grips,
07:52.14*** join/#brlcad yagami_i (~yagami_i@FL1-119-244-163-89.okn.mesh.ad.jp)
10:13.05*** join/#brlcad Stattrav (~Stattrav@122.172.17.180)
10:13.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:27.19*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
10:51.15*** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no)
11:22.33*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
11:49.57CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2437 10/wiki/GeometryServiceNetworkProtocol: Rename title for clarity
11:51.17DaveLoMernin all.
12:07.46*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:07.52CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2438 10/wiki/GeometryServiceNetworkProtocol: Enter more of the libPKG header use description.
12:41.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:09.29CIA-58BRL-CAD: 03d_rossberg * r42565 10/brlcad/trunk/src/libged/nirt.c: _WIN32 needs the ret variable too
13:47.02starseekerbrlcad: awesome!
14:17.38DaveLogo go no dbupgrade!
14:17.39CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2439 10/wiki/GeometryServiceNetworkProtocol: Define libPKG header components
15:14.19CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2440 10/wiki/GeometryServiceNetworkProtocol: More details in libPKG header part.
16:37.55CIA-58BRL-CAD: 03starseeker * r42566 10/brlcad/branches/cmake/src/other/incrTcl/itk/CMakeLists.txt: Er, that's not win32 specific.
16:41.12*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
16:49.43*** join/#brlcad Nohla (~Nohla@64.76.19.227)
17:16.56CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2441 10/wiki/GeometryServiceNetworkProtocol: Flesh out the GSNet portion of the Header info a bit.
17:42.56CIA-58BRL-CAD: 03brlcad * r42567 10/brlcad/trunk/ (53 files in 6 dirs):
17:42.56CIA-58BRL-CAD: copy-paste code hell. remove the proliferation of rtprivate.h inclusion from a
17:42.57CIA-58BRL-CAD: slew of places where it actually isn't used; they just needed the optical.h
17:42.57CIA-58BRL-CAD: header. for the rest that did use it, remove the half-assing k&r-style
17:42.58CIA-58BRL-CAD: declarations in rtoptical. this cascades a slew of updates to rtuif code that
17:42.58CIA-58BRL-CAD: didn't match the signature, and didn't match the caller.
17:59.09CIA-58BRL-CAD: 03brlcad * r42568 10/brlcad/trunk/include/rtprivate.h: remove the doxygen comments since this isn't public header API.
18:17.15CIA-58BRL-CAD: 03brlcad * r42569 10/brlcad/trunk/ (34 files in 4 dirs): move rtprivate out of include/ into src/rt/ and update references accordingly. looks like remrt and rttherm are the only two deep referencers.
18:53.34CIA-58BRL-CAD: 03brlcad * r42570 10/brlcad/trunk/src/ (33 files in 3 dirs): rename rtprivate.h to rtuif.h to better match the intended purpose. expand the API documentation with the comments from http://brlcad.org/w/images/3/3d/Application_Development.pdf by Anderson and Butler.
18:55.20CIA-58BRL-CAD: 03starseeker * r42571 10/brlcad/branches/cmake/src/other/incrTcl/itk/CMakeLists.txt: Add STATIC flag
19:03.21brlcadthis is restaurant week in baltimore, lots of great dinner deals to be had...
19:03.51brlcadstarseeker: made it to fogo yet? :-)
19:04.17starseekernot yet - hoping to go soon
19:04.22brlcadthinks he might have to make it there sometime this week
19:04.32starseekerhad wedding this Friday to go to...
19:04.33brlcadtheir $50 dinner is $35 all week :)
19:05.13brlcadagain??  didn't you just get married? <wry grin>
19:07.21starseekerheh - yeah, been going to a lot of weddings
19:07.56starseekerwife's family is local, and somewhat older than my side (where I'm the oldest) so it's kinda a perfect storm generationally speaking
19:11.19CIA-58BRL-CAD: 03starseeker * r42572 10/brlcad/branches/cmake/ (misc/CMake/FindTCL.cmake src/other/CMakeLists.txt): Don't go through the whole search song and dance if we already have the TCL variables we need - should help when FindTCL is called multiple times too
19:20.08CIA-58BRL-CAD: 03brlcad * r42573 10/brlcad/trunk/src/rt/ (do.c ext.h opt.c rtuif.h): move the non-rtuif functions and globals from rtuif.h into ext.h header. found inconsistent size_t decls on incr_level and incr_nlevel along the way.
19:22.46CIA-58BRL-CAD: 03brlcad * r42574 10/brlcad/trunk/src/rt/do.c: remove unnecessary declarations
19:24.45CIA-58BRL-CAD: 03brlcad * r42575 10/brlcad/trunk/src/rt/ (ext.h viewfrac.c viewrad.c viewscat.c): remove authorship per hacking
19:28.49CIA-58BRL-CAD: 03brlcad * r42576 10/brlcad/trunk/src/rt/ext.h: ws cleanup
19:35.23CIA-58BRL-CAD: 03brlcad * r42577 10/brlcad/trunk/src/rt/ (hurt.c main.c reshoot.c rtshot.c rtuif.h rtwalk.c): eliminate RT_BUFSIZE. it's not RT API and not necessary regardless since rt_dirbuild() is fed sizeof(idbuf). arbitrarily increase from 1024 to 2048 (v4 was 132).
20:00.12epileghello
20:00.25brlcadhowdy epileg !
20:00.42epileghi brlcad!
20:01.50epilegwell, today i've done some compilation but without success till enabling everything
20:01.57brlcad:)
20:02.13brlcadit definitely gets a lot more tricky when you leave our management of dependencies
20:03.00brlcaddo you describe the required dependencies when you disable their compilation?
20:04.06epileghow?
20:04.49brlcadI don't have a debian system available to tell you that :)
20:04.59epilegok
20:05.45epilegjust a question. how i can know the minimun version of shared libraries needed by brlcad  
20:05.47epileg?
20:06.21brlcadfor what mafm worked on, dependencies are described in the "control" file, see misc/debian/control
20:06.43brlcadthat has minimums listed too
20:07.55CIA-58BRL-CAD: 03brlcad * r42578 10/brlcad/trunk/src/mged/ (Makefile.am chgview.c dir.c): remove a slew of dead code unveiled after searching for callers.
20:08.36CIA-58BRL-CAD: 03brlcad * r42579 10/brlcad/trunk/src/mged/qray.c: entire file is no longer used, logic migrated to libged
20:09.09epilegbrlcad: do you mean "control" file of misc/debian/?
20:09.36brlcadyes
20:10.17epilegwell, here aren't all the needed libraries
20:11.49epilega want to know, i.e. the minimun version of png dev library. in ubuntu the actual version is 1.2.44, but brlcad may need some newer one, isn't it?
20:13.44brlcadnot really
20:13.46CIA-58BRL-CAD: 03brlcad * r42580 10/brlcad/trunk/src/mged/fbserv_win32.c: more dead code elimination. looks like the fbserv_win32 interface was a big hack job.
20:19.00brlcadit's not clear what the actual minimum required is .. feature wise, probably anything 1.0+ will work; code wise, probably anything 1.2+
20:19.28epilegaha
20:21.37epilegok, is there a way to test every component (i.e. png) of an installed brlcad?
20:44.21brlcad"make benchmark" is the core competency test, "make test" will also work on some platforms
20:44.50epilegok
20:45.08brlcadafter install, testing becomes a manual process -- HACKING file describes the testing steps near the end
20:47.22epilegthank You brlcad
21:27.11CIA-58BRL-CAD: 03brlcad * r42581 10/brlcad/trunk/src/mged/ (7 files): more dead code elimination. more than 800 lines poof.
21:42.44CIA-58BRL-CAD: 03erikgreenwald * r42582 10/brlcad/trunk/src/libged/editit.c: avoid shadowing stat
21:52.04CIA-58BRL-CAD: 03brlcad * r42583 10/brlcad/trunk/ (6 files in 4 dirs): db_shader_mat() renamed to rt_shader_mat()
22:03.17CIA-58BRL-CAD: 03brlcad * r42584 10/brlcad/trunk/src/libbn/globals.c: replace all of the numeric literals with vmath references.
22:15.23CIA-58BRL-CAD: 03starseeker * r42585 10/brlcad/branches/cmake/src/other/togl/: Remove old togl dir in preparation for attempt at CMake togl
22:26.20CIA-58BRL-CAD: 03brlcad * r42586 10/brlcad/trunk/src/ (23 files in 16 dirs): use libbn math constants. use vmath's M_PI and related defines along with DEG2RAD & RAD2DEG conversions where appropriate.
22:42.56*** join/#brlcad Ralith (~ralith@d142-058-093-041.wireless.sfu.ca)
23:20.37CIA-58BRL-CAD: 03starseeker * r42587 10/brlcad/branches/cmake/src/other/ (169 files in 17 dirs):
23:20.38CIA-58BRL-CAD: Initial stab at togl + CMake, based off my github fork with some changes. In
23:20.39CIA-58BRL-CAD: particular, scary change to glxext.h to work around a conflict with glx.h on the
23:20.39CIA-58BRL-CAD: Mac - need to see what glfw does with that situation and make it less scary.
23:20.40CIA-58BRL-CAD: Almost certainly this isn't portable yet.
IRC log for #brlcad on 20110125

IRC log for #brlcad on 20110125

00:02.35CIA-58BRL-CAD: 03starseeker * r42588 10/brlcad/branches/cmake/src/other/togl/ (demo/CMakeLists.txt src/Xmu/LookupCmap.c src/Xmu/StdCmap.c): Tweaks for building on Linux
00:33.53CIA-58BRL-CAD: 03starseeker * r42589 10/brlcad/branches/cmake/src/other/togl/src/CMakeLists.txt: Conditionalize the Xmu sources to X11
00:57.55*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
00:57.55*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
02:30.04*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
03:03.42*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
03:24.54CIA-58BRL-CAD: 03brlcad * r42590 10/brlcad/trunk/src/conv/Makefile.am:
03:24.55CIA-58BRL-CAD: this is likely the cause of the build failure that tom browder expressed on the
03:24.55CIA-58BRL-CAD: mailing list where compilation in src/conv failed due to some c++ warning.
03:24.56CIA-58BRL-CAD: while the majority of c++ code (step, intaval) compiles without -Werror, the
03:24.56CIA-58BRL-CAD: 3dm-g converter sources were being compiled with the same AM_CPPFLAGS which now
03:24.57CIA-58BRL-CAD: includes -Werror. to make 3dm-g not compile without the strict flags, they have
03:24.57CIA-58BRL-CAD: to be distributed to all the other binaries accordingly.
03:55.52CIA-58BRL-CAD: 03brlcad * r42591 10/brlcad/trunk/src/burst/Sc.c: curious new failure. termios.h may define VMIN which conflicts vmath, so undef it.
05:01.14*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
05:22.09*** join/#brlcad Stattrav (~Stattrav@122.172.15.195)
05:22.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:58.31*** join/#brlcad Stattrav (~Stattrav@122.172.15.195)
05:58.36*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:18.32*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
09:11.27*** join/#brlcad Stattrav (~Stattrav@122.172.15.195)
09:11.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:17.15*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
09:17.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:20.49*** join/#brlcad jay_ (~jay@212.96.10.253)
09:22.17jay_anyone here?
10:17.39*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:42.39jay_anyone here
11:46.02DaveLomernin all!
11:46.12DaveLohowdy jay_ !  What's up?
11:48.45jay_DaveLo: looking for a good tutorial on drawing a floor plan
11:49.38jay_DaveLo: have you tried using qcad
11:50.35DaveLoNope, can't say that I have.  I'm primarily a BRL-CAD modeler, with some exp in Blender, 3DSmax and Maya.
11:51.23jay_ok. thnx
11:52.26alex_jonijay_: floor plan as in for a house?
11:53.03jay_alex_joni: yes
11:53.41alex_jonithere are some programs specialized in that
11:53.52alex_joniI used 3D-Home a long time ago
11:54.51jay_does it do 2d and is it as advanced as autocad
11:55.35alex_joninope
11:55.58jay_ok. thnx
11:56.12alex_jonibut I think I remember some Autocad plugins for that
11:56.44jay_ok. i'll check it out.
14:57.42CIA-58BRL-CAD: 03erikgreenwald * r42592 10/brlcad/trunk/misc/win32-msvc8/ (g2shellrect/g2shellrect.vcproj mged/mged.vcproj): reflect renaming/dead code removal
15:27.10*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
15:52.37*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:53.13DaveLoThis is actually pretty darn good for a fan film: http://www.joystiq.com/2011/01/24/fallout-nuka-break-fan-film/
15:57.02``Erikis that what all the noise was earlier?
15:57.19DaveLoguns and stuff?
15:57.35``Erikyeah, richard said it sounded like a video game and was wondering if it was my computer O.o :D
15:58.08DaveLoso...i need to pipe it thru the big speakers and run the video again... is that what you're saying? =D
15:59.13``Erikwas joking about cranking up my system and having a sub war, he didn't seem thrilled
15:59.26``Erikand the dudes upstairs would come down and say "can you turn it down? we can't feel our feet anymore"
16:00.04DaveLosimple: Lock your door!
16:20.47CIA-58BRL-CAD: 03brlcad * r42593 10/brlcad/trunk/TODO: can open binary-incompatible v4
16:36.44CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2442 10/wiki/GeometryServiceNetworkProtocol: Flesh out Data a bit.
16:43.35CIA-58BRL-CAD: 03brlcad * r42594 10/brlcad/trunk/src/libbu/brlcad_path.c: expand ipwd so that it uses realpath() if available. expand paths found with getenv() and attempt expanding '.' if that fails or is skipped.
16:45.19CIA-58BRL-CAD: 03brlcad * r42595 10/brlcad/trunk/TODO: needs testing, but ipwd should be better now
16:48.55CIA-58BRL-CAD: 03brlcad * r42596 10/brlcad/trunk/TODO: save g_ renaming until 7.20
16:53.23CIA-58BRL-CAD: 03brlcad * r42597 10/brlcad/trunk/src/conv/Makefile.am: everyone needs CFLAGS, and fastf4-g isn't quite what was intended
18:23.56CIA-58BRL-CAD: 03starseeker * r42598 10/brlcad/branches/cmake/ (9 files in 9 dirs): Use the more specific and thorough test for termlib, instead of Curses. While we're at it, add (conditionally) togl to the build.
19:00.08CIA-58BRL-CAD: 03erikgreenwald * r42599 10/rt^3/trunk/tests/utility/configTest.cxx: QString is in .../QtCore/
19:00.24CIA-58BRL-CAD: 03erikgreenwald * r42600 10/rt^3/trunk/tests/libNet/CMakeLists.txt: add tcl include path
19:00.37CIA-58BRL-CAD: 03erikgreenwald * r42601 10/rt^3/trunk/CMakeLists.txt: search for QT Networking up front
19:03.56CIA-58BRL-CAD: 03starseeker * r42602 10/brlcad/branches/cmake/misc/CMake/NSIS.template.in: Make a stab at conditionalizing the installation of the Desktop icons for NSIS installer
19:05.29*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
19:29.47*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
19:33.33*** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201)
21:13.32CIA-58BRL-CAD: 03erikgreenwald * r42603 10/brlcad/trunk/src/conv/nmg/asc-nmg.c: change stat to status to avoid shadowing. indent.
21:14.32CIA-58BRL-CAD: 03starseeker * r42604 10/brlcad/branches/cmake/misc/CMake/NSIS.template.in: Try pointing to the installed readme file
21:30.54*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
21:31.57CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2443 10/wiki/NetMsgTypes:
21:36.25*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
21:43.57CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2444 10/wiki/NetMsgTypes: First round of formatting/editing for NetMsg Types. Eventually, this will be a Doxy file.
22:09.53CIA-58BRL-CAD: 03starseeker * r42605 10/brlcad/branches/cmake/misc/CMake/NSIS.template.in:
22:09.54CIA-58BRL-CAD: Still doesn't work even after removing inappropriate SetOutPath command -
22:09.55CIA-58BRL-CAD: apparently this has NEVER worked, even with the old installer, so don't worry
22:09.55CIA-58BRL-CAD: about it. May require something like renaming the README file to have a .txt
22:09.59CIA-58BRL-CAD: extension or some such on Windows, but not worth experimenting with - just
22:09.59CIA-58BRL-CAD: remove.
22:20.07CIA-58BRL-CAD: 03starseeker * r42606 10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: Don't keep appending more TK_CFLAGS on multiple runs - let's see if this is why tk keeps rebuilding every time
23:00.01CIA-58BRL-CAD: 03starseeker * r42607 10/brlcad/branches/cmake/CMakeLists.txt: Cache either way, so it doesn't pop up in the gui (hopefully, untested)
23:09.30CIA-58BRL-CAD: 03starseeker * r42608 10/brlcad/branches/cmake/ (CMakeLists.txt src/other/togl/src/CMakeLists.txt): Remove debug messages.
23:11.01CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2445 10/wiki/NetMsgTypes: Added TODO
23:23.40CIA-58BRL-CAD: 03erikgreenwald * r42609 10/brlcad/branches/bottie/ (859 files in 134 dirs): MFC 42604
23:28.56starseekeryay huge merges
23:29.14starseekercan't wait for the next rel8 sync
23:52.45``Erikheh
23:56.20starseekermerges trunk into cmake and watches the crawl...
IRC log for #brlcad on 20110126

IRC log for #brlcad on 20110126

00:16.47``Erikheh, yeah, uh, the bottie merge there took a few hours
00:17.51``ErikI imagine I'll have to do a quick followup tomorrow along with the "number_of_triangles" hack and backing the ray up a micron, then see how bad I screw trunk up
00:20.54starseekerhrm
00:21.31starseekerpossible issue...
00:21.52starseekerlibbn/mat.c:54: error: MAT_INIT_IDN undeclared here (not in a function)
00:26.15starseekertries a clean build
00:29.37``Erikdid any conflicts list?
00:29.52starseekernot in CMake (at least not that I saw)
00:29.58``Erikduring the merge
00:30.10starseekeryeah, didn't see any
00:30.31``Erikfunky, I always seem to get at least one
00:31.00starseekerI do get some on occasion, usually when I've done something in the cmake branch first and then in trunk
00:31.11starseekeryeah, libbn builds now
00:31.34starseekeroh, bet it was using the old copy in the build directory's include dir
00:31.40starseekerdur
00:32.47CIA-58BRL-CAD: 03starseeker * r42610 10/brlcad/branches/cmake/ (249 files in 76 dirs): Update cmake branch to trunk r42609
00:34.12CIA-58BRL-CAD: 03starseeker * r42611 10/brlcad/branches/cmake/ (include/CMakeLists.txt src/mged/CMakeLists.txt): Remove files no longer present from CMakeLists.txt files
00:43.00starseekerbrlcad: is that new rtuif.h header supposed to be installed?
00:43.39``Erikit's the new rt_private.h, I don't think it is
00:43.53starseekerk
00:44.08starseekerah, right
00:44.14starseekerin src/rt, not include
00:45.53brlcadit's a private header, fixed a problem
00:46.18starseekernods - yeah, was reading the list wrong, my bad
01:00.33starseekerinteresting I'm getting a bu_ipwd crash with the cmake build on mac
01:02.41brlcadhm, entirely possible -- I didn't get the chance to test my fix before heading in to the meeting
01:02.56brlcadany particular test sequence?
01:03.01starseekerProgram received signal EXC_BAD_ACCESS, Could not access memory.
01:03.01starseekerReason: KERN_PROTECTION_FAILURE at address: 0x00000000
01:03.01starseeker0x93a266b7 in realpath$DARWIN_EXTSN ()
01:03.12brlcadrealpath was given a null
01:03.17starseekerlibbu/brlcad_path.c:100
01:03.34starseekerI don't see how, and gdb doesn't think ipwd is null...
01:04.09brlcadhm
01:04.18brlcadmight be a difference between bsd and linux realpath()
01:04.27brlcadwhat does your manual page say for the second argument?
01:05.09brlcadI pass NULL for the result since bsd realpath() will use that as a key to malloc and pass the result back as the return value
01:05.19brlcadthe first param shouldn't be null..
01:05.39brlcadoh, DARWIN .. you're on mac too..
01:05.53starseekerah, that could be why - I think the proper handling of second argument being NULL in realpath is only guaranteed by POSIX 2008
01:08.31starseekerconsidered snarfing GNU's canonicalize_file_name function and putting that into libbu, but it kinda seemed like overkill...
01:10.37CIA-58BRL-CAD: 03brlcad * r42612 10/brlcad/trunk/include/bu.h: check for PATH_MAX before _MAX_PATH
01:13.17CIA-58BRL-CAD: 03starseeker * r42613 10/brlcad/branches/cmake/src/libbu/brlcad_path.c: realpath + NULL is not happy on Mac, apparently - will this work?
01:17.39starseekerbrlcad: that seems to work here, if you don't mind the static solution - IIRC realpath only runs into trouble on operating systems like HURD that have unlimited path length, and somehow I doubt we'll be worried about running on HURD anytime soon...
01:17.54starseekerheads out
01:19.40CIA-58BRL-CAD: 03brlcad * r42614 10/brlcad/trunk/src/libbu/brlcad_path.c: unlike 10.6 and recent linux, realpath() on Mac OS X 10.5 is not set up to take NULL for the second paramter so pass in our path buffer and adjust logic accordingly.
01:20.50brlcadsimilar solution
01:24.20brlcadusually best to avoid function call return values as expressions unless the function specifically returns a boolean (e.g., isspace()); unintentional pointers and integers are common logic bugs
01:59.22CIA-58BRL-CAD: 03brlcad * r42615 10/brlcad/trunk/TODO: promote plate mode nurbs since it's scheduled for Q2, create a new project section for NURBS with added tasks for implementing implicit CSG to NURBS CSG, documenting the new primitive, and boolean evaluation.
02:15.23CIA-58BRL-CAD: 03brlcad * r42616 10/brlcad/trunk/TODO: expand, consolidate and clean up the section for NMG/BoT too
02:43.53*** join/#brlcad yukonbob (~bch@S0106001cf044d085.ok.shawcable.net)
02:43.54yukonboboh hai
03:08.31DX^Anyone alive that could explain to me how NURBS are rendered
03:08.40DX^does the program break it up into triangles?
03:08.52DX^I don't understand how it could otherwise show smooth surfaces
03:20.48*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
03:58.11starseekerDX^: it doesn't break it up into triangles
03:58.40starseekerit builds a surface tree, which provides an initial guess for a hit point which is then iterated to a solution
03:59.15starseekerwe'll get triangles eventually for tessellation and shaded displays, but the are only an approximation - the NURBS surface itself is more accurate
04:21.38starseekerbrlcad: doesn't that patch return the success/fail value of realpath instead of the result in buffer?
04:24.11starseekeroh, nevermind - I see
04:29.31starseekernifty - realpath returns what you need as the result.  not bad
04:30.53CIA-58BRL-CAD: 03starseeker * r42617 10/brlcad/branches/cmake/ (5 files in 4 dirs): Sync to trunk 42616 (mostly, brlcad_path.c patch is approximate since the Windows version of realpath is unaddressed in trunk).
05:16.25CIA-58BRL-CAD: 03brlcad * r42618 10/brlcad/trunk/TODO: little section for STEP-related tasks
08:16.33*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
09:13.26*** join/#brlcad Stattrav (~Stattrav@117.192.131.143)
09:13.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:48.06*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:18.21starseekerglares at falling snow and unplowed roads
12:31.08starseekerhmm... slashdot redesigned again
12:35.01starseekergets introduced to the Stylish Firefox plugin... nifty
13:12.24CIA-58BRL-CAD: 03starseeker * r42619 10/brlcad/trunk/src/tclscripts/ (archer/Archer.tcl mged/man.tcl): Tweak man page viewer to work in-build-dir
13:47.07brlcad<PROTECTED>
13:47.28brlcadI'd think the embedded path separators will cause problems on windows
13:47.36brlcadthat's what file join is supposed to resolve
13:47.42DaveLoMernin all
13:47.53brlcadhowdy DaveLo
13:48.12DaveLoHows you?  take the test yet?
13:49.40brlcadnot yet, still have another week or two of studying
13:49.55DaveLoah, okie.
13:50.02CIA-58BRL-CAD: 03davidloman * r42620 10/rt^3/trunk/docs/ (4 files): Adding in some .psd's for the wiki graphics.
13:50.24DaveLostares at the falling snow and is eager to get out there later and make the Ultimate Snow Fortress
14:01.48starseekerbrlcad: ok, I can try that
14:06.11CIA-58BRL-CAD: 03starseeker * r42621 10/brlcad/trunk/src/tclscripts/ (archer/Archer.tcl mged/man.tcl): Don't assume '/' for dir separators
14:08.39starseekerah, the mged one was just a typo (not sure why it didn't show up before...) archer wasn't using file join where it needed to
14:09.29CIA-58BRL-CAD: 03starseeker * r42622 10/brlcad/branches/cmake/ (5 files in 4 dirs): Update cmake branch to trunk r42621
14:39.20*** join/#brlcad Stattrav (~Stattrav@117.192.146.62)
14:39.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:41.48DaveLo``Erik: why is TCL needed in rt3?
14:45.33brlcadDaveLo: tcl.h is included by raytrace.h and bu.h
14:46.09brlcadhoping we can eliminate that inclusion at some point in the future, but decoupling from tcl in the public API is a job in itself
14:46.40DaveLoah, i see.
14:47.29DaveLois the tcl libsj included in the windows brlcad binaries install?  
14:47.49brlcadshould be
14:47.57brlcadwon't run without em
14:48.09DaveLothats what I thought.
14:48.29DaveLofor somereason, i was building rt3 just fine, but now that there is a findTCL.cmake in the works, its failing.
14:48.33DaveLo:/
14:49.57brlcadmight have been pulling some system tcl.h
14:50.25DaveLonot likely, as i don't have tcl.h on my windows system ;)
14:50.35brlcadhm, that's curious then
14:51.12brlcadnot only why it's now needing it, but how it worked before too
14:51.34DaveLoi know cmake can find the brlcad include and libs, i just don't think the cmake find is smart enough to dive down in to a subdir of brlcad/include
14:52.02DaveLoI think it was working before because if cmake can find bu.h, then bu.h knows where the tcl headers
14:52.05DaveLoare
14:52.28DaveLocmake, however, doesn't use bu.h to gain a clue where the tcl headers are.
14:52.29DaveLo:/
14:54.42DaveLobah, that's too deep of a rabit hole to dive in atm :/, i'll leave windows till later i guess.
14:56.13brlcadbu.h doesn't know, it just does a #include "bu.h"
14:56.16brlcader, tcl.h
14:58.07brlcadso something else, something really basic, is going on
14:59.30DaveLolikely something else. :/
15:01.47brlcadfwiw, include paths are build system trivialities, any dev should be able to diagnose/understand/override fix with ease
15:02.39brlcadotherwise it's like a builder not knowing how a power drill works :)
15:03.48DaveLoheh, well in that case, Im still learning about the power drills, so don't make fun =P
15:04.31brlcadnot making fun, just saying "don't fear the power drill"
15:04.51brlcador treat it like it's untouchable black magic that will take a long time to figure out
15:04.55``Erikdlo: tcl is required for bu.h
15:05.16``Erikwhen using a system that doesn't have tcl.h in /usr/include or /usr/brlcad/include, it was failing
15:07.01``Erik*readreadread* heh, yeh
15:07.08brlcadcmake adds a little extra complexity, but it's akin to adding a pneumatic compressor to your drill .. it's still a drill though ;)
15:07.19DaveLowell wait... if tcl.h is installed into a non standard location, it was failing?
15:07.25``Erikprobably need a -DTCL_INCLUDE_DIR=C:\some\path\to\brlcad\include
15:07.48DaveLoeither of you two going to be in on Friday?
15:07.57``Erikthe problem was that it was failing when tcl was installed to the standard include path... not the path that linux and BRL-CAD expect
15:08.22DaveLowhat 'standard include path' are you talking about/
15:08.24DaveLo?
15:08.30``ErikI have no plans to not be in on friday... depends on weather
15:08.33``Erik/usr/local/
15:09.43``Erikmac and linux both abuse the system header directory for user packages like package managed tcl
15:14.11``ErikO.O gtk3? hmmm
15:35.18DaveLoconfigure --enable-all or configure --enable-everything
15:35.21DaveLoi cannot remember
15:50.48brlcadthey're aliases for the same flag if it was either of those
17:27.39DaveLo5" on the ground so far.  Second wave is coming in a few hours!
17:45.25*** join/#brlcad Stattrav (~Stattrav@117.192.143.147)
17:45.25*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:26.48DaveLoOkay, round one is shoveled.  Now, bring on round two!
18:50.13CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2446 10/wiki/GSNet_String:
18:55.03CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2447 10/wiki/GSNet_String: Update table styling
18:56.10*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
18:57.43CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2448 10/wiki/GSNet_String: Adjust table width
19:02.00CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2449 10/wiki/GeometryServiceNetworkProtocol: Fixed headline
19:30.12CIA-58BRL-CAD: 03Dloman 07http://brlcad.org * r2450 10/wiki/NetMsgTypes: headline fixes and spacing.
19:49.33*** join/#brlcad Stattrav (~Stattrav@117.192.143.147)
19:49.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:07.41*** join/#brlcad CIA-53 (~CIA@208.69.182.149)
20:15.24CIA-53BRL-CAD: 03brlcad * r42623 10/brlcad/trunk/src/libged/ls.c: eliminate dead code
20:18.57*** join/#brlcad Ralith (~ralith@d142-058-078-138.wireless.sfu.ca)
20:22.52CIA-53BRL-CAD: 03brlcad * r42624 10/brlcad/trunk/src/librt/db_lookup.c: calloc our ptbl so we're initialized to zero
20:34.59CIA-53BRL-CAD: 03brlcad * r42625 10/brlcad/trunk/src/librt/db_lookup.c: v4 geometry database do not use d_major_type and d_minor_type, so zero-set accordingly as a preventive measure.
20:39.47brlcadhttps://github.com/mcneel/rhinocommon
20:40.04brlcad(they just released another sdk as open source)
20:41.37brlcadit's the C# portion of Rhino 5.0's new cross-platform SDK
20:47.06CIA-53BRL-CAD: 03brlcad * r42626 10/brlcad/trunk/src/conv/asc/g2asc.c: do not check values directly. _GLOBAL is merely an attribute-only object.
22:17.18*** join/#brlcad Ralith (~ralith@142.58.92.37)
22:20.43*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
22:20.49yukonbob_hello, #brlcasd
22:20.56yukonbob_#brlcad, even.
22:25.04yukonbob_png.h has 2 diff't prototypes for PNG_EXPORT().
22:25.44yukonbob_or... 1s; /me reviews
22:29.20*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
22:29.20*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
22:38.13yukonbob_:P nn --- conflicting header files from diff't versions of libpng.
22:38.25yukonbob_*nm
22:51.02yukonbob_q: how far along in the build process is one if asc2g conversions are running?
23:16.10brlcadhttp://itmanagement.earthweb.com/osrc/article.php/3922041/50-Open-Source-Applications-for-Sci-Tech-Education.htm
23:16.22brlcadyukonbob_: basically the build is done
23:16.39brlcadall of the sources have compiled by that point
23:23.08yukonbob_brlcad: congratulate me, then. I've got brlcad built on netbsd for first time in ~2 years.
23:23.28yukonbob_then fails, but I think I know why. I'll have some patches forthcoming.
23:25.44CIA-53BRL-CAD: 03brlcad * r42627 10/brlcad/trunk/TODO:
23:25.44CIA-53BRL-CAD: pull up annotation primitive since it's soon. also relaly need to upgrade the
23:25.44CIA-53BRL-CAD: back-end svn repo so branches can be tracked better (especially since there is a
23:25.44CIA-53BRL-CAD: major merge coming soon). push down dbcp/merg and exporting all top-level
23:25.44CIA-53BRL-CAD: objects in the converters.
23:25.44brlcadexcellent
23:25.53brlcadit's been a while since I've done a netbsd build myself
23:27.07yukonbob_I've been working on this now for last ~24 hours (not non-stop :) ) and think I've got the roadblocks solved for this particlar case... which is NetBSD -current, Tcl8.6b, and some other oddities.
23:28.53yukonbob_runtime will be another test itself... I'm not intimately familiar w/ itcl/itk, and it's a major-version bump over what brl-cad ships with... so that's be interesting.
23:32.26CIA-53BRL-CAD: 03brlcad * r42628 10/brlcad/trunk/src/libged/ls.c:
23:32.26CIA-53BRL-CAD: fix a bug with the ls command where it was printing NULL or garbage for the
23:32.26CIA-53BRL-CAD: object type if you requested an ls -la long listing. this only occurred for v4
23:32.26CIA-53BRL-CAD: geometry databases but was due to an assumption in the code that d_minor_type is
23:32.26CIA-53BRL-CAD: a suitable index into the rt_functab[] (which it's not). other commands need
23:32.26CIA-53BRL-CAD: fixing too.
23:44.02CIA-53BRL-CAD: 03brlcad * r42629 10/brlcad/trunk/src/libged/attr.c: attributes aren't valid for v4, but don't use d_minor_type as an index into rt_functab[] regardless.
23:53.55yukonbob_default installation == /usr/local/*?
23:58.09yukonbob_sees is /usr/brlcad
IRC log for #brlcad on 20110127

IRC log for #brlcad on 20110127

00:05.48CIA-53BRL-CAD: 03brlcad * r42630 10/brlcad/trunk/src/libged/ls.c: simplify. even though this is libged, there's no compelling reason to use GED_DB_GET_INTERNAL() here since it assumes a GED_OK/ERROR return value if the get fails. we don't actually care much if the get fails.
00:06.16CIA-53BRL-CAD: 03brlcad * r42631 10/brlcad/trunk/src/libged/wdb_obj.c: match ls.c and attr.c files. ugh, duplication. when can this file die?
00:06.55starseekerbrlcad: hmm - don't know how much use rhinocommon will be as C# - don't see a license either, unless I'm missing something
00:10.42*** part/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
00:12.45CIA-53BRL-CAD: 03starseeker * r42632 10/brlcad/branches/cmake/ (8 files in 5 dirs): Update cmake branch to trunk r42631
00:18.58starseekerbrlcad: what do you want to do about needing windows.h for that Win version of the realpath functionality?
00:29.25brlcadstarseeker: rhinosommon didn't seem very useful to us at all, was just interesting that they're expanding their opensourceness
00:29.38brlcadtheir press release was emphasizing that angle
00:29.59brlcadstarseeker: condtionally include windows.h in the files that call realpath?
00:30.19CIA-53BRL-CAD: 03starseeker * r42633 10/brlcad/trunk/src/other/togl/ (336 files in 16 dirs): togl is extradisted in trunk anyway, so stick the cmake branch version in to minimize differences
00:34.11starseekerbrlcad: I think that's what I did initially?  unless I misread, you didn't seem happy about a system header in libbu
00:41.40starseekerwhat the heck... what happened to the togl directory?
00:47.42starseekerchecks out other again...
00:50.20starseekerthere we go
01:16.53*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
01:36.27epilegbrlcad: ping
02:08.48*** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net)
02:08.54yukonbobhello, #brlcad
02:09.24CIA-53BRL-CAD: 03starseeker * r42634 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake): Start trying to hammer the C/CXX flags logic into shape. More to do here, but getting better (should actually be using more of the flags now...)
02:09.27starseekeryukonbob: howdy :-)
02:09.32yukonbobstarseeker: :)
02:09.40starseekerso you have things running with tcl/tk 8.6?
02:09.45yukonbobstarseeker: indeed.
02:09.50starseekertrunk?
02:09.55yukonbobfirst time I've had brlcad running natively on this box in ~2years
02:10.01yukonbob<PROTECTED>
02:10.06starseekerheh
02:10.16starseekerare you using trunk or an older version?
02:10.20yukonbobfwiw that fscking *sucked* *sucked* *sucked* *sucked* *sucked*.
02:10.45starseeker8.5 gives us modern stuff like the new tree widget
02:11.02yukonbobmoving to 8.5 while it was in beta had me fall off the wagon.
02:11.15starseekerah, back in the day
02:11.24starseeker(was gonna say, 8.5 has been stable for a while...)
02:11.27yukonbobnot trying to be a drama queen, just stating the facts.
02:11.55starseekeryukonbob: you should be happy then we haven't gone leaping onto the 8.6 bandwagon yet :-P
02:12.01yukonbobwas helping push the boundaries of tcl 8.4 back in the day :P
02:12.16yukonbobstarseeker: what's the holdup -- I'm here now!!!1!
02:12.24yukonbob;)
02:12.30starseekerwhat were the issues with 8.6?
02:12.37starseekerthe one attempt I made didn't go so well
02:13.06yukonbobI *just* fired up mged... and have done *some* runtime patching, but haven't tested exhaustively.
02:13.14starseekernods
02:13.18starseekerfurther than I got
02:13.24starseekerare you using trunk?
02:13.27yukonboby
02:13.42yukonbobI've been running trunk for.... maybe a year now?
02:13.48yukonbobon NetBSD cvs -head.
02:13.49starseekercool - hopefully using only package require for things like itcl/itk helped...
02:14.04yukonbobheh -- thats one of the things I patched ;)
02:14.17starseekerhmm?  you went back to the C api?
02:14.57yukonbobno, but had to adjust for version #s
02:15.01starseekerah
02:15.28starseekerwhen I tried 8.6 we were still talking to itcl/itk at the C level... Something Wasn't Happy
02:15.52yukonbobanyway... it's literally been a few years since I've been in mged -- I'm going to re-introduce myself to it, and shake-out bugs as they present themselves
02:16.05starseekerwasn't urgent enough for me to dig deep, since package require was obviously a better way and the main benefit of 8.6 was the Cocoa backend on Mac
02:16.13starseekerwelcome back :-)
02:16.20yukonbobya, thanks ;)
02:16.24starseekeryou might check out archer - it's had a lot of work done
02:16.46yukonbobis going to get his name back into the changelogs...
02:17.00yukonbobarcher != tcl/tk, correct?
02:17.28yukonbobya -- when I was last using brlcad, I think archer was in design phase, or maybe "Hey, I've got an idea' phase.
02:18.39starseekerno, archer is tcl/tk
02:18.46CIA-53BRL-CAD: 03starseeker * r42635 10/brlcad/branches/cmake/CMakeLists.txt: Uh, whoops - add the flags if the build type IS set, not when it isn't...
02:18.48starseekerone of the drivers for using 8.5, actually
02:19.12starseekerit's not all the way there yet, but there's some cool new stuff
02:19.18starseekertree widget is especially nifty
02:19.36yukonbobcool.
02:20.41yukonbobTcl is what brought me to brl-cad in the first place, and I haven't lost my love of Tcl... the joy of brl-cad is what kept me hacking to get it back working, but I'm exceptionally interested in Tcl/BRL-CAD, and C/BRL-CAD
02:21.37yukonbobholy fsck, I don't remember a single mged-specific command :P
02:30.02starseekerremember where the quick reference card is? :-P
02:30.03CIA-53BRL-CAD: 03starseeker * r42636 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Better - don't need if wrappers now, fix spacing
02:31.46yukonbobgrabbing mged tutorial, documentation...
02:32.30CIA-53BRL-CAD: 03starseeker * r42637 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Er - wrap the message so it doesn't blather every time
02:36.21yukonbobahhhhhh... nice.
02:43.11yukonbobthank $deity there's restraint and good sense wrt display and interface on brlcad...
02:43.40yukonbobmy screen happens to be slow, but the wireframe display and kb controls make everything still so easy to manage...
02:44.24yukonbobcomputers may be 100x faster than they were $x years ago, but there are always "resource constrained" systems, or just people (like me) who want to pretent they're one one...
02:52.36CIA-53BRL-CAD: 03starseeker * r42638 10/brlcad/branches/cmake/CMakeLists.txt: enable optimized flags for Release build, and warn if they are disabled - also set up 64 bit flag for MSVC, although this is untested and the CompilerFlags.cmake file doesn't yet incorporate MSVC flags (it should, TODO)
02:53.01starseekermuch better
03:08.08CIA-53BRL-CAD: 03starseeker * r42639 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake): Get most of the remaining summary report entries functioning, although need to check what compilation progress means in configure.ac. Also will need to re-sync warning/strict flag logic to match new autotools settings.
03:28.50CIA-53BRL-CAD: 03starseeker * r42640 10/brlcad/branches/cmake/CMakeLists.txt: Enable the CMake counterpart to the verbose output option. Also, finally turn off the static libraries when doing a debug build unless they're specifically requested (non MSVC builds)
03:34.04yukonbob? no more "tor" in mged?
03:45.41brlcadthere's still torii
03:46.24epileghello brlcad
03:46.28brlcadhowdy epileg
03:47.14yukonbobre-familiarizing self w/ mged... I think I'll have to work through tutorial briefly front-> back :}
03:47.47yukonbobbrlcad: I've *finally* got a running instance here again... happy days ;)
03:48.12brlcadgreat
03:48.20brlcadgoing to write some code then?
03:48.29yukonbobyes.
03:48.33brlcadfantastic
03:48.38yukonbobI've already got some patches for 8.6
03:48.50yukonbob...and some cross-platform tweaks for consideration.
03:49.23brlcadcan't wait to see them
03:49.57yukonboband some features that I've had since 7.x that are still applicable...
03:50.19brlcadthere's now also a slew of "contributor quickies" that are meant to be tiny projects only lasting a few days, to help someone get emmersed
03:50.22brlcadhttp://brlcad.org/wiki/Contributor_Quickies
03:51.09brlcadslowly expanding that list as topics come up
03:51.50yukonbobnods.
03:52.14yukonbobwell, looking forward to working w/ you again :) it's been a long time.
03:52.28brlcadyeah, it has been a while
03:53.20yukonbob2 or three years, off top of head :P
03:54.54yukonbobneeds to update hub for new decade ;P
03:57.08CIA-53BRL-CAD: 03brlcad * r42641 10/brlcad/trunk/src/librt/db_float.c: ws
03:58.59yukonbobwow... rt is fast
04:00.13yukonbob(though I crashed it on first try; I'll try to remember (and bother)) to keep logs/fixes of problems...
04:02.40CIA-53BRL-CAD: 03starseeker * r42642 10/brlcad/branches/cmake/src/other/togl/ (src/CMakeLists.txt tools/genStubs.tcl):
04:02.41CIA-53BRL-CAD: Fix togl build to only re-build on re-run of CMake, which is inevitable because
04:02.41CIA-53BRL-CAD: we're handling header template generation with CMake. This tweak, however,
04:02.41CIA-53BRL-CAD: results in proper termination instead of regenerating the header with every make
04:02.41CIA-53BRL-CAD: call.
04:02.53brlcadepileg: sure, usually :)
04:02.56CIA-53BRL-CAD: 03brlcad * r42643 10/brlcad/trunk/ (doc/deprecation.txt include/db.h): rt_fastf_float(), rt_mat_dbmat() and rt_dbmat_mat() are deprecated since they pertain to old v4 file i/o and are platform endian dependent.
04:04.33CIA-53BRL-CAD: 03brlcad * r42644 10/brlcad/trunk/doc/deprecation.txt: add the version number for the other 7.18 deprecations
04:06.27epilegto build debian packages with sh/make_deb.sh is not so dificult but there is a problem, if You are in a 64 bit platform, it will create just hte 64 bit and non-architecture dependents packages
04:07.53epilegis this a problem brlcad?
04:07.55brlcadepileg: well right now it doesn't really do anything, right? ;)
04:08.02epilegyes
04:08.11brlcadso it's an improvement ;)
04:08.15CIA-53BRL-CAD: 03starseeker * r42645 10/brlcad/branches/cmake/TODO.cmake: Archer now runs from the build dir.
04:09.53epilegok, then, and if You are agree, we can try to create the deb packages just in to the /usr/brlcad/ directory
04:10.54brlcadyeah, the make_deb.sh script should be like our other non-package-management system binary distributions, just building an --enable-all dependency-free build that can be posted up for users
04:11.19CIA-53BRL-CAD: 03starseeker * r42646 10/brlcad/branches/cmake/ (5 files in 5 dirs): Update cmake branch to trunk r42645
04:11.53brlcadideally, we'd post a 32-bit and 64-bit verison, but you've got a lot of room to decide how to manage things best since you're maintaining that platform
04:13.00brlcadepileg: if you've not yet read it, you should read "NAMING A BINARY RELEASE" and "MAKING A RELEASE" in the HACKING file
04:13.14epilegok
04:13.41brlcadjust to be familiar with the usual release steps we take for other builds
04:13.54epilegaha
04:14.36brlcadthe only part not documented there is that some platforms use a --prefix=/usr/brlcad/rel-7.18.0 and symbolic links are created in /usr/brlcad after install
04:14.47brlcadthat way multi-version installs work
04:15.44epilegso, to do that in debian like systems, We must put the version as a par of the name
04:16.00epilegpart*
04:16.23brlcadwhat do you mean?
04:16.50brlcadit's not the same convention as /usr/brlcad-7.18.0
04:16.54brlcadthat'd suck
04:16.56epilegordinary package: brlcad_7.18.0-1_i386.deb
04:17.03brlcadah, the file name, that's fine
04:17.14brlcadthat's actually what NAMING A BINARY RELEASE talks about
04:17.24brlcadthere's a specific format we try to make most of them match
04:17.34epilegnot just the file name but the project name
04:18.17brlcadare you referring to what apt does or .deb files in general?
04:18.30brlcadI know apt has it's own rules, but it didn't sound like you were trying to address apt
04:20.11epilegexactly, in debian You can only have installed one release of a project at the same time
04:23.03brlcadmm, okay
04:23.08brlcadthat's fine, the /usr/brlcad it is then
04:23.18brlcads/the /then /
04:25.42epilegone question, simbolic links are overwritten with the last installation?
04:27.49CIA-53BRL-CAD: 03starseeker * r42647 10/brlcad/trunk/ (4 files in 4 dirs): Put the archer.ico file where it belongs
04:28.27brlcadwith multiple version installs, yes usually .. so the last installed is always "default" yet you can get to any version
04:29.03epilegwell, this is not allowed by apt too :-/
04:29.04brlcadnote that the symlinks wouldn't necessarily have to be bundled files, they could be a post-install script
04:29.56epilegwell, no problem like this
04:31.05brlcadmore important to be reliably available and well integrated (like your other usability improvements)
04:31.40brlcadmulti-versions is for stand-alone binary installs -- if people really want that behavior, they should be able to download one of the other linux binaries
04:31.52brlcadso not a big deal
04:31.54epilegsure
04:33.38epilegabout the package name, can I keep the debian style on it? :-)
04:34.22brlcadfrom what you wrote, it already is almost a match
04:34.56brlcadonly difference would be to prefer the project long name instead of the short name, unless there was a technical limitation
04:35.50brlcadi.e., BRL-CAD_7.18.0-1_i386.deb
04:37.12yukonbobbrlcad: OK -- i'm being lazy -- what's cmd to select an obj from mged (using kb cmds to mged prompt)
04:37.15yukonbob?
04:37.52brlcadyukonbob: depends if it's a primitive or not, sed or oed
04:38.08yukonbobah -- those are familiar
04:38.13yukonbobbrlcad: thx ;)
04:38.15brlcadthose two have different syntax
04:38.21yukonbobit'll all come back.
04:38.44yukonbobis one of those guys who doesn't like to have to use mouse.
04:39.51CIA-53BRL-CAD: 03brlcad * r42648 10/brlcad/trunk/TODO: sed+oed, right hand begone
04:39.54brlcadthen you should implement the 'select' command, it's on our todo list :)
04:40.04brlcadhighly useful command for keyboard modelers
04:40.40yukonbobwill look into it.
04:41.03yukonbobafter he finds out how to get out of 'sed' mode...  (but not *immediately* after) ;)
04:41.14brlcad"reject"
04:41.18brlcad"accept"
04:42.20yukonboboh hey -- you mentioned call for papers other week... did I ask if was for something specific, or you're just collecting material?
04:43.23brlcaddoesn't recall mentioning a call for papers recently
04:44.23yukonbobyou asked if I'd write up something -- (but wasn't a specific request) -- must've been for general tutorial library or such...
04:48.27brlcadwell, there are the quickie documentation ideas
04:48.58brlcadand there is http://brlcad.org/wiki/Community_Publication_Portal
04:49.05brlcadwhich has more ideas pending publication
04:50.44yukonbobwill familiarize self w/ outstanding issues/requests over next few weeks...
04:50.46brlcad``Erik: on that same note, any possibility you'd write up a brief draft on the adrt/libtie integration work -- doesn't have to be fancy or finished, I can wordsmith it, but something that describes what you did, why, basic results .. the same stuff you were talking about yesterday would be perfect
04:50.50*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
04:51.32brlcadyukonbob: I wouldn't dwell too much on outstanding issues -- there are hundreds -- more useful to just pick one issue and try to fix it
04:52.21brlcadotherwise, you could be familiarizing for months and never actually get to anything useful
04:52.41yukonboboh indeed... I won't dwell --- I'm familar w/ the project (and my interests), so I'll marry the two -- I'm just rusty atm ;)
04:53.00brlcadpretty much *anything* in the TODO or BUGS file or Quickies page or publication page
04:54.17epilegbrlcad: what do You prefer, four packages or just one?
04:54.48brlcadepileg: which four?
04:55.06CIA-53BRL-CAD: 03starseeker * r42649 10/brlcad/branches/cmake/ (8 files in 7 dirs): Get cmake branch a bit closer to trunk
04:55.55epilegbrlcad-data, brlcad-bin, brlcad-dev and brlcad-doc
04:56.02CIA-53BRL-CAD: 03starseeker * r42650 10/brlcad/trunk/src/libbu/dirname.c: Pull in the change from cmake to make dirname a bit more cross platform
04:57.02CIA-53BRL-CAD: 03starseeker * r42651 10/brlcad/trunk/src/ (9 files in 6 dirs): Various cmake branch tweaks to bat files, tcl scripts - also remove some WIN32 hacks.
04:59.26brlcadyukonbob: here's a great one to start with
04:59.30brlcad"let the cp command take multiple arguments for simultaneously creating multiple named copies"
05:00.15brlcadcp command is src/libged/copy.c
05:00.19yukonbobie: cp existing1 new1 new2 new3 new4?
05:00.36brlcadexactly
05:03.39yukonboboh noes --- is there a reason "animate" cmd is spelled "animmate"?
05:05.02epilegbrlcad: brlcad-data, brlcad-bin, brlcad-dev and brlcad-doc
05:06.00epilegbrlcad: this is the actual deb packaging distribution made by Manuel
05:18.33*** join/#brlcad Stattrav (~Stattrav@122.172.40.92)
05:18.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:19.05CIA-53BRL-CAD: 03starseeker * r42652 10/brlcad/trunk/configure.ac: manuals/archer isn't there anymore
05:22.23CIA-53BRL-CAD: 03starseeker * r42653 10/brlcad/trunk/doc/html/manuals/Makefile.am: update manuals/Makefile.am too
05:30.33yukonbobis there a [red] for editing params of a primitive?
05:30.52yukonbob(i.e.: resetting a torus' radii, etc.)
05:33.32yukonbobsees ted...
05:44.01yukonbobok -- why are sed/ted not having the params "stick".
05:44.03yukonbob?
06:38.40*** join/#brlcad yukonbob (~bch@S0106001cf044d085.ok.shawcable.net)
06:38.59epilegbrlcad: I understand that You prefer only one package, isn't it?
08:48.30CIA-53BRL-CAD: 03ThedaHouser 07http://brlcad.org * r2452 10/wiki/Help:Navigation: /* Sidebar */
12:19.10CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r2453 10/wiki/Help:Navigation: Reverted edits by [[Special:Contributions/ThedaHouser|ThedaHouser]] ([[User talk:ThedaHouser|Talk]]); changed back to last version by [[User:Sean|Sean]]
12:19.29CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:ThedaHouser]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
12:21.29brlcadepileg: that only makes sense for managed integration, not for stand-alone .deb files
12:21.38brlcadthey can be combined into one...
12:45.54epilegthanks brlcad. I ask You all this things because I feel as a someone who's nearly to "destroy" the previous deb work. That's all.
12:46.28epilegbrlcad: but if You are agree, me too.
13:13.52*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
13:46.22CIA-53BRL-CAD: 03starseeker * r42654 10/brlcad/branches/cmake/src/ (CMakeLists.txt libpc/CMakeLists.txt): Add CMakeLists.txt file for libpc
13:52.01CIA-53BRL-CAD: 03starseeker * r42655 10/brlcad/branches/cmake/src/tclscripts/mged/CMakeLists.txt: Add botedit.tcl to the CMakeLists.txt file
13:53.03CIA-53BRL-CAD: 03starseeker * r42656 10/brlcad/branches/cmake/src/tclscripts/archer/CMakeLists.txt: Add DataUtils.tcl to CMakeLists.txt
14:00.03CIA-53BRL-CAD: 03starseeker * r42657 10/brlcad/branches/cmake/include/CMakeLists.txt: Add fft.h to header list.
14:29.03*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
14:33.10CIA-53BRL-CAD: 03starseeker * r42658 10/brlcad/branches/cmake/src/other/ (7 files in 7 dirs): add some headers and other files, LIBTERM->TERMLIB
14:38.53CIA-53BRL-CAD: 03starseeker * r42659 10/brlcad/branches/cmake/doc/docbook/lessons/ (en/CMakeLists.txt es/CMakeLists.txt): Fix a couple of docbook target paths
14:53.38CIA-53BRL-CAD: 03starseeker * r42660 10/brlcad/branches/cmake/sh/CMakeLists.txt: Add conversion.sh to the scripts list
14:58.03CIA-53BRL-CAD: 03starseeker * r42661 10/brlcad/branches/cmake/src/libpc/CMakeLists.txt: Copy/paste error
15:04.41CIA-53BRL-CAD: 03starseeker * r42662 10/brlcad/trunk/doc/ (4 files in 2 dirs): Not sure how far it got, but VolIV in docbook now has a 'correct' place to go, so put it there.
15:07.13CIA-53BRL-CAD: 03starseeker * r42663 10/brlcad/trunk/ (configure.ac doc/Makefile.am doc/book/): And remove the book directory
15:16.10CIA-53BRL-CAD: 03starseeker * r42664 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeIV.xml: Point to local docbook resources
15:19.35CIA-53BRL-CAD: 03starseeker * r42665 10/brlcad/branches/cmake/ (6 files in 4 dirs): Update cmake branch to trunk r42664
17:03.32*** join/#brlcad PrezKennedy (MK@whitecalf.net)
17:39.25CIA-53BRL-CAD: 03tbrowder2 * r42666 10/brlcad/trunk/src/mged/setup.c: ws
19:22.59*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
19:23.01yukonbob_oh hai
19:28.04yukonbob_q: re: sed/ted. when I'm presented w/ objects attibutes in ted-spawned editor, none of my changes seem to take effect. Is something basic I'm missing?
19:32.57starseekeryukonbob_: auugh
19:33.01starseekerthis is with trunk?
19:33.15starseekeryou're saving the text file before closing the editor?
19:36.26yukonbob_starseeker: heh. I know you have to ask these questions. Yes. and my computer is plugged in and turned on.
19:36.38yukonbob_starseeker: is 7.18.0
19:37.38yukonbob_fwiw, my remember my platform is still "unique" in the sense I'm running tcl 8.6b, and itl/itk 4, among other things.
19:37.49yukonbob_*itcl/itk
19:45.06yukonbob_starseeker: let me know if you can confirm bug...
19:47.59yukonbob_starseeker: ping?
20:46.56yukonbob_starseeker: ping
21:58.57*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
22:18.06yukonbob_starseeker: ping -- curious to know if you see same issues re: sed/ted.
22:22.27starseekeryukonbob_: sorry, passed out (lot of snow shoveling)
22:22.44yukonbob_heh
22:23.05yukonbob_starseeker: curious --- do you see same effect on what you'd consider to be a stable system?
22:23.18starseekerdon't mean to seem insulting - we've had problems with both ted and red in recent history, but thought we had them fix
22:23.21starseekered
22:23.22starseekertries...
22:23.24yukonbob_I did something like:
22:23.34yukonbob_make x tor ...
22:23.45yukonbob_then: sed x; ted
22:24.06yukonbob_[edit], [save], [exit]. No changes.
22:24.18yukonbob_subsequent "ted" indicate no changes, too.
22:24.46yukonbob_re: insulting -- no offence taken; likewise, I hope :)
22:24.53starseekerah - there was a post 7.18.0 fix to ted
22:25.09yukonbob_starseeker: can you point me to diff?
22:25.12starseeker'course not
22:25.15starseekeris looking
22:25.28yukonbob_wants his super-dumb primitives!!!1! :)
22:25.56starseekerr42276
22:28.50starseekerit seems to work in my 7.18.1 build (ted)
22:35.45CIA-53BRL-CAD: 03starseeker * r42667 10/brlcad/trunk/src/mged/tedit.c: Add nano to the list of editors we know about
22:36.18starseekeryukonbob_: any luck?
23:14.58CIA-53BRL-CAD: 03starseeker * r42668 10/brlcad/branches/cmake/ (3 files in 3 dirs): fill in some of the variables pkgconfig files expect - once CMake is the main build system, need to revisit the issue of pkgconfig
23:19.10yukonbob_starseeker: I'll have to try later.
23:19.32*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
23:20.00yukonbob_but r42276 has my changes ( or collection of changes ), correct?
23:23.45starseekerthose are the changes that made ted work forme
23:31.45yukonbob_ok; did you observe the broken behaviour I described above in prev. (7.18.0) code?
23:33.31CIA-53BRL-CAD: 03starseeker * r42669 10/brlcad/branches/cmake/src/brlman/CMakeLists.txt: Get cute with brlman - write one version out for the build bin dir that will work locally, and put the one to be installed in src/brlman/brlman
23:35.53yukonbob_starseeker: ----^
23:42.32starseekeryukonbob_: yes - we got a bug report of ted not applying changes
23:42.50starseekerthe red thing was a bit further back - let me see if red is working...
23:44.34starseekerseems to accept a change here in a quick test
23:46.01yukonbob_starseeker: re: bug -- ok -- that's good. I'm considering my whole system "suspect" because it's 1) quite non-standard 2) using beta software at it's core, so to corelate events/behaviour w/ other systems is important for me...
23:46.14yukonbob_s/re: bug/re: bug report/
23:55.53CIA-53BRL-CAD: 03starseeker * r42670 10/brlcad/trunk/src/other/jove/ (Makefile.am jove_main.c mkversion.sh): That's an aweful lot of logic just to set a version number, which isn't particularly important for our uses anyway - set it to 2.1 in jove_main.c (the only place that appears to use it) and call it done.
23:56.29starseekeryukonbob_: to be fair, it's quite possible our new editor logic isn't happy on that particular OS
23:58.05yukonbob_can't imagine that would be too difficult... it's basically an exec to a tmpfile, no?
23:58.41starseekeryes, but it's surprisingly annoying
23:58.48yukonbob_ie: exec "$env(editor) $tmpfile"; # blocking call to editor
23:58.53yukonbob_read $tmpfile.
23:59.38starseekertake a look at tedit.c in mged and src/libged/editit.c
IRC log for #brlcad on 20110128

IRC log for #brlcad on 20110128

00:00.46CIA-53BRL-CAD: 03starseeker * r42671 10/brlcad/branches/cmake/ (6 files in 3 dirs): Update cmake to trunk r42670
00:28.22CIA-53BRL-CAD: 03starseeker * r42672 10/brlcad/branches/cmake/ (3 files in 3 dirs): sigh. jove is explicitly referenced as the editor of last resort in other code, so go ahead and build it. wonder if this actually works on Windows...
00:40.23CIA-53BRL-CAD: 03starseeker * r42673 10/brlcad/trunk/src/other/libz/zconf.h.cmakein: add the fix from 41902 to zconf.h.cmakein too
00:48.45yukonbob_starseeker: re: jove -- in case of ted, it says it'll run "ed"  by default.
00:48.59yukonbob_<PROTECTED>
00:49.21starseekernods
00:52.57CIA-53BRL-CAD: 03starseeker * r42674 10/brlcad/trunk/src/other/step/src/ (7 files in 3 dirs): Hmm - warning flags got passed to step, which isn't happy - maybe could ignore, but since we're maintaining the code anyway might as well...
01:00.19CIA-53BRL-CAD: 03starseeker * r42675 10/brlcad/branches/cmake/ (11 files in 6 dirs):
01:00.19CIA-53BRL-CAD: OK, this should bring the compiler flags logic pretty darn close to the latest
01:00.19CIA-53BRL-CAD: autotools, with this possible exception of not isolating the src/other dir quite
01:00.19CIA-53BRL-CAD: well enough - on the other hand, may be OK since it built successfully on gentoo
01:00.19CIA-53BRL-CAD: with these settings.
01:22.56CIA-53BRL-CAD: 03starseeker * r42676 10/brlcad/trunk/src/mged/dm-rtgl.c: interp->INTERP in rtgl
01:23.35CIA-53BRL-CAD: 03starseeker * r42677 10/brlcad/branches/cmake/ (CMakeLists.txt src/mged/CMakeLists.txt src/mged/dm-rtgl.c): Allow the enabling of RTGL, although things look to be a tad broken at the moment - need to check trunk.
01:49.11CIA-53BRL-CAD: 03starseeker * r42678 10/brlcad/trunk/src/libdm/dm-rtgl.c: (log message trimmed)
01:49.11CIA-53BRL-CAD: This gets past the initial bu_malloc error, but we've got some kind of weirdness
01:49.11CIA-53BRL-CAD: going on here. The RT_CK_SEGS test in recordHit fails with what looks like a
01:49.11CIA-53BRL-CAD: bad magic error - printing out the seg list in debug shows a lot of strange
01:49.11CIA-53BRL-CAD: looking numbers, and commenting out the check shows a lot of one hit reports and
01:49.12CIA-53BRL-CAD: a visible rtgl raytrace (e.g. aside from the errors it largely succeeds.) rtgl
01:49.13CIA-53BRL-CAD: code hasn't changed in quite a while, so something must have changed out from
01:50.47CIA-53BRL-CAD: 03starseeker * r42679 10/brlcad/branches/cmake/src/libdm/dm-rtgl.c: Might as well sync this from trunk...
01:52.55CIA-53BRL-CAD: 03starseeker * r42680 10/brlcad/branches/cmake/TODO.cmake: Getting down there - add note on opensolaris
01:59.08CIA-53BRL-CAD: 03starseeker * r42681 10/brlcad/branches/cmake/TODO.cmake: add note about library versions in src/other builds
02:02.13CIA-53BRL-CAD: 03starseeker * r42682 10/brlcad/branches/cmake/TODO.cmake: note wish exe on Windows needs work
02:07.20brlcadstarseeker: you threw in a new logic scope, but didn't fix the indentation in dm-rtgl.c
02:07.31starseekeroh, sorry
02:07.33starseekerfixes
02:07.43brlcadand if( isn't the right style
02:08.24brlcadotherwise, that looks like a good fix for a category of alloc failures
02:12.34CIA-53BRL-CAD: 03starseeker * r42683 10/brlcad/trunk/src/libdm/dm-rtgl.c: ws, indent
02:13.13brlcadwow, that hit a lot more than expected
02:14.31brlcader, yeah.. that's not right
02:15.15brlcadstarseeker: how'd you auto-indent that?
02:15.24starseekerindent.sh and ws.sh
02:15.35brlcadhuh, it looks like it's using 2-char indent
02:16.19brlcadodd, indent.sh here reverts your changes
02:16.29starseekerblinks
02:16.33brlcadyou might have something in your .emacs
02:16.40starseekeror .vimrc
02:16.52starseekergo ahead and commit - I won't argue
02:17.10starseekeris more concerned about what's happening with the rtgl raytrace
02:18.11brlcadtry running indent.sh on vers.c
02:18.16brlcaddoes it modify the file?
02:18.52starseekeryes - just the return brlcad_ident line
02:19.10starseekerwhich is the only one there, of course...
02:19.18brlcadsvn revert vers.c,  move your .emacs out of the way, and retry
02:19.40brlcadit shouldn't modify
02:20.12starseekerstill did
02:20.29brlcadwhat platform are you on?
02:20.34starseekergentoo
02:20.47brlcademacs --version
02:20.54CIA-53BRL-CAD: 03brlcad * r42684 10/brlcad/trunk/src/libdm/dm-rtgl.c: revert and fix formatting.
02:20.55starseekerGNU Emacs 23.2.1
02:22.34brlcadhm, okay -- so the indent.sh is unusable by you for some reason -- is there any clue in the output when you run it?  some warning or error?
02:26.10starseekerno - just "Loading vc-svn..."
02:26.20starseekerIndenting region...
02:26.23starseekerIndenting region... done
02:26.30brlcadhm, darn
02:26.31starseekersaving and wrote lines
02:26.35brlcadsuspect something in misc/batch-indent-region.el is getting interpreted differently causing the variable block to be ignored
02:26.51brlcadwell, so it's just unusable for you until debugged
02:26.57starseekernods
02:27.16brlcadyou'll have to stick with manually indenting or vim (the vi-line mode should be respected if you turn it on)
02:27.42starseekerthat's the mode name?  vi-line?
02:27.47brlcadonly an issue because that last edit is a prime example that can lead to a logic bug later
02:28.19brlcadno, it's not
02:31.24starseekerhmm - my default vim setup doesn't work gg=G indents everything wrong
02:36.43brlcad:help 'modeline'
02:36.59brlcadturning that on should make it respect the modeline at the bottom of every file
02:37.32brlcadotherwise, you can set the style in your .vimrc with rules similar to this:  http://drupal.org/node/29325
02:37.52brlcadexcept it's shiftwidth=4 tabstop=8
02:48.42starseekerthe modeline gets close
03:13.49brlcadthere's probably more variables that could/should be set for vim users
03:14.02brlcadbut the two there are the critical ones for consistent indentation
03:14.10starseekernods
03:14.18brlcadthe stylistic ones were left as an exercise to the reader :)
03:14.26starseekerheh
03:14.33brlcadcontinues working on rt_db_corrupt()
03:16.19CIA-53BRL-CAD: 03starseeker * r42685 10/brlcad/branches/cmake/ (3 files in 3 dirs): Pick up sunmath if it's there for tcl/tk
03:20.35starseekeryow
03:20.44starseekeropennurbs and sun studio don't get along at all
03:22.03starseekerhah - actually, that's the same issue clang saw
03:22.04starseekercool
03:45.39*** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net)
03:45.42yukonboboh hai.
03:46.38yukonbobq: re problems w/ sed/ted in 7.18.0 (apparently fixed in 7.18.1) -- does anybody remember roughly (or better, acutely and accurately) what the fix was?
04:03.05starseekerneeded to test for TCL_OK, as opposed to just using the return val for the if statement (IIRC)
04:03.26starseekerreturn val of editit in tedit.c I believe, but not sure
04:04.10starseekeryukonbob: recommend setting up gdb, breaking just before the edit is to be applied to disk (as a start) and tracing back where the failure is
04:04.20starseekergrrrr
04:04.52starseekersun stuido gives this error:  "The function "_finite" must have a prototype"
04:05.00starseekerwhat on earth...
04:05.04yukonbobstarseeker: thanks for the clues... I was going to try to get away w/ least-invasive patch possible.
04:14.55CIA-53BRL-CAD: 03starseeker * r42686 10/brlcad/branches/cmake/src/libdm/dm-rtgl.c: grab dm-rtgl ws/indent fixes
04:37.40CIA-53BRL-CAD: 03starseeker * r42687 10/brlcad/branches/cmake/src/other/openNURBS/ (4 files): These are minimal 'get opennurbs compiling on sun studio' hacks - commiting them because I accidently erased one last go-around, but need cleanup and conditional wrappers
04:53.11brlcadstarseeker: sun studio is notorious for having drastically different compilation behavior when you change standard compliance levels
04:54.00brlcadthe default does not match gcc behavior but there is a mode that does match pretty closely iirc
05:06.11yukonbobsees some interesting header changes in bwish -- stripping itk.h and replacing w/ tk.h alone?
05:07.46yukonbobcrosses fingers, configs 7.18.1
05:08.15*** join/#brlcad Stattrav (~Stattrav@122.172.46.55)
05:08.16*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:08.43yukonbobfeh -- immediate 'make' failure :P
05:09.16yukonbobmissing rtprivate.h
05:26.41*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
05:36.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:00.19*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
06:00.19*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
06:00.52*** join/#brlcad yukonbob (~bch@S0106001cf044d085.ok.shawcable.net)
06:49.23yukonbobstarseeker: that TCL_OK on editit() was the problem/fix. Thx.
07:15.24yukonbobis there such a process as a lathe yet, like povray?
07:17.17brlcadyukonbob: yes, though much more general (and much less tested) :)
07:17.24brlcad'revolve' primitive
07:17.32yukonbobbrlcad: hello :)
07:17.37brlcadtakes a 2D 'sketch' object, and an axis of rotation
07:17.47yukonbobhow old is revolve?
07:17.54brlcadfew years
07:17.55yukonbob<2years
07:17.57yukonbob?
07:18.08yukonbobcool
07:18.32yukonbobbrlcad: how're things?
07:18.33brlcadr31599 | pacman87 | 2008-06-24 13:34:05 -0400 (Tue, 24 Jun 2008) | 1 line
07:18.33brlcadbeginning of revolve primitive, with shot() algorithm for straigh line sketches (untested)
07:19.17yukonbobthat makes sense -- probabably ~the time I became less involved...
07:19.29brlcadhttp://brlcad.org/wiki/Revolve_Primitive
07:19.43yukonbobpovray "lathe" operation is quite nice -- looking forward to playing w/ revolve...
07:20.52brlcadhttp://brlcad.org/tmp/revolve/ has a sample
07:21.01yukonbobbrlcad: you see the ted bug that shipped w/ 7.18.0 :P
07:21.11brlcadyep
07:21.16brlcadwhat about it?
07:21.42yukonbobted doesn't work :P
07:21.45brlcadted isn't best practice
07:21.54brlcadmore of a crutch
07:22.03yukonbobthe return code is incorrectly checked, and the edits are effectively thrown away.
07:22.30brlcadI'm aware of what the bug is and how it was fixed -- I helped diagnose and fix when it was reported
07:22.32yukonbobwhat do the cool kids use instead of ted?
07:23.09brlcadit depends on the type of edit, there are different commands for different operations
07:23.22brlcadmost of the common ones are listed on the quick ref card
07:23.49yukonbobwill have to get to a printer and print all these again... I used to carry them with me ;)
07:23.56brlcade.g., sca, rot, tra
07:24.45yukonbobscale, rotate, translate, sure... will those let one redefine the second radius of a torus, though?
07:24.55brlcadthe only tricky edits are the refined parameter edits displaed on the Edit menu when you go into edit mode, but even those are selectable on the command line using the "press" command
07:25.10yukonbobah
07:26.24yukonbobwhy is ted considered !Best Practice ?
07:26.52brlcadpress "Set Radius 2"
07:26.58brlcadfor that specific action
07:27.04brlcadp 10
07:27.24brlcadted basically punts on providing a user interface, kicking off a dump to a text file
07:27.54yukonbobso is just non-elegant, in at least one way...
07:28.01brlcadthat's fine for some things, like diagnostics, but a really crappy and supremely error-prone way to go about things
07:28.30brlcadthe errors it causes tend to far outweigh the warm fuzzy feeling some people get working in their favorite text editor
07:28.46brlcadit's a crutch
07:29.03yukonbobnods
07:29.39yukonbobanyway, is broken crutch in latest .tgz; I've got it working here, now, but will train self to use alternatives.
07:34.15brlcadwow, my corruption detection routine is actually working... woot!
07:59.48*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
08:51.07CIA-53BRL-CAD: 03brlcad * r42688 10/brlcad/trunk/src/librt/ (Makefile.am db_corrupt.c):
08:51.07CIA-53BRL-CAD: add an initial working implementation of a routine to help detect when a v4
08:51.07CIA-53BRL-CAD: geometry file seems corrupt due to endianness. this walks over all matrices of
08:51.07CIA-53BRL-CAD: combinatino members and tests whether they preserve axis perpendicularity and
08:51.07CIA-53BRL-CAD: that scaling/rotation elements are unitized. if a matrix fails, it flips it and
08:51.08CIA-53BRL-CAD: tries again to see if flipping fixes the problem. if ALL failures were
08:51.09CIA-53BRL-CAD: successfully fixed by flipping, then true is returned.
09:00.12CIA-53BRL-CAD: 03brlcad * r42689 10/brlcad/trunk/include/raytrace.h: provide declaration and documentation for rt_db_flip_endian(), to be used for detecting binary-incompatible v4 geometry database files.
10:38.42*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:18.19epilegbrlcad: hello. I've made the needed changes in /misc/debian folder and in sh/make_deb.sh file, to make it working. Now I've to commit
13:31.05CIA-53BRL-CAD: 03starseeker * r42690 10/brlcad/branches/cmake/src/other/openNURBS/ (4 files): Wrap sun studio stuff in conditionals
13:41.47CIA-53BRL-CAD: 03starseeker * r42691 10/brlcad/branches/cmake/src/other/openNURBS/ (CMakeLists.txt opennurbs_system.h): Whoops - opennurbs build isn't using the CONFIG_H_FILE at the moment, so add definitions explicitly. Perhaps this is why ieeefp.h wasn't getting picked up, so comment out the define - if this works remove it.
13:44.50CIA-53BRL-CAD: 03starseeker * r42692 10/brlcad/branches/cmake/src/other/openNURBS/opennurbs_system.h: Nope, HAVE_IEEEFP_H wasn't enough
14:52.45brlcadepileg: okay, go for it :)
14:53.13brlcadyou didn't have to wait until you were done, you could/can commit incrementally
14:54.00epilegbrlcad: Do have I commit acces to trunk/sh/ folder?
15:34.43*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:39.47CIA-53BRL-CAD: 03brlcad * r42693 10/brlcad/trunk/src/libbu/mappedfile.c: checking the wrong debug flag
15:51.07CIA-53BRL-CAD: 03brlcad * r42694 10/brlcad/trunk/include/bu.h: BU_DEBUG_DB is no longer used, mark as such to free up the slot.
15:52.22CIA-53BRL-CAD: 03brlcad * r42695 10/brlcad/trunk/include/raytrace.h: mark the private db_i members as such more explicitly, ws consistency migration to keep names associated with their type for db_i and directory structs.
15:57.15CIA-53BRL-CAD: 03starseeker * r42696 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Don't mess with jove on Windows
15:59.02CIA-53BRL-CAD: 03starseeker * r42697 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Say something about it instead of turning off silently
16:06.35*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
16:06.59brlcadepileg: the only way to know that for sure is to try, right?
16:07.12epilegright :-)
16:07.40epilegabout the commit comment. some rule to follow?
16:08.09brlcadsure, make it something useful to the other developers and to yourself 5 years from now
16:09.01brlcadbriefly describing what *and* why/impact/reasoning
16:22.02CIA-53BRL-CAD: 03starseeker * r42698 10/brlcad/branches/cmake/src/bwish/CMakeLists.txt: tweak bwish build logic
16:24.13CIA-53BRL-CAD: 03brlcad * r42699 10/brlcad/trunk/src/librt/namegen.c: lots of dead code, mostly dead code
16:26.43CIA-53BRL-CAD: 03brlcad * r42700 10/brlcad/trunk/src/librt/db5_scan.c:
16:26.43CIA-53BRL-CAD: change db_dirbuild() to no longer directly check the file header and calculate
16:26.43CIA-53BRL-CAD: the version. let db_version() be the (only) place that happens. should reduce
16:26.43CIA-53BRL-CAD: a few petty file i/o operations but more importantly avoid overriding
16:26.44CIA-53BRL-CAD: dbi_version since it needs to be negative for flipped v4 files.
16:28.19CIA-53BRL-CAD: 03brlcad * r42701 10/brlcad/trunk/ (3 files in 2 dirs): enable db_corrupt for librt compilation
16:31.31CIA-53BRL-CAD: 03brlcad * r42702 10/brlcad/trunk/src/librt/db5_scan.c: right, 'header' is no longer used.
16:37.11CIA-53BRL-CAD: 03starseeker * r42703 10/brlcad/branches/cmake/ (10 files in 10 dirs): Add version number logic for some of the src/other libs
16:47.31CIA-53BRL-CAD: 03brlcad * r42704 10/brlcad/trunk/src/fbserv/fbserv.c: return from main instead of exiting
16:49.20CIA-53BRL-CAD: 03brlcad * r42705 10/brlcad/trunk/src/other/tnt/tnt_fortran_array3d.h: quell warning about having no space on the empty for loop before the semicolon.
17:09.51*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
18:21.39CIA-53BRL-CAD: 03starseeker * r42706 10/brlcad/branches/cmake/src/other/ (tcl/CMakeLists.txt tk/CMakeLists.txt): Hmm endian test isn't happy with VC2010
18:27.59CIA-53BRL-CAD: 03starseeker * r42707 10/brlcad/branches/cmake/src/other/incrTcl/ (itcl/CMakeLists.txt itk/CMakeLists.txt): itcl/itk too
18:28.30CIA-53BRL-CAD: 03erikgreenwald * r42708 10/brlcad/branches/cmake/src/libpc/CMakeLists.txt: add TCL_INCLUDE_DIRS to make bu.h happy
18:36.05CIA-53BRL-CAD: 03starseeker * r42709 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Hmm - was this the issue with the endian test?
18:47.04starseekerhmm.  nope
18:47.10starseekerdoes fix another problem though
18:48.09starseekersees other indications that TestBigEndian may be quirky with VC2010... well, not likely to be needed anyhow with MSVC
19:18.20CIA-53BRL-CAD: 03starseeker * r42710 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: More flag tweaking...
19:55.49CIA-53BRL-CAD: 03starseeker * r42711 10/brlcad/branches/cmake/misc/CMake/test_srcs/report_username.c.in: Tweak WIN32 conditional define to _WIN32
20:06.53CIA-53BRL-CAD: 03bob1961 * r42712 10/brlcad/trunk/ (include/tclcad.h src/libtclcad/ged_obj.c): Added a callback for when the view changes to libtclcad.
20:13.13CIA-53BRL-CAD: 03starseeker * r42713 10/brlcad/branches/cmake/src/other/step/ (11 files in 6 dirs): Simplify the SCL CMake logic, grab some of the updates from newer BRL-CAD logic
20:14.43CIA-53BRL-CAD: 03bob1961 * r42714 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Added methods to expose libtclcad's view_callback function.
20:18.38CIA-53BRL-CAD: 03starseeker * r42715 10/brlcad/branches/cmake/include/config_win_cmake.h: This is defined in newer MSVC compilers - conditionalize to quell warnings
20:29.05CIA-53BRL-CAD: 03starseeker * r42716 10/brlcad/trunk/src/libbu/backtrace.c: Let's not do the assignment in the if statement - quell MSVC warning
20:29.38CIA-53BRL-CAD: 03starseeker * r42717 10/brlcad/trunk/src/libbu/backtrace.c: typo
20:32.20CIA-53BRL-CAD: 03brlcad * r42718 10/brlcad/trunk/src/tclscripts/mged/text.tcl: can't just directly call 'bind' since procedures might be called without ::tk:: namespace loaded. catch any error.
20:34.11CIA-53BRL-CAD: 03brlcad * r42719 10/brlcad/trunk/src/tclscripts/mged/dbupgrade.tcl: make dbupgrade work once again in classic console mode where there is no ::tk
20:36.10CIA-53BRL-CAD: 03starseeker * r42720 10/brlcad/branches/cmake/src/other/CMakeLists.txt: try adding xlib to TCL_INCLUDE_DIRS (untested)
20:38.19CIA-53BRL-CAD: 03starseeker * r42721 10/brlcad/branches/cmake/src/other/CMakeLists.txt: typo
20:44.52CIA-53BRL-CAD: 03bob1961 * r42722 10/brlcad/trunk/src/tclscripts/archer/CombEditFrame.tcl: Fixed CombEditFrame::updateGeometry. It's now able to turn off inherit.
20:52.06CIA-53BRL-CAD: 03brlcad * r42723 10/brlcad/trunk/src/conv/asc/g2asc.c: check ==0 instead of ==DB5_MINORTYPE_RESERVED since the value may change. zero suffices for unset.
20:53.03CIA-53BRL-CAD: 03brlcad * r42724 10/brlcad/trunk/src/conv/dbupgrade.c:
20:53.04CIA-53BRL-CAD: dbupgrade with a coredump flag makes the automatic endianness flip test fail
20:53.04CIA-53BRL-CAD: since low-level libbn routines will bomb if they encounter a bad matrix.
20:53.04CIA-53BRL-CAD: instead of bombing, let them return their error so we upgrade cleanly.
20:53.43CIA-53BRL-CAD: 03brlcad * r42725 10/brlcad/trunk/src/tclscripts/mged/help.tcl: improve help, dbupgrade will begin processing if it's followed by 'upgrade'
21:00.48CIA-53BRL-CAD: 03brlcad * r42726 10/brlcad/trunk/src/tclscripts/mged/help.tcl: list all three upgrade commands
21:01.38CIA-53BRL-CAD: 03brlcad * r42727 10/brlcad/trunk/src/tclscripts/mged/dbupgrade.tcl: display the entire detailed help if the user requests help. 'help dbupgrade' will still just report a brief usage message.
21:03.17CIA-53BRL-CAD: 03jordisayol * r42728 10/brlcad/trunk/ (31 files in 2 dirs): Upgraded the debian package build proccess. Added mged, archer, rtwizard, documentation and examples menus. Added brlcad mime type. Added brlcad mime file association.
21:09.13CIA-53BRL-CAD: 03starseeker * r42729 10/brlcad/branches/cmake/src/ (CMakeLists.txt irprep/subroutines.c other/CMakeLists.txt): more Windows stuff...
21:10.44CIA-53BRL-CAD: 03brlcad * r42730 10/brlcad/trunk/src/tclscripts/mged/dbupgrade.tcl: support all variations of 'yes' and inform the user that upgrade was cancelled and database is being reopened. this way, if it's a corrupt database, the warning makes sense.
21:10.56brlcadepileg: congratulations :)
21:11.06epilegthanks brlcad
21:11.29epilegbut it do not compile on trunk
21:11.46epilegin 7.18.0 compile without problem
21:12.30brlcadyou have to be way more specific for that to mean anything
21:13.06epilegok, just a moment
21:13.12brlcadthere are dozens or even hundreds of commits nearly every day, and they won't all work -- that's the nature of working on trunk
21:14.08brlcadfirst step is to always check and see if there's an update, read the recent commits from in here to see if the commit message says anything about breaking things
21:15.02brlcadthen just read the failure to see what happened, because 90% of the time, it's a very simple syntax mistake that can be easily fixed by anyone
21:15.38brlcadthen, if you can't make sense of the error, you can paste your build log somewhere and ask for help in here :)
21:17.20brlcadepileg: you also need to update misc/Makefile.am to list all of the file changes you made
21:17.30brlcadadditions and deletions
21:17.34brlcadit's a simple list
21:17.53epilegok, I'll do right now
21:21.33CIA-53BRL-CAD: 03brlcad * r42731 10/brlcad/trunk/src/librt/db_open.c:
21:21.33CIA-53BRL-CAD: enable automatic flipping of a binary-incompatible v4 geometry database if
21:21.33CIA-53BRL-CAD: rt_db_flip_endian() returns true. this should only occur if flipping the
21:21.33CIA-53BRL-CAD: database was observed to fix ALL matrix member failures during a quick db_open()
21:21.33CIA-53BRL-CAD: scan of the file. the user should be able to force flipped values in mged with
21:21.34CIA-53BRL-CAD: 'opendb -f'.
21:26.33brlcadepileg: you can check a build's suitability for distribution, particularly whether you missed any files, with "make distcheck"
21:28.16epilegok
21:28.55epilegnow i'm modifying misc/Makefile.am
21:29.35brlcadcool
21:31.14brlcadepileg: can you describe what all the changes were -- new menus, mime type file association, desktop icons, ... anything else?
21:33.33epilegbrlcad: where i've to describe this?
21:34.04brlcadheh, here -- just asking for general info
21:34.11epilegah
21:34.32CIA-53BRL-CAD: 03starseeker * r42732 10/brlcad/branches/cmake/misc/CMakeLists.txt: whoopsie - to run in the build dir, need archer.ico in the build dir...
21:36.10epilegconfigure was changed from shared to build-in libraries
21:37.20epilegchanged --prefix from /usr/ to /usr/brlcad/
21:39.06CIA-53BRL-CAD: 03starseeker * r42733 10/brlcad/branches/cmake/TODO.cmake: Update TODO.cmake
21:39.06brlcadanything else?
21:43.56CIA-53BRL-CAD: 03brlcad * r42734 10/brlcad/trunk/AUTHORS: add epileg's aliases
21:47.28*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
21:47.28*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
21:50.24CIA-53BRL-CAD: 03brlcad * r42735 10/brlcad/trunk/NEWS:
21:50.24CIA-53BRL-CAD: extensive work for the debian platform by jordi sayol (epileg). there are new
21:50.24CIA-53BRL-CAD: application menus, icons, mime-type associations, and other usability essentials
21:50.24CIA-53BRL-CAD: for a self-contained .deb installer. this should make it easier for a platform
21:50.24CIA-53BRL-CAD: maintainer to publish .deb files on a more regular basis.
21:58.18CIA-53BRL-CAD: 03brlcad * r42736 10/brlcad/trunk/NEWS:
21:58.18CIA-53BRL-CAD: you can now run 'ls -la' on a v4 database and have it properly report primitive
21:58.18CIA-53BRL-CAD: types. it was reporting NULL and even potential crash-inducing garbage due to
21:58.18CIA-53BRL-CAD: directly indexing into the rt_functab based on an unset d_minor_type.
21:59.09CIA-53BRL-CAD: 03erikgreenwald * r42737 10/brlcad/branches/bottie/src/librt/primitives/bot/ (bot.c btg.c btg.h btgf.c tie.c tie_kdtree.c): warning quellage
22:20.08*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
22:22.16CIA-53BRL-CAD: 03jordisayol * r42738 10/brlcad/trunk/misc/Makefile.am: Updated debian/ files list
22:22.53*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
22:25.29CIA-53BRL-CAD: 03brlcad * r42739 10/brlcad/trunk/NEWS:
22:25.29CIA-53BRL-CAD: mged's opendb command now has a -f flip option for reading in a
22:25.29CIA-53BRL-CAD: binary-incompatible v4 geometry database with a flipped endianness translation.
22:25.29CIA-53BRL-CAD: the files are made read-only but may then be run through keep or dbupgrade to
22:25.29CIA-53BRL-CAD: clean them up. this closes out a long-standing request from users and a class
22:25.30CIA-53BRL-CAD: of modeling/rendering failures due to the platform-specific nature of v4 files,
22:25.31CIA-53BRL-CAD: albeit only minimally tested with a few sample files.
22:27.45*** join/#brlcad ibot (~ibot@rikers.org)
22:27.45*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || Happy Open Source Anniversary 2010-12-21 !!! Six years...
22:29.07CIA-53BRL-CAD: 03starseeker * r42740 10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: Doesn't look like winMain.c belongs in libtk, but that's not the only issue.
22:29.23CIA-53BRL-CAD: 03brlcad * r42741 10/brlcad/trunk/NEWS: (log message trimmed)
22:29.23CIA-53BRL-CAD: dbupgrade (along with ALL other BRL-CAD commands) now supports reading in
22:29.23CIA-53BRL-CAD: binary-incompatible v4 files. the low-level librt db_open() inteface for
22:29.23CIA-53BRL-CAD: reading in files will now auto-convert a v4 file to an alternate endian format
22:29.24CIA-53BRL-CAD: if it finds that flipping all combination member matrices makes them valid. for
22:29.24CIA-53BRL-CAD: safety, that means if an old v4 has even one actual bad matrix (so that it's
22:29.25CIA-53BRL-CAD: invalid regardless of being flipped), then the dbupgrade cannot be performed
22:46.23CIA-53BRL-CAD: 03brlcad * r42742 10/brlcad/trunk/misc/Makefile.am: M-x sort-lines
22:46.53epilegops, sorry
22:47.01brlcadno problem
22:51.04CIA-53BRL-CAD: 03brlcad * r42743 10/brlcad/trunk/TODO: dbupgrade support is done
22:53.39CIA-53BRL-CAD: 03brlcad * r42744 10/brlcad/trunk/src/tclscripts/mged/help.tcl: document the new -f option to opendb
23:02.47CIA-53BRL-CAD: 03brlcad * r42745 10/brlcad/trunk/doc/docbook/system/mann/en/opendb.xml: document the opendb -f option
23:11.05CIA-53BRL-CAD: 03r_weiss * r42746 10/brlcad/trunk/src/libbn/bntester.c: Added to 'bntester' support for testing function 'bn_isect_line3_line3'.
23:15.18CIA-53BRL-CAD: 03brlcad * r42747 10/brlcad/trunk/include/ged.h:
23:15.18CIA-53BRL-CAD: refactor principle of DRY -- Don't Repeat Yourself. user usage statements don't
23:15.18CIA-53BRL-CAD: belong in the public header regardless, but they're also already listed in the
23:15.18CIA-53BRL-CAD: manual pages and src/tclscripts/mged/help.tcl and the bastard replications for
23:15.18CIA-53BRL-CAD: archer and rtwizard (Db.tcl and Ged.tcl). approx 700 line reduction.
23:15.18CIA-53BRL-CAD: ultimately, usage should be defined in the source C file directly in src/libged
23:17.33brlcadhm, distcheck does not like the misc/debian/brlcad-db.png symbolic link
23:18.48epilegis this a problem?
23:19.05epilegwell, I can make a copy of the png
23:22.40``Eriksome os's don't support symlinks, can it cp when running the makedeb script shtuff?
23:26.07brlcadepileg: yeah, a copy would be better
23:26.35CIA-53BRL-CAD: 03jordisayol * r42748 10/brlcad/trunk/misc/debian/ (brlcad-db.png brlcad-db.png):
23:27.02brlcadshould always have *some* comment message, at least say why :)
23:27.30epilegok. sorry
23:28.33brlcadcould have been "copy instead of symlink" or "distcheck hates symlinks or even "sean complained so make a copy" .. all fine :)
23:29.13brlcadi.e., what would be useful to someone looking at that change years from now when the reason is no longer obvious
23:30.06*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || http://itmanagement.earthweb.com/osrc/article.php/3922041/50-Open-Source-Applications-for-Sci-Tech-Education.htm
23:54.54RalithI'll be needing to do inward polygon+arc offsetting in the gcode generator; a bit of research has pointed me towards M. Held. "On the Computational Geometry of Pocket Machining", LNCS500, Springer-Verlag, 1991, which "uses a Voronoi Diagram (VD) to produce rounded or constant-radius offset curves."  I can get a copy of this at my univ library.  Sound like I'm on the right track?
23:55.13Ralith... which describes how to use "..., rather
IRC log for #brlcad on 20110129

IRC log for #brlcad on 20110129

00:05.35epilegbrlcad: here is the problem:
00:05.36epilegbacktrace.c:313: error: ‘else’ without a previous ‘if’
01:05.57brlcadhm, I have no else on backtrace.c:313
01:12.02starseekerbrlcad: oh, that's me
01:39.58starseekerwhat the bleep... sf password issue
01:45.21starseekerI can't fix it - my password is being rejected
01:51.35starseekerbrlcad: can you commit?
01:52.02starseekertried to reset my password - can reach the website but the commits still fail
02:03.22starseekerwell, here's the diff anyway... http://paste.lisp.org/display/119160
04:03.38*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
04:03.44starseeker``Erik: around?
05:50.22*** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net)
05:50.24yukonboboh hai
05:51.33yukonbobI've got a 101 question: I want a "tool" that I use later in CSG operations. How do I create this tool itself? I can create it, but when I try to clone/tra it, I'm told it's not a solid.
05:52.07yukonbobI tried combinations and regions, no dice.
06:02.15brlcadstarseeker: there's exactly the indentation problem I was commenting on yesterday -- fortunately the logic was actually invalid this time, but had it not been invalid that would have been a superbly obscure bug injection
06:02.27brlcad(in backtrace.c)
06:02.34brlcadshould fix your indentation
06:16.08brlcadthat said, the login problems are site-wide -- sf reset all passwords and an updated password will take a while to propagate
06:17.42brlcadyukonbob: if you post the exact steps you're trying, it'll be easier to help but I suspect that you're not using the 'oed' command correctly (sed only works with primitives)
06:17.59brlcadthere's an extensive tutorial on oed on the website that starseeker wrote up a while back
06:18.02brlcadgood reading
06:20.35yukonbobhas that oed...
06:20.40yukonbob*oed manual
06:21.07yukonboband Chapter II, and quick ref (which happened to have printed out in complete gibberish for me, except for imagages)
06:21.27yukonbob... but what I'm doing:
06:21.59yukonbobI want a bar (arb8, like a popsicle stick), but with rounded ends.
06:22.30yukonbobso I create another arb8, and difference it w/ an rcc.,
06:23.33yukonbobthen I think: ok - I want two copies of this, and I want one rotated on X axix 180 degrees.
06:23.49yukonbobnow.. is this something I ought to be doing w/ oed?
06:24.15yukonbobI can't "sed" the obj (wrong type)
06:25.14yukonbobultimately, I think I want to rot one, tra both, difference them w/ end of "popsicle stick" and have that popsicle be a nice bar w/ rounded ends.
06:25.23yukonbobhits oed...
06:25.57yukonbobthe tool I have could be as such:
06:26.07yukonbobmake circ rcc
06:26.13yukonbobmake box arb8
06:26.22yukonbob[make sure geometry/orientation are good]
06:26.39yukonbobc cutter box - circ
06:27.32yukonbobnow I want to select "cutter" and apply tra, then: c nicerStick stick - cutter
06:38.19yukonbobyay, oed.
06:38.20yukonbob...though, I need to get some oed-fu together to make my regions behave atomically
06:45.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:14.35*** join/#brlcad bch_ (~bch@S0106001cf044d085.ok.shawcable.net)
07:49.33*** join/#brlcad yukonbob (~bch@S0106001cf044d085.ok.shawcable.net)
08:00.09*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
09:01.11yukonboboed, I'm getting to know you again...
10:35.30*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
11:53.29*** join/#brlcad Stattrav (~Stattrav@122.172.33.253)
11:53.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:15.28CIA-53BRL-CAD: 03jordisayol * r42749 10/brlcad/trunk/misc/debian/changelog: update debian changelog
14:00.22CIA-53BRL-CAD: 03starseeker * r42750 10/brlcad/trunk/src/libbu/backtrace.c: Whoops, compile then commit - fix if/else logic
14:01.43*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
14:02.48starseekerbrlcad: heh, actually I had the modeline activated on my home box but forgot to add it at work
14:02.59starseekerwill get it monday
14:06.13CIA-53BRL-CAD: 03starseeker * r42751 10/brlcad/branches/cmake/ (CMakeLists.txt src/other/step/CMakeLists.txt): One the path is non-default, make sure the default test fails subsequently, even in the same CMake run (in case a subproject sets it in the default case, like step)
15:18.28CIA-53BRL-CAD: 03starseeker * r42752 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Tweak the flags, add comments - don't include -w, misses the whole point
15:30.12starseekerbrlcad: looking at the comments for your gstabs+/ggdb3 logic, the comment suggests 10.4 and less would go with gdb3 but the logic seems to use gstabs+ for lower versions and ggdb3 for higher?
15:31.06brlcadit's hard to keep them straight
15:31.56brlcadiirc, I verified that gstabs+ worked with 10.4
15:32.14brlcadimplying gstabs+ should work for 10.[43210]
15:32.40brlcadhaven't tested as carefully what 10.5 and 10.6 want
15:32.53CIA-53BRL-CAD: 03starseeker * r42753 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Untested - try to duplicate configure.ac version based check for correct mac debug flag
15:33.41brlcadmoreover, I'm pretty sure 10.6 isn't happy with -ggdb3 .. :)
15:33.52starseekerauugh
15:34.24starseekernods - not a big deal, I'll have to test that logic on monday anyway when I have a mac, so I imagine I'll find out then
15:34.45starseekerwhat does the -W flag do without any argument?
15:35.02starseekeris trying to find it in the gcc docs, but not having much luck yet
15:44.14``Erikadditional warnings
15:44.53``Erikum, it looks like the proper name for it is now -Wextra
15:44.57``Erikhttp://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
15:47.54starseekerah, that makes sense
15:47.57starseekeradds Wextra
15:49.19CIA-53BRL-CAD: 03starseeker * r42754 10/brlcad/branches/cmake/misc/CMake/ (BRLCAD_Util.cmake CompilerFlags.cmake): Add Wextra to warning and strict flags
16:17.51CIA-53BRL-CAD: 03starseeker * r42755 10/brlcad/branches/cmake/ (29 files in 29 dirs): There we go - optionally turn off warnings for src/other globally (on by default) and add lots of strict flags
16:18.23brlcadcool
16:18.42starseekeryep, that's got it - itcl is quiet and librt fails :-P
16:20.04CIA-53BRL-CAD: 03starseeker * r42756 10/brlcad/branches/cmake/misc/CMake/BRLCAD_Util.cmake: whoops, remove debug printing
16:21.06starseekeryow src/sig and libpc got noisy
16:50.01CIA-53BRL-CAD: 03starseeker * r42757 10/brlcad/branches/cmake/ (7 files in 4 dirs): Get librt building with strict, but need to check some of the changes with Keith - particularly vdot in opennurbs_ext.cpp - before merging into trunk
17:29.55CIA-53BRL-CAD: 03starseeker * r42758 10/brlcad/branches/cmake/ (8 files in 8 dirs):
17:29.55CIA-53BRL-CAD: Getting too cute for my own good - OK to copy the headers in order to duplicate
17:29.55CIA-53BRL-CAD: the install dir, but don't use them to compile BRL-CAD itself - if you want to
17:29.55CIA-53BRL-CAD: edit a header, the error message should report the location of the copy that
17:29.55CIA-53BRL-CAD: will be edited and checked into subversion, not the build-dir copy.
17:30.47CIA-53BRL-CAD: 03starseeker * r42759 10/brlcad/branches/cmake/src/other/jove/CMakeLists.txt: Point jove to the source dir
17:41.13*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
19:08.28*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
19:08.37*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
19:29.07*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
20:21.02*** join/#brlcad yukonbob (~bch@d207-6-21-57.bchsia.telus.net)
20:21.07yukonbob:)
22:00.35CIA-53BRL-CAD: 03jordisayol * r42760 10/brlcad/trunk/misc/debian/ (5 files): updated debian menu desktop files
22:08.34CIA-53BRL-CAD: 03jordisayol * r42761 10/brlcad/trunk/sh/make_deb.sh: more accurate tests in debian changelog and menu desktop files
IRC log for #brlcad on 20110130

IRC log for #brlcad on 20110130

00:46.21*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
01:28.19CIA-53BRL-CAD: 03starseeker * r42762 10/brlcad/branches/cmake/ (62 files in 19 dirs): Update cmake branch to trunk r42761
01:53.12CIA-53BRL-CAD: 03johnranderson * r42763 10/brlcad/trunk/src/conv/asc/asc2g.c: Yet another size_t issue. This time just changed the declaration of to temporary variabes from size_t to unsigned long.
02:07.01``Erikinteresting exercise video: http://www.youtube.com/watch?v=b_KHh_c6Ha4
02:34.00CIA-53BRL-CAD: 03brlcad * r42764 10/brlcad/trunk/misc/debian/ (5 files): change mime-type to text/plain so that diff history can be reviewed.
03:32.06*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
03:42.57CIA-53BRL-CAD: 03starseeker * r42765 10/brlcad/trunk/doc/docbook/resources/standard/xsl/ (428 files in 21 dirs): Update docbook-xsl to version 1.76.1
04:18.20*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
06:11.12*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
12:36.07*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:48.44CIA-53BRL-CAD: 03starseeker * r42766 10/brlcad/trunk/doc/docbook/resources/standard/xsl/ (284 files in 16 dirs): Switch to xsl-ns - had to use dos2unix to avoid inconsistent line ending failures
15:51.33CIA-53BRL-CAD: 03starseeker * r42767 10/brlcad/trunk/doc/docbook/ (298 files in 12 dirs): (log message trimmed)
15:51.33CIA-53BRL-CAD: Take the plunge... Docbook 4.5 is getting old and development efforts in the
15:51.33CIA-53BRL-CAD: Docbook community have shifted to 5.0, which came out in Feb 2008. Updated
15:51.33CIA-53BRL-CAD: docbook-xsl to docbook-xsl-ns (same version, 1.76.1) and convert xml files to
15:51.33CIA-53BRL-CAD: Docbook 5. The local copy of the dtd does not appear to be needed any longer.
15:51.33CIA-53BRL-CAD: Note that the conversion to Docbook 5 was done automatically using the upgrade
15:51.34CIA-53BRL-CAD: tool, so review will be needed - the 'Converted by db4-upgrade' comment has been
16:30.03CIA-53BRL-CAD: 03starseeker * r42768 10/brlcad/branches/cmake/ (815 files in 38 dirs): Update cmake branch to trunk r42767, fix docbook CMake logic for new setup.
17:05.51CIA-53BRL-CAD: 03starseeker * r42769 10/brlcad/trunk/doc/docbook/system/man1/mged_cmd_template.xml: Update template
17:07.29CIA-53BRL-CAD: 03starseeker * r42770 10/brlcad/trunk/doc/docbook/ (4 files in 4 dirs): Move the template
18:10.53CIA-53BRL-CAD: 03starseeker * r42771 10/brlcad/branches/cmake/doc/docbook/ (4 files in 4 dirs): Update and move template
18:14.07CIA-53BRL-CAD: 03starseeker * r42772 10/brlcad/trunk/doc/docbook/system/ (245 files in 4 dirs): Use info section to handle authors
18:17.44CIA-53BRL-CAD: 03starseeker * r42773 10/brlcad/branches/cmake/doc/docbook/system/ (245 files in 4 dirs): Sync cmake branch to trunk r42772
18:24.18CIA-53BRL-CAD: 03starseeker * r42774 10/brlcad/branches/cmake/doc/docbook/CMakeLists.txt: Ah hah - to have the custom command go out of date when a file is updated, make the command depend on the source file explicitly
19:15.28CIA-53BRL-CAD: 03starseeker * r42775 10/brlcad/branches/cmake/src/tclscripts/ampi.tcl: Verbose output from this script is quite annoying - don't be verbose by default, perhaps it can be made a setting later or redirected to a log file...
19:26.34*** join/#brlcad yukonbob (~bch@d207-6-21-57.bchsia.telus.net)
19:46.35CIA-53BRL-CAD: 03starseeker * r42776 10/brlcad/branches/cmake/ (4 files in 4 dirs): Add a few more dependencies on source files to custom commands
19:49.54CIA-53BRL-CAD: 03starseeker * r42777 10/brlcad/branches/cmake/src/tclscripts/ (17 files in 17 dirs): (log message trimmed)
19:49.55CIA-53BRL-CAD: This results in a bit of a proliferation of build targets, but make all of the
19:49.55CIA-53BRL-CAD: tclscripts and data part of the actual build logic. The effect of this should
19:49.55CIA-53BRL-CAD: be to allow the developer to edit the tcl script in the source dir, type 'make'
19:49.55CIA-53BRL-CAD: in the build dir, and have the build dir copy use the updated tclscript without
19:49.55CIA-53BRL-CAD: any manual copying or running of CMake. In principle, this should be done for
19:49.56CIA-53BRL-CAD: all data in the build dir - it's less likely to be seen on less frequently
20:00.39*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
20:19.30CIA-53BRL-CAD: 03starseeker * r42778 10/brlcad/branches/cmake/doc/docbook/ (10 files in 10 dirs): Add CMakeLists.txt files to the various docbook directories that contain subdirectories, so make will do something in them
20:34.56*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
20:39.00CIA-53BRL-CAD: 03starseeker * r42779 10/brlcad/branches/cmake/ (misc/CMake/BRLCAD_Util.cmake src/nirt/CMakeLists.txt): Using the technique from tclscripts, make a generic macro for BRL-CAD. Use it for nirt - may just replace the tclscripts version altogether
23:30.46*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
IRC log for #brlcad on 20110131

IRC log for #brlcad on 20110131

00:43.31CIA-53BRL-CAD: 03starseeker * r42780 10/brlcad/branches/cmake/src/tclscripts/ (17 files in 17 dirs): Switch to using BRLCAD_ADDDATA in tclscripts
00:52.36CIA-53BRL-CAD: 03starseeker * r42781 10/brlcad/branches/cmake/src/archer/CMakeLists.txt: Few more uses of BRLCAD_ADDDATA - really need to make the plugins less sprawling in directory layout
01:03.20CIA-53BRL-CAD: 03starseeker * r42782 10/brlcad/branches/cmake/ (misc/CMake/BRLCAD_Util.cmake src/archer/CMakeLists.txt): BRLCAD_ADDFILE for single files
01:29.54*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
01:52.42CIA-53BRL-CAD: 03starseeker * r42783 10/brlcad/branches/cmake/ (17 files in 17 dirs): (log message trimmed)
01:52.42CIA-53BRL-CAD: Get a little more sophisticated. Still do the FILE(COPY up front, which is much
01:52.42CIA-53BRL-CAD: quicker and doesn't slow the build down, but allow the user to optionally enable
01:52.42CIA-53BRL-CAD: the data target generation, which will add the data and documentation files to
01:52.42CIA-53BRL-CAD: the make logic at the expense of a large increase in make targets (and
01:52.43CIA-53BRL-CAD: corresponding build slowdown). The initial build will still copy all the files
01:52.44CIA-53BRL-CAD: even with the FILE(COPY if the targets are on, since the timestamps will be
02:23.04*** join/#brlcad ibot (ibot@rikers.org)
02:23.05*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.0 is posted (20101209) || http://itmanagement.earthweb.com/osrc/article.php/3922041/50-Open-Source-Applications-for-Sci-Tech-Education.htm
02:25.31CIA-53BRL-CAD: 03starseeker * r42784 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMakeLists.txt misc/Doxyfile.in): Take a quick stab at adding Doxygen build logic.
02:26.14CIA-53BRL-CAD: 03starseeker * r42785 10/brlcad/branches/cmake/TODO.cmake: update CMake TODO
02:26.23starseekerbrlcad: have you had a chance to try the CMake build yet?
02:27.27starseekerseems to be behaving pretty well here
02:33.51CIA-53BRL-CAD: 03starseeker * r42786 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMakeLists.txt): Don't need an option for doxygen - just don't make it part of the ALL target.
02:40.54CIA-53BRL-CAD: 03starseeker * r42787 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Will eventually need to handle step better, but no need right now and these vars are just garbage.
03:01.40CIA-53BRL-CAD: 03starseeker * r42788 10/brlcad/branches/cmake/ (5 files in 3 dirs): Start cleaning up - mark some things as advanced so they don't show in the default view, more to go
03:02.06brlcadstarseeker: nope, not yet
03:02.39brlcadBRLCAD_ADDDATA?
03:03.02starseekersubstitutes for a bunch of file copy and install commands
03:04.17starseekerI suppose it could be BRLCAD_ADD_DATA if that looks better
03:05.19starseekerhunts dinner
03:05.48brlcadoh, cmake macro
03:06.24brlcadthat's fine, was thinking it was new code logic
03:06.29brlcadlike BRLCAD_DATA
03:06.33starseekerah, nope
03:07.12starseekerblegh, lots of advanced markings to do on the src/other variables
03:07.37brlcadI've been sorting through tons of computer and electrical equipment this weekend, exhausting
03:07.52starseekernods - that's some heavy crap
03:07.57brlcadweeking out old stuff I don't need, trying to get under a half dozen 'puters :)
03:08.03starseekerhehe
03:08.20starseekerneeds to find a good home for his old sun ultra1 boxes - never did get them running
03:08.32brlcadnot going to happen if I count laptops, but desktops should hit the mark
03:08.45starseekerhehe - laptops are easy to store/hide
03:09.12starseekerheads to Applebees for a salad... bbl
03:26.28*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
05:18.08CIA-53BRL-CAD: 03starseeker * r42789 10/brlcad/branches/cmake/misc/CMake/ThirdParty.cmake: Don't force the third party lib off if it's been set on elsewhere, mark vars as advanced
06:00.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:44.17CIA-53BRL-CAD: 03starseeker * r42790 10/brlcad/branches/cmake/ (14 files in 10 dirs): (log message trimmed)
07:44.17CIA-53BRL-CAD: A variety of fixes and cleanups - had broken Tcl/Tk search, got it working -
07:44.17CIA-53BRL-CAD: more advanced options cleanup, got things pretty much where they should be now.
07:44.17CIA-53BRL-CAD: Move termlib logic into FindTERMLIB.cmake so it can work in the third party
07:44.17CIA-53BRL-CAD: logic. Added new ability to the ThirdParty.cmake code - can now FORCE enabling
07:44.18CIA-53BRL-CAD: and disabling of any given library, over and above the ENABLE_ALL style logic.
07:44.19CIA-53BRL-CAD: Hopefully that will allow mimicking the autotools ./configure --enable-all
08:09.56starseekerwoo-hoo
08:25.09starseekercan sleep now - invite folks to try out the cmake branch and see what still isn't up to par
11:05.37*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:03.56*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:47.09CIA-53BRL-CAD: 03jordisayol * r42791 10/brlcad/trunk/misc/debian/source/include-binaries: add debian binary list to properly debian source build
12:55.15dlomanMernin all!  Ready for some ice?  ;)
13:08.40*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:53.42*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
14:12.40*** join/#brlcad roberthl (~robert@v001.rhl.me.uk)
14:12.40*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
15:01.10starseekercrawls back to a state of quasi-awake...
15:01.23starseekerd_rossberg: is your build still doing the extensive re-build thing?
15:06.14d_rossbergstarseeker: now it looks to me as some build targets (e.g. INSTALL?) require a complete rebuild but a simple mged with its depending libraries won't
15:06.47starseekerd_rossberg: that might be... what does the ALL_BUILD target do for you?
15:07.11starseekerususally does ALL_BUILD, PACKAGE and then uses the installer
15:08.46starseekerif I rerun ALL_BUILD multiple times, it does terminate here
15:09.24CIA-53BRL-CAD: 03starseeker * r42792 10/brlcad/branches/cmake/CMakeLists.txt: Shouldn't need these any more, now that bu_brlcad_root and bu_brlcad_data are pretty much sorted out.
15:11.48d_rossbergi haven't checked it recently, last time i tested it it showed a "mystcal" behavior: long times of full system load with no output
15:12.14d_rossbergmaybe i should check it again
15:12.18starseekerum.  What version of Visual Studio are you using?
15:12.30starseekerhas been doing a lot of cleanup
15:13.19starseekerd_rossberg: I'm getting very close to being "finished", and I'd like not to derail all you're stuff when we "go live" with the new CMake logic in the trunk
15:13.23d_rossberg2008
15:13.54starseekerhmm.  Well, I'll try my copy here once...
15:13.56starseekerreboots
15:17.15d_rossbergok, then i'll do some more intensive testing (beside my other work, you know, so be lenient)
15:18.14starseeker'course
15:18.39starseekerjust wanting to give you a heads up that we're getting quite close, and I know it'll probably impact you
15:18.53starseekeryech, windows
15:22.43starseekerI do still need to add the 64bit flags for Windows...
15:29.58CIA-53BRL-CAD: 03starseeker * r42793 10/brlcad/branches/cmake/TODO.cmake: Note Windows 64 bit build as something to check/setup
15:31.30CIA-53BRL-CAD: 03starseeker * r42794 10/brlcad/branches/cmake/CMakeLists.txt: Remove stray debug message
15:47.26CIA-53BRL-CAD: 03starseeker * r42795 10/brlcad/branches/cmake/ (7 files in 7 dirs): Do a little more thorough wrapping of TERMLIB stuff.
15:50.02brlcadstarseeker: if you had to run dos2unix (regarding r42766), then you likely did not set the right proplist on those files when they were added
15:50.43brlcadthere should be an svn:mime-type and svn:eol-style set on all text files
15:51.25brlcadtext/plain and native respectively
15:51.57starseekerbrlcad: I did set those - a few files contained mixed line endings
15:52.12brlcadhm
15:52.54brlcadthat's rather unusual it itself, but okay good to konw
15:53.24starseekeryeah, threw me for a minute - I actually had to install that tool, hadn't encountered that situation before
15:54.14brlcadmixed endings in our files, or xml dtd files, or docbook schema files?
15:54.25starseekerdocbook xsl files
15:54.35starseekeror docbook-xsl-ns, to be specific
15:55.09brlcadk
15:55.49CIA-53BRL-CAD: 03starseeker * r42796 10/brlcad/branches/cmake/CMakeLists.txt: mark as advanced for GUI
16:04.31CIA-53BRL-CAD: 03starseeker * r42797 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Don't try the termlib tests on Windows.
16:06.11*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
16:09.14starseekerggrrrrrr... wish, what is your problem??
16:11.25starseekerat least bwish works
16:12.11starseekersaddles up and heads in
16:14.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:16.36*** join/#brlcad Stattrav (~Stattrav@117.192.138.154)
18:16.36*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:40.36CIA-53BRL-CAD: 03erikgreenwald * r42798 10/brlcad/branches/cmake/src/other/togl/CMake/FindTCL.cmake: throw in some extra quotes on variables to avoid "wrong # of arguments" issues
19:33.13*** join/#brlcad Stattrav (~Stattrav@117.192.138.154)
19:33.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:44.48*** join/#brlcad Ralith (~ralith@d142-058-093-090.wireless.sfu.ca)
20:11.42CIA-53BRL-CAD: 03starseeker * r42799 10/brlcad/branches/cmake/src/other/step/src/ (5 files in 3 dirs): Remove stray semicolons
20:36.31CIA-53BRL-CAD: 03erikgreenwald * r42800 10/brlcad/branches/bottie/ (5 files in 2 dirs): incorporate changes from trunk
21:01.04CIA-53BRL-CAD: 03brlcad * r42801 10/brlcad/trunk/src/librtserver/ (Makefile.am rtserver.c): quell verbose warnings. mark unused parameters, remove dead code, remove unused variables. upgrade size variables to size_t except leave parameters as int and cast accordingly.
21:06.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:13.53CIA-53BRL-CAD: 03brlcad * r42802 10/brlcad/trunk/src/libtclcad/tclcad.c: need to include tk.h too for Tk_Init()
21:17.56CIA-53BRL-CAD: 03brlcad * r42803 10/brlcad/trunk/src/libtclcad/ged_obj.c: mark the slew of unused parameters. huge indicator that these callbacks are screwed up if so many have to be marked as unused
21:25.31CIA-53BRL-CAD: 03brlcad * r42804 10/brlcad/trunk/src/libtclcad/Makefile.am: compiling clean on osx, enable strict
21:30.55starseekerbrlcad: is it correct that there isn't a way to make a binary tar.gz distribution on unix systems and have the exectutables know to look for local relative library paths without setting LD_LIBRARY_PATH first?
21:50.45CIA-53BRL-CAD: 03starseeker * r42805 10/brlcad/branches/cmake/CMakeLists.txt: Add ORIGIN into RPATH
22:06.36starseekerbrlcad: nevermind :-)
22:08.04brlcadstarseeker: ok
22:08.21starseekergoogle and CMake list to the rescue
22:08.45starseekerbrlcad: finish digging through the mountain of computer gear yet?
22:10.50brlcadyep
22:11.00starseekerawesome - what was the final count?
22:11.37brlcadoh, I didn't keep exact count, more important was to sort and organize everything
22:11.50brlcadnow on to the few remaining strict dirs
22:11.59starseekercool
22:12.24starseekerdid you get under half a dozen desktops in the end?
22:17.27brlcadyeah, I think it's five
22:17.58*** join/#brlcad WhiteCalf (MK@whitecalf.net)
22:18.01starseekerthat'll save some space
22:22.59CIA-53BRL-CAD: 03brlcad * r42806 10/brlcad/trunk/src/halftone/ (6 files): mark unused params, rename 'new' param to be 'newrow'
22:23.36CIA-53BRL-CAD: 03brlcad * r42807 10/brlcad/trunk/src/halftone/Makefile.am: passing mac, enable strict
22:24.04CIA-53BRL-CAD: 03brlcad * r42808 10/brlcad/trunk/src/irprep/all_sf.c: mark unused params, avoid exact floating point comparisons
22:26.22CIA-53BRL-CAD: 03brlcad * r42809 10/brlcad/trunk/src/irprep/showtherm.c: unused params, index->idx
22:27.59*** join/#brlcad Ralith (~ralith@d142-058-080-092.wireless.sfu.ca)
22:34.43CIA-53BRL-CAD: 03starseeker * r42810 10/brlcad/trunk/src/other/step/src/ (7 files in 3 dirs): This isn't the right fix for this - revert
22:36.40CIA-53BRL-CAD: 03brlcad * r42811 10/brlcad/trunk/src/librtserver/Makefile.am: linux issues to resolve, not yet
22:40.14CIA-53BRL-CAD: 03starseeker * r42812 10/brlcad/branches/cmake/src/other/step/ (8 files in 4 dirs): revert r42674 in cmake too
23:03.13CIA-53BRL-CAD: 03bob1961 * r42813 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Added cadwidgets::Ged::tk_to_rgb
23:06.50CIA-53BRL-CAD: 03erikgreenwald * r42814 10/brlcad/branches/bottie/src/librt/primitives/bot/btg.c: throw in the global variables
23:21.02CIA-53BRL-CAD: 03starseeker * r42815 10/brlcad/branches/cmake/ (4 files in 4 dirs): Tweaks for BSD - closer to building, though not fully tested
23:25.01*** join/#brlcad Ralith (~ralith@d142-058-080-092.wireless.sfu.ca)
23:32.04starseeker``Erik: ok, that looks like it's got it
23:32.14starseeker(for non-strict on BSD anyway)
23:35.58starseekeryep, togl runs (remotely even)
23:36.31starseekerheads out before it decides to ice
IRC log for #brlcad on 20110201

IRC log for #brlcad on 20110201

01:02.46*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
01:46.53*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
02:20.33*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
03:17.42*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
04:35.58CIA-53BRL-CAD: 03starseeker * r42816 10/brlcad/branches/cmake/CMakeLists.txt:
04:35.58CIA-53BRL-CAD: Going to have to use a global property for the build targets lists - functions
04:35.58CIA-53BRL-CAD: have local variable scope, not sure why it ever worked originally. This needs
04:35.58CIA-53BRL-CAD: more testing, not sure it stays constant over multiple cmake runs and need to
04:35.58CIA-53BRL-CAD: verify it's doing 'the right things'. Also, test noprod rule.
05:07.48CIA-53BRL-CAD: 03brlcad * r42817 10/brlcad/trunk/src/librtserver/rtserver.c: add missing footer
05:08.39CIA-53BRL-CAD: 03brlcad * r42818 10/brlcad/trunk/src/librtserver/rtserver.c: ws/indent consistency cleanup
05:33.13CIA-53BRL-CAD: 03starseeker * r42819 10/brlcad/branches/cmake/CMakeLists.txt:
05:33.14CIA-53BRL-CAD: This is a long shot, but see if a per-directory noprod can be set up. Just
05:33.14CIA-53BRL-CAD: exploring the preliminary steps as yet - if this does work it will involve a
05:33.14CIA-53BRL-CAD: hideous abuse of the old CMP0002 policy allowing non-unique target names, so not
05:33.14CIA-53BRL-CAD: ideal even if it does work...
05:35.51*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
05:57.58*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
05:59.49*** join/#brlcad Stattrav (~Stattrav@122.172.33.253)
05:59.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:44.58CIA-53BRL-CAD: 03jordisayol * r42820 10/brlcad/trunk/ (misc/debian/control misc/debian/rules sh/make_deb.sh): add the option to build debian source packages and change debian configuration.
09:14.39CIA-53BRL-CAD: 03jordisayol * r42821 10/brlcad/trunk/ (4 files in 2 dirs): add two new doc menu entries
09:58.29cjdevlin!info xubuntu-desktop
11:19.43dlomanWell, i must admit that this storm is rather disappointing :/
11:20.11dlomansnow was supposed to start at 1700 yesterday and accumulate 5 inches.. so far, just a dusting.
11:20.34dlomanBut the ice has finally started..... yay.
12:38.49*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:29.54*** join/#brlcad Stattrav (~Stattrav@117.192.135.87)
13:29.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:36.57*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:38.13``Erikhm, the cul de sac is a sheet of ice, no one else in my cul de sac has tried venturing out, one of my neighbors said he heard about lots of accidents on tv and was going to wait until it warms up later to try
13:38.17``ErikO.O wee
13:48.35dlomantime to take the M3 out for a 'spin' eh? =D
13:51.29``Erikheh, it wouldn't be able to get out of the driveway, still too much snow and ice
13:59.09dlomanfun fun!
14:19.47*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
14:57.07dlomanIcy here, icy there...but at least post is open! lol
15:34.16``Erikonce I got out of my neighborhood (I think about a mile?), it was all good
15:34.43``ErikI don't think they salt back in my development, or the one I have to go through to get from mine to the highway
15:35.43``Erik0.7 miles according to google maps heh
15:41.40CIA-53BRL-CAD: 03starseeker * r42822 10/brlcad/branches/cmake/CMakeLists.txt: (log message trimmed)
15:41.40CIA-53BRL-CAD: Eeek. This appears to be a working per-directory noprod solution. Done the
15:41.40CIA-53BRL-CAD: best I can for convenience vs. policy - CMP0002 forbids non-unique target names,
15:41.40CIA-53BRL-CAD: and hence excludes a 'make noprod' rule for each directory. Even forcing that
15:41.40CIA-53BRL-CAD: to OLD, get some odd behavior with the toplevel 'make noprod' rule (not
15:41.41CIA-53BRL-CAD: surprisingly, the policy is there for a reason). Hence, there is a toplevel
15:41.42CIA-53BRL-CAD: make noprod command and in subdirectories 'make noprod' becomes 'cmake -P
15:42.56starseekerbrlcad: that appears to be the best I can do for noprod - you can achieve (I think) the effects of make noprod in a directory but you'll have to do the cmake -P thing instead of make noprod
16:11.14CIA-53BRL-CAD: 03starseeker * r42823 10/brlcad/branches/cmake/ (9 files in 5 dirs): Fix step build properly - surprise, surprise using scl_cf.h correctly actually helped
16:20.15CIA-53BRL-CAD: 03starseeker * r42824 10/brlcad/branches/cmake/src/conv/step/CMakeLists.txt: Add the output include dir for step
17:05.17CIA-53BRL-CAD: 03starseeker * r42825 10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Nevermind the dash - this symlink logic is too fragile, so just go with CMake standard practice
17:08.52CIA-53BRL-CAD: 03jordisayol * r42826 10/brlcad/trunk/misc/Makefile.am: add two debian doc menu entries
17:53.08CIA-53BRL-CAD: 03starseeker * r42827 10/brlcad/branches/cmake/ (5 files in 5 dirs): Ah - remove files based on version number properties as well for noprod. Start using the exec list to strip executables for CPack
18:28.15*** join/#brlcad andrecastelo (~andre@187.115.160.108)
18:33.10CIA-53BRL-CAD: 03erikgreenwald * r42828 10/brlcad/trunk/src/librt/primitives/nmg/nmg_junk.c: Remove the HIDDEN from these junk functions to avoid "unused symbol" failures when debugging is off.
18:43.21CIA-53BRL-CAD: 03starseeker * r42829 10/brlcad/branches/cmake/src/other/step/CMake/SCL_Utils.cmake: Don't use absolute install paths
18:54.28CIA-53BRL-CAD: 03starseeker * r42830 10/brlcad/branches/cmake/ (4 files in 4 dirs): another absolute install path
19:12.52``Erikhttp://punditkitchen.files.wordpress.com/2011/01/1fe680f4-203b-47af-bb23-8bb0e0f2a623.jpg
19:20.16CIA-53BRL-CAD: 03starseeker * r42831 10/brlcad/branches/cmake/ (3 files in 2 dirs): Little more tweaking to mark variables as advanced
19:25.14CIA-53BRL-CAD: 03starseeker * r42832 10/brlcad/branches/cmake/src/tclscripts/ampi.tcl: verbose flag is intentional to highlight problems - restore
19:29.26CIA-53BRL-CAD: 03johnranderson * r42833 10/jbrlcad/trunk/ (10 files in 2 dirs): Point and Vector3 now have a common base class (Triple)
19:36.29CIA-53BRL-CAD: 03starseeker * r42834 10/brlcad/branches/cmake/ (25 files in 11 dirs): MFC 42833
19:43.05CIA-53BRL-CAD: 03starseeker * r42835 10/brlcad/trunk/src/libbu/brlcad_path.c: realpath tweak, add ifdef wrapped Windows logic
19:45.49CIA-53BRL-CAD: 03starseeker * r42836 10/brlcad/trunk/src/libbn/anim.c: initialize dir (quiet a warning)
19:57.47starseekerum...
19:57.49starseekercc1plus: warnings being treated as errors
19:57.49starseekersrc/other/openNURBS/opennurbs_array.h: In function ?ON_Curve* brlcad::pullback_curve(ON_BrepFace*, const ON_Curve*, brlcad::SurfaceTree*, double, double)?:
19:57.52starseekersrc/other/openNURBS/opennurbs_array.h:353: error: inlining failed in call to ?virtual ON_2dPointArray::~ON_2dPointArray()?: call is unlikely and code size would grow
19:57.55starseekersrc/librt/opennurbs_ext.cpp:2400: error: called from here
19:58.12starseekerhuh?
20:11.00brlcadc++ should not be compiling with strict
20:11.29brlcadthough that warning is a valid "issue"
20:12.01brlcaddestructors shouldn't be inline anyways
20:12.27starseekerdoesn't see where it's being inlined
20:33.08CIA-53BRL-CAD: 03brlcad * r42837 10/brlcad/trunk/misc/debian/ (7 files): switch to text/plain and set eol-style to native
20:42.24CIA-53BRL-CAD: 03brlcad * r42838 10/brlcad/trunk/src/libbn/anim.c: VINIT_ZERO instead of {}
20:50.00CIA-53BRL-CAD: 03starseeker * r42839 10/brlcad/branches/cmake/src/libfft/CMakeLists.txt: Yow - optimized is what kills fft - don't go above 256 until there's a demonstrated need
20:51.28brlcadhehe
20:53.02brlcadthe autotools build only goes up to 256
20:53.10CIA-53BRL-CAD: 03starseeker * r42840 10/brlcad/branches/cmake/src/libtclcad/CMakeLists.txt: Make libtclcad strict
20:53.31brlcadthose generated sources get big fast
20:53.37starseekerindeed
20:54.26brlcadbut it's clever, iirc one of the fastest implementation methods
20:54.43starseekerneat
20:54.54starseekerhmm
20:54.57starseekersrc/liboptical/sh_noise.c:174: error: ‘noise_render’ declared ‘static’ but never defined
20:54.58brlcadwould be ineteresting to revisit some comparisons to see if we're still one of the best
20:55.56brlcadthe curse of forward declarations
20:56.17brlcadthere shouldn't be any forward declarations
20:59.26starseekermust have missed an update
21:01.47CIA-53BRL-CAD: 03starseeker * r42841 10/brlcad/trunk/src/liboptical/sh_noise.c: Forward declarations bad. - move mfuncs down and get rid of them
21:01.58starseekersh_points.c:79: error: useless storage class specifier in empty declaration
21:04.09CIA-53BRL-CAD: 03starseeker * r42842 10/brlcad/trunk/src/liboptical/sh_points.c: Hidden causes a warning here about useless storage class specification
21:05.11*** join/#brlcad R0b0t1 (~Enigma@64-136-219-55.dyn.everestkc.net)
21:05.11*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
21:10.51epilegI can not create pdf files in Linux. is this normal?
21:11.06starseekerepileg: you mean the build won't make them?
21:11.14epilegyes, this is
21:11.21starseekerwhat is the error?
21:11.35epilegno error, on config says...
21:11.39epilegjust a moment
21:11.46starseekeroh - you need to install Apache FOP
21:13.03epilegstarseeker: thanks!  I'll check
21:14.54starseekerbrlcad: uh, this one has me puzzled...
21:14.58starseekersrc/conv/g-vrml.c:821: error: variable ‘__stream’ might be clobbered by ‘longjmp’ or ‘vfor
21:25.46brlcadstarseeker: you didn't see all of those longjmp commits last week?
21:26.20brlcador at least read the commit messages .. I blathered quite a bit about that :)
21:26.27starseekerthought he recalled something
21:26.30starseekerchecks...
21:30.28starseekerbrlcad: r42544?
22:00.51starseekercannot follow what this logic is doing
22:01.06starseekerq
22:12.34CIA-53BRL-CAD: 03starseeker * r42844 10/brlcad/trunk/src/conv/dem-g.c: Compiler doesn't like this inline
22:19.40CIA-53BRL-CAD: 03starseeker * r42843 10/brlcad/trunk/src/liboptical/sh_text.c: Need a little more careful look here, but this removes enough forward decls to get it building
22:20.39CIA-53BRL-CAD: 03brlcad * r42845 10/brlcad/trunk/ (4 files in 3 dirs): check for GetFullPathName() and conditionalize on HAVE_GETFULLPATHNAME instead of _WIN32 accordingly
22:21.44CIA-53BRL-CAD: 03brlcad * r42846 10/brlcad/trunk/src/libbu/ (brlcad_path.c timer.c): include bio.h instead of direclty including windows.h; keying off _WIN32 is bad form
22:21.44CIA-53BRL-CAD: 03brlcad * r42847 10/brlcad/trunk/src/mged/mged.c: ERR... really? somehow this commit didn't make it through. give mged the ability to forcibly flip the version number even if librt doesn't do it automatically.
22:21.44CIA-53BRL-CAD: 03brlcad * r42848 10/brlcad/trunk/src/bwish/ (consoleMain.c winMain.c): another bio.h inclusion instead of windows.h
22:21.45CIA-53BRL-CAD: 03erikgreenwald * r42849 10/brlcad/branches/bottie/ (4 files in 3 dirs): mimic rt_bot_minpieces for TIE algorithm
22:27.20CIA-53BRL-CAD: 03starseeker * r42850 10/brlcad/trunk/src/conv/g-vrml.c: work around potential clobber in g-vrml
22:27.20CIA-53BRL-CAD: 03starseeker * r42851 10/brlcad/trunk/src/conv/g-x3d.c: Same issue with g-x3d
22:28.37CIA-53BRL-CAD: 03starseeker * r42852 10/brlcad/trunk/src/libdm/ (dm-plot.c dm-ps.c dm-tk.c): reorder to remove forward declarations
22:39.41CIA-53BRL-CAD: 03starseeker * r42853 10/brlcad/branches/cmake/misc/CMake/BRLCAD_Util.cmake: Turn off Werror when we see cpp files in a strict library, unless CXX_STRICT is on. Leave the warnings unless the warnings option is off.
22:42.31CIA-53BRL-CAD: 03starseeker * r42854 10/brlcad/branches/cmake/CMakeLists.txt: Add the BRLCAD-ENABLE_CXX_STRICT option
22:44.30CIA-53BRL-CAD: 03brlcad * r42855 10/brlcad/trunk/src/mged/mged.c: tweak the message to let the user know whether -f had any affect. only mark as read-only and flip if we need to.
22:45.16CIA-53BRL-CAD: 03starseeker * r42856 10/brlcad/trunk/src/ (4 files in 2 dirs): Few misc tweaks - turn off some unused libged code, UNUSED in brep.cpp
22:46.55CIA-53BRL-CAD: 03starseeker * r42857 10/brlcad/branches/cmake/ (26 files in 10 dirs): Put various fixes into CMake branch
22:46.57CIA-53BRL-CAD: 03brlcad * r42858 10/brlcad/trunk/include/config_win.h: file wasn't saved for r42845. set HAVE_GETFULLPATHNAME
22:49.11CIA-53BRL-CAD: 03starseeker * r42859 10/brlcad/trunk/src/libtclcad/ged_obj.c: not defined
22:50.05CIA-53BRL-CAD: 03starseeker * r42860 10/brlcad/branches/cmake/src/bwish/ (consoleMain.c winMain.c): More fixes from trunk
22:50.36CIA-53BRL-CAD: 03starseeker * r42861 10/brlcad/branches/cmake/src/libtclcad/ged_obj.c: remove this on cmake branch too
22:50.54brlcadshould delete unused code
22:51.13starseekerbrlcad: thought I'd check with Bob/Richard before nuking
22:51.42brlcadit's in revision history
22:51.49starseekertrue
22:52.07brlcadif there's no comment, then there's definitely no reason to keep it
22:52.07CIA-53BRL-CAD: 03starseeker * r42862 10/brlcad/branches/cmake/src/mged/mged.c: update from trunk
22:52.47brlcadcommented out code, #if 0'd code
22:53.41brlcadit's a maintenance burden and just makes the files messy and often error prone, the code falls out of sync quickly and can cause bugs if re-enabled
22:57.02CIA-53BRL-CAD: 03starseeker * r42863 10/brlcad/trunk/src/libged/ (bigE.c human.c): Go ahead and remove the code from libged, instead of commenting itout
22:57.45brlcadah yeah, covered by HACKING under the refactoring section too :)
23:00.50CIA-53BRL-CAD: 03starseeker * r42864 10/brlcad/trunk/src/ (4 files in 4 dirs):
23:00.50CIA-53BRL-CAD: Let's try this again - see if we can do without tclcad_tcl_library. Using
23:00.50CIA-53BRL-CAD: private Tcl functions is Not Good, particularly when it's for debug printing.
23:00.50CIA-53BRL-CAD: also removing the found_init_tcl call to TclSetLibraryPath - same basic problem
23:00.50CIA-53BRL-CAD: and the comment says it doesn't do what we might expect it to anyway.
23:02.20CIA-53BRL-CAD: 03starseeker * r42865 10/brlcad/branches/cmake/src/ (4 files in 4 dirs): remove tclcad_tcl_library in CMake branch too
23:02.37starseekerbrlcad: is that alternative way to do the make noprod thing acceptable?
23:04.18brlcaddoing a "make noprod" from the top-level would even probably work if you can relink a given binary (e.g. "make mged") with one step
23:05.57brlcadhard to say without trying it in practice really, wasn't clear what the final step(s) needed were going to be
23:06.29starseekeruh... you just do cmake -P ./cmake_noprod.cmake instead of make noprod
23:07.12brlcadheh, might just end up with an sh/noprod.sh script then that runs that
23:08.13starseekercmake will relink the libraries required by mged before linking mged
23:08.23starseekerfollowing its dependency logic
23:09.13brlcadso what about a simple rule that wipes out all products?
23:09.23starseekerthat's the toplevel make noprod
23:09.25starseekerthat works
23:09.41starseekerit's just in the subdirectories you need to run the specific script
23:09.48starseekerI can't define a noprod target for every directory
23:11.00CIA-53BRL-CAD: 03bob1961 * r42866 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Updated Archer::constructor to properly set the view of the command window (i.e. how much command window to display verses geometry window etc.
23:13.04starseekerO.o the toy jeep is giving out Bend radii errors
23:15.10brlcadthe toplevel make noprod sounds like it might end up being more practical than cmake -P ./cmake_noprod.cmake
23:15.31starseekerwell, they're both there
23:15.45starseekerit's not an either/or situation
23:16.04brlcadit just feels way too long and prone to being forgotten
23:16.19starseekerwhat about cmake -P noprod
23:16.39starseekerthe last arg is a file name, I can just call it noprod if that's better
23:16.40brlcadthat'd probably be better
23:17.01brlcadno way to inject custom make rules?
23:17.26brlcadsome "if target is makefile, #include Makefile.inc"
23:17.44brlcadsimilar to what is done for "make fast"
23:17.59starseekernot that I've found so far...
23:18.00brlcadand make noprod for that matter, iirc
23:20.00brlcadmy gut feeling is if all products are unique, then cd'ing down into the hierarchy isn't going to be as important
23:20.31brlcadsince I can "make noprod && make rt" and it'll relink rt (along with all of rt's dependencies)
23:20.37starseekernods
23:20.50starseekerwell, the cmake -P option is there if it's needed
23:21.12starseekerwas quite the operation to set up
23:21.18brlcadnot quite as ideally targetted as *only* relinking rt, but possibly workable
23:21.28brlcadhave to see in practice, but it's a minor point
23:21.55brlcadI don't doubt it
23:22.56brlcadunfortunately, cmake makes some things much harder to do
23:23.09brlcada known limitation going into this
23:23.29starseekera few maybe, but I haven't had too much trouble on the whole...
23:23.35brlcadheh
23:23.44starseekermain trouble was Tcl/Tk
23:23.45brlcadsays you more than 6 months later :)
23:24.19starseeker<snort> If I'd been re-creating the autotools logic, I'd bet on a year easy (for me, anyway)
23:25.58CIA-53BRL-CAD: 03starseeker * r42867 10/brlcad/branches/cmake/CMakeLists.txt: no reason to use cmake_noprod.cmake - just call it noprod so it's more like a make target
23:27.01starseekeryou super scripting gurus are more comfortable with sh and friends - for me it might as well be perl
23:28.40brlcadautotools was a learning hurdle too
23:29.03brlcadboth erik and I put several months whipping configure.ac and friends into shape
23:30.55brlcadthe cmake effort is probably on-par, seems like even a bit more given it's not as mature and flexible
23:31.29brlcadbut then higher short-term with the hope that maintenance is lower in the long-term
23:31.48starseekernods
23:33.11brlcadrealistically speaking, there's undoubtedly months of work still remaining to bring it on-par cross-platform in a low-maintenance fashion with all the bugs squeezed out
23:34.06starseekerI suppose.  On the whole I'm rather happy with how it's turned out, but of course I haven't done extensive options testing and such
23:34.21starseekerknows turning off X11 won't quite work yet, for example - it still builds Tk
23:35.29brlcadsimple code metrics -- no code is perfect, there will be bugs even aside from incompleteness
23:37.40brlcadnew code is pretty consistently reliable to have bugs on the order as bad as 1% to as good as 0.1% (on average)
23:38.35starseekerbrlcad: what are the remaining hurdles for me to be able to merge into trunk?
23:39.33brlcadlines-of-code of course isn't really strictly reliable, but it's pretty reasonable to assume that if 10000 new lines of logic were written, that there's at least a dozen bugs in there if not more
23:42.45brlcadstarseeker: well whenever you're confident that you're "done done", that should mean that someone else should be able to do a code review to see if there are any show-stopper code differences, things that were turned on/off, that a release can be produced and verified, that everything is properly documented (which is really part of release verification)
23:45.10CIA-53BRL-CAD: 03starseeker * r42868 10/brlcad/branches/cmake/src/ (bwish/CMakeLists.txt other/CMakeLists.txt): Don't enable Tk even with ENABLE_ALL if we aren't supposed to build it
23:45.39starseekerbrlcad: so I need the equalivent to our documentation of the configure options for the significant CMake variables
23:46.27starseekerponders... hmm...
23:46.41brlcadideally, yes -- but more specifically, README, INSTALL, HACKING, doc/* have to be updated
23:47.24brlcadplaces that refer to "autogen.sh", or "configure", "make", "Makefile.am", etc
23:47.43brlcadwe have to be able to push out a source release
23:47.59brlcadcompilation docs are part of that
23:47.59starseekernods.
23:52.04brlcadnotes that it's time to prepare a release
23:53.00brlcadhow extensively did you test r42864 ?
23:53.18brlcadtclcad_tcl_library() removal
23:53.45starseekerI've had it gone in the CMake branch for a while, but less extensively than I'd like
23:54.15starseekerunless its documentation was wrong, it's a debug output function?
23:54.26brlcadit's not
23:54.43brlcadit prevents a runtime crash for some versions of tcl
23:56.14brlcadTclGetLibraryPath() initializes some things internal to the Tcl library that were not otherwise getting initialized by Tcl_Init or other calls and would result in a non-catchable run-time crash
23:56.59brlcadiirc, not visible during --enable-all but was reproducible if you used a system tcl/tk
23:57.51brlcaddon't know if it was specific to any tcl version, 8.4 or 8.5 but it was a hard show-stopper crash of mged
23:58.32brlcadit was a while ago too, so if it works with --enable-all and --disable-all now with 8.5+ for example, then we can just move forward
23:58.57starseekerok, I'll see what happens with a system tcl/tk
23:59.15starseekerWe can put it back in if we have to, but I really don't like calling private Tcl/Tk functions
23:59.26brlcadputting it back isn't the issue
23:59.34brlcadgiven it's a hard crash, we can't do a release until verifying
23:59.40starseekerah
23:59.43brlcadbecause it's otherwise DOA
IRC log for #brlcad on 20110202

IRC log for #brlcad on 20110202

00:00.35brlcadneed to check at least linux with and without system tcl, and mac (without of course)
00:01.37brlcadfwiw, make test and make distcheck aren't sufficient, have to kick off the GUI
00:01.46starseekernods
00:06.57brlcadI had distchecks passing with all options on/off for 64-bit linux, testing mac now
00:31.44CIA-53BRL-CAD: 03starseeker * r42869 10/brlcad/branches/cmake/TODO.cmake: Add a few more TODO items for CMake
00:35.08CIA-53BRL-CAD: 03starseeker * r42870 10/brlcad/trunk/src/mged/mged.c: dbip_filename -> dbi_filename
00:50.59*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
00:53.33starseekerbrlcad: I think I may have messed up.  I am using BRLCAD_DATA as a relative path from BRLCAD_ROOT, but I'm seeing in trunk that both BRLCAD_DATA and BRLCAD_ROOT are full paths
01:09.54*** join/#brlcad DX^ (~DX@c-71-59-50-121.hsd1.ga.comcast.net)
01:10.01DX^I can't find the configure flag to disable compiling with X11
01:10.40starseeker--disable-x11 ?
01:14.14DX^I tried --disable-x
01:14.19DX^but that didn't work, I'll try that..
01:15.55DX^still says its enabled
01:16.40starseeker--without-x11 ?
01:17.34DX^trying
01:17.58starseekerbrlcad: my apologies - I think I made my own trouble with the path logic, after all
01:22.19DX^that worked, awesome
01:22.38CIA-53BRL-CAD: 03starseeker * r42871 10/brlcad/trunk/src/libbu/brlcad_path.c: Dur. BRLCAD_DATA is supposed to be a full path, but I had a relative path in the CMake logic... hilarity ensued. Put it back the way it should be and make CMake do it right.
01:29.59CIA-53BRL-CAD: 03starseeker * r42872 10/brlcad/trunk/configure.ac: Add note that BRLCAD_DATA must be a full path
01:39.41CIA-53BRL-CAD: 03starseeker * r42873 10/brlcad/branches/cmake/ (CMakeLists.txt configure.ac src/libbu/brlcad_path.c): Do BRLCAD_DATA the right way in CMake.
01:49.51CIA-53BRL-CAD: 03starseeker * r42874 10/brlcad/trunk/ (7 files in 4 dirs): Apply 42757 to trunk - without this, getting failures on gentoo with warnings enabled.
01:55.54CIA-53BRL-CAD: 03starseeker * r42875 10/brlcad/trunk/configure.ac: Whoops - manuals/archer is still gone
02:12.14CIA-53BRL-CAD: 03starseeker * r42876 10/brlcad/trunk/doc/docbook/Makefile.am: catalog.xml is no more
02:35.33brlcadstarseeker: hm, yeah they should be full paths but it's an interesting thought
02:35.51brlcadrelative path "should" work, but I can see how an assumption may be in there
02:36.40starseekerrelative is already sort of there with the root/share/brlcad/version check - that's what you get with a relative BRLCAD_DATA
02:36.52brlcadBRLCAD_ROOT and BRLCAD_DATA are environment variables so they could conceivably be relative if we allow it
02:37.10brlcadbu_brlcad_root() and bu_brlcad_data() probably have assumptions otherwise
02:37.27brlcadah, yeah, that would work
02:37.36brlcadthough full-path root and relative data should work too
02:37.58brlcador the limitation should be documented
02:38.04starseekerthat's what I was doing with CMake (albeit accidentally)
02:38.12starseekermentioned it in configure.ac
02:38.22brlcadyeah, i saw
02:38.39brlcadI mean to users though -- the environment variable isn't set by configure
02:38.46brlcadit sets the "hard wired" default
02:38.48starseekerwouldn't be too hard to make it accept a relative path - I did it initially before I realized
02:38.59starseekerah, point
02:39.52starseekerWindows might be a problem if they stick a drive letter at the beginning of a path though
02:40.33starseekerbrlcad: distcheck passes here
02:41.00starseekeralthough come to think of it, it did work on Windows
02:48.18brlcadcool
02:48.22brlcadmged runs?
02:48.33brlcadwhat platform/settings?
02:49.02starseekergentoo x86_64 with --enable-all
02:49.11starseekermged seems to run
02:49.16starseekerwill build again with system tcl/tk
02:49.59brlcadokay, testing mac here
02:50.08brlcad10.6
02:56.38brlcadeveryone ready for GSoC?
02:57.09starseekerah, that's on again?
02:57.10starseekersweet
03:06.21starseekerbrlcad: just a thought - with the cmake build, all the final build products are right there in lib or bin
03:08.21DX^IGES/STEP converters are segfaulting on me
03:08.23DX^with the newest code
03:08.51starseekeron files that worked previously?
03:09.02DX^no, but the STEP file I'm trying is just a box
03:09.06DX^don't think it can get much simpler
03:09.14starseekerwhat's the error?
03:09.35DX^"Segmentation fault"
03:09.42starseekerah, that's it?
03:09.56DX^yep
03:09.59starseekerDX^: can you post the file on a bug report at sourceforge?
03:10.15starseekerbrlcad: local tcl/tk seems to work too
03:10.32DX^starseeker: yeah
03:10.47starseekercool - we'll need to hook up a debugger to see what happened
03:32.13brlcadstarseeker: that's good to hear -- what version of tcl?
03:32.16CIA-53BRL-CAD: 03brlcad * r42877 10/brlcad/trunk/misc/Makefile.am: include debian/source/include-binaries in dist
03:32.27brlcadsuspects the crashes were 8.4 specific
03:33.24starseeker8.5.9
03:37.28brlcadstarseeker: that's a good point regarding cmake build -- noprod might be obsolete via that alone since you could run targetted rm's and remake
03:37.58brlcadhave to put it through the paces with use to see what's most efficient
03:39.41CIA-53BRL-CAD: 03starseeker * r42878 10/brlcad/branches/cmake/src/other/togl/CMakeLists.txt: Stray character
03:39.53CIA-53BRL-CAD: 03tbrowder2 * r42879 10/brlcad/trunk/HACKING: added info on using in-tree executables without installing\nadded words about developer responsibilities
03:48.10CIA-53BRL-CAD: 03starseeker * r42880 10/brlcad/branches/cmake/src/other/togl/demo/gears.tcl: Just package require Togl for the gears demo - don't need to manually load anything if we're set up correctly.
03:53.17CIA-53BRL-CAD: 03tbrowder2 * r42881 10/brlcad/trunk/INSTALL: added information about where file check sums are to be found
04:14.11*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
05:08.29CIA-53BRL-CAD: 03starseeker * r42882 10/brlcad/branches/cmake/bench/CMakeLists.txt: benchmark needs pixcmp
05:36.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:33.42*** join/#brlcad Stattrav (~Stattrav@122.172.33.253)
06:33.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:26.28*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
07:35.18*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
09:59.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:49.28*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:52.28epilegbrlcad: what's better? build deb packages with or without pdf files?
12:52.28epilegwith (≃ 85 MB.), without (≃ 55 MB.)
13:58.38starseekerepileg: for now I'd say without
13:58.55epilegok, thanks!
13:58.55starseekerwe have some work to do before the pdf output from most of our stuff is fit for consumption
14:21.00CIA-53BRL-CAD: 03erikgreenwald * r42883 10/brlcad/branches/bottie/ (1260 files in 90 dirs): MFC 42842
14:37.09*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
14:37.26brlcadstarseeker: did "make test" pass for you?
14:37.56brlcadI'm getting all sorts of failures here, but still have to look into why
14:42.33starseekerhmm - it's failing to create solids.rt, shaders.rt...
14:44.42*** join/#brlcad Stattrav (~Stattrav@117.192.140.121)
14:44.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:46.21CIA-53BRL-CAD: 03brlcad * r42884 10/brlcad/trunk/src/halftone/main.c: enable-optimized linux strictness failure, check fwrite() return value
14:47.15starseekerbrlcad: opendb isn't creating solids.g
14:48.02starseekerwhen it runs opendb solids.g y the command completes, but a database is not opened
14:48.28brlcadokay, that should be easy to fix
14:48.37brlcadmaybe even my doing with the -f flag
14:48.48starseekerthat was my first guess
14:49.00brlcadan argc check off by one or something
14:49.33brlcadcool, optimized and unoptimized distchecks now all passing on linux
14:56.54starseekerbrlcad: I'm guessing it's in 42564
14:57.21brlcadhah, looks like the logic is just reversed
14:57.34brlcadopendb files.g n creates a database :)
14:57.42starseekerlol
14:58.11starseekerok, so probably not that commit then
15:01.21``Erikwell, damn, I just spent the last 2 days trying to get things together and working to move bottie to trunk O.o
15:01.38starseekerwhy is that a problem?
15:02.08``Erikif we're in the middle of release cycle, it might not be the best time to do it
15:02.08brlcadit can be the highlight feature for 7.18.4 or 7.20 even
15:02.33brlcadget more attention that way anyways
15:02.46*** join/#brlcad mafm (~mafm@72.Red-83-45-72.dynamicIP.rima-tde.net)
15:02.51``Erikapparently some weirdness happened, or svn sucks for this kinda merge, royal pain :/
15:03.28brlcad``Erik: it sucks until that last to-do item is dealt with, which I'm planning as soon as release is posted
15:03.44brlcadour repo is too old to support merge tracking
15:03.52``Erikah, --reintegrate?
15:03.54brlcadthat's what has been causing some of the merge headache
15:03.56``Erikfsfs 2 vs 3 or something
15:04.07brlcad1.5+ backend repo
15:04.12brlcadwe're a 1.4 repo or something iirc
15:04.24starseeker``Erik: were you going to try and track down the big missing pieces in bottie raytracing prior to merge?
15:04.49starseekeror just stick with the insane high threshold for now
15:05.23``Erikstarseeker: was going to have an obnoxiously high # and work it after merge, I seem to spend way more time merging and resolving conflicts to try to track trunk than getting to actually work on it
15:06.06``Erikwonders if there's a darcs/svn bridge O.o
15:09.56starseeker``Erik: then you should be pretty safe to merge, yes?
15:11.14``Erikprobably *shrug*
15:16.13brlcadI wouldn't call that merge-safe in the least .. heh
15:16.20brlcadit's a huge body of change to code and a new feature
15:18.38brlcadrelease safe things are like minor bug fixes, updating documentation, tweaking a bu_log, removing dead code, adding comments, ...
15:21.13brlcadthat really is great feature for the next release where it can be spoken to and highlighted, maybe erik can write up a mini article about it all even
15:22.00CIA-53BRL-CAD: 03erikgreenwald * r42885 10/brlcad/trunk/src/halftone/main.c: more missed size_t changes
15:24.38CIA-53BRL-CAD: 03erikgreenwald * r42886 10/brlcad/trunk/src/libged/ (vdraw.c wdb_vdraw.c): cast to long unsigned int to match wdb_vdraw.clu
15:25.05``Erikugh, tons of those in src/conv
15:26.01brlcadwant me to disable strict or you going to hit em up?
15:26.30brlcadI don't have a plat that warns on that one opt or non-opt
15:26.37``ErikI can hit them, bit nervous about casting read pointers like that blindly
15:26.41``Erikcrit should do it
15:27.14``ErikFreeBSD 8.2-PRERELEASE #3: Thu Dec  2 13:59:53 EST 2010
15:28.08``Erikusing system tcl, tk, tnt, debug off (that seems to be a big one), optimized on
15:28.50CIA-53BRL-CAD: 03brlcad * r42887 10/brlcad/trunk/TODO: two release issues being worked on now, opendb failure and strict failures on fbsd
15:28.57brlcadah, debug off .. haven't tries that in a while
15:29.52CIA-53BRL-CAD: 03erikgreenwald * r42888 10/brlcad/trunk/src/libtclcad/tkImgFmtPIX.c: more size_t fixing
15:40.57CIA-53BRL-CAD: 03erikgreenwald * r42889 10/brlcad/trunk/src/conv/ (6 files in 3 dirs): casts/changes to cope with size_t vs vprintf
15:46.12``Erikthat seems to be all the type warnings, there is still the tcl85 vs tcl8.5 link error when building tcl with BRL-CAD, though :/
15:49.35CIA-53BRL-CAD: 03brlcad * r42890 10/brlcad/trunk/src/libbu/booleanize.c:
15:49.36CIA-53BRL-CAD: bu_booleanize() FAIL. several problems: 1) \!str == 0 means we return false for
15:49.36CIA-53BRL-CAD: all non-null strings, 2) strtol() will return 0 if there are no numbers (boo,
15:49.36CIA-53BRL-CAD: hiss), and 3) it wasn't taking whitespace into consideration. stash the input
15:49.36CIA-53BRL-CAD: into a vls, trim whitespace, then perform our tests.
15:49.49starseekerbrlcad: heh, you just beat me to it
15:49.53starseekerwas writting my commit message
15:50.55CIA-53BRL-CAD: 03brlcad * r42891 10/brlcad/trunk/src/libbu/booleanize.c: remove debug statements
15:51.35brlcadstarseeker: ah, heh -- what was your change?
15:51.41brlcadthere's another problem in mged.c
15:52.09starseekerwas doing str == NULL instead of !str
15:52.24starseeker!str was returning 0 here even for a valid string
15:52.39starseekergood call on the whitespace
15:53.34CIA-53BRL-CAD: 03brlcad * r42892 10/brlcad/trunk/src/mged/mged.c: logic is reversed. if NOT true, i.e. the user responded 'n', then report that no database is open.
15:53.41brlcad!str is 0 for all valid strings ;)
15:53.49brlcad!str is only true if str is null :)
15:54.03starseekerah, gotcha
15:54.38starseekerone possible improvement I can still make...
15:54.43brlcadit should have been "str == NULL" or "!str" .. but "!str == NULL" (i.e., "!str == 0") means that all valid strings will return negative
15:54.51starseekerhehe
15:54.53CIA-53BRL-CAD: 03starseeker * r42893 10/brlcad/trunk/src/libbu/booleanize.c: Can still use strtol, but need to make sure endptr is '\0' (i.e., that a valid number was actually processed).
15:55.53starseekerbrlcad: if I'm reading the strtol documentation right, that will work
15:56.23brlcadhm
15:56.25brlcad"If there were no digits at all, however, strtol() stores the original value of str in *endptr.
15:56.39starseekerright
15:56.48brlcadokay, I think I see it
15:58.42CIA-53BRL-CAD: 03starseeker * r42894 10/brlcad/trunk/src/libbu/booleanize.c: whoops - val is an int
15:59.07brlcadwhat do you think about bu_true() instead of bu_booleanize() ?
15:59.22brlcadfor readability, if (bu_true(some_string)) ...
15:59.43starseekerit's a bit shorter... does true imply anything that booleanize doesn't? (or vice versa?)
16:00.15starseekerhave expects bu_true to always return true, but that's just a silly reflex
16:00.21starseekers/have/half
16:00.26brlcadthe name bu_booleanize() doesn't imply a truth return value, so it's funky to read and get the logic right
16:00.46brlcadthe mged.c change for example
16:01.09starseekerI'm cool with bu_true
16:01.13brlcadbu_str_true()
16:01.22starseekerah, yeah that's better
16:01.25starseekerlittle more specific
16:04.08CIA-53BRL-CAD: 03starseeker * r42895 10/brlcad/trunk/src/libbu/booleanize.c: Let's stay consistent - long, not int
16:04.18brlcadnamingwise, bu_str_to_rgb() is the only other bu_str_ along with the C wrappers bu_strdup, bu_strcpy, etc
16:05.02starseekerwell, either way
16:05.12starseekerdoesn't have a real strong opinion
16:05.46brlcadbu_str_to_bool() is no better than bu_booleanize()
16:06.13brlcadheh, bu_truthify()
16:06.46brlcadbu_test_whether_string_is_yes()
16:07.00*** join/#brlcad Zaebos (~irc@217.91.127.94)
16:07.10``Erikwhy do I feel like the description needs the phrase "and truthishly" in it
16:07.27CIA-53BRL-CAD: 03starseeker * r42896 10/brlcad/trunk/src/adrt/libtie/tie.c: tie.h includes common.h, so don't need to include it twice - fixes regress common.h inclusion order error.
16:09.16starseekerbrlcad: we still have bio.h in cmd.h - I guess the thing to do is take it out and see what fails on Windows?
16:11.25brlcadsure, though the comment says why it's there
16:11.29brlcadtimeval from windows.h
16:11.31starseekerwas included in 41077... if it does need to be there (and since some guy called brlcad committed it I'm guessing we really do) we should probably special case exempt that in the regression test
16:12.12brlcadso either cmd.h needs the same windows wrapper logic like bio.h has or bio.h has to be included before all instances of cmd.h
16:12.35starseekeror we tweak the regression test...
16:12.49brlcadjust because I committed it does mean it's right.. looks wrong to me :)
16:13.18brlcadhaving to put exceptions usually implies something is wrong
16:14.42starseekermutter... mged has its own cmd.h file, clutters up grep
16:14.49starseekertunes...
16:16.12starseekerwow, cmd.h is popular
16:17.00brlcadto be a self-contained header including what it needs, cmd.h should probably just have the windows.h logic
16:17.11starseekeris doing that now...
16:19.02CIA-53BRL-CAD: 03starseeker * r42897 10/brlcad/trunk/include/cmd.h: grab the relevant part of bio.h's windows.h inclusion logic and put it in cmd.h, rather than including bio.h (should fix regression test failure.
16:21.51CIA-53BRL-CAD: 03brlcad * r42898 10/brlcad/trunk/ (include/bu.h src/libbu/booleanize.c src/mged/mged.c):
16:21.51CIA-53BRL-CAD: rename bu_booleanize() to bu_str_true() which is not only two chars shorter but
16:21.51CIA-53BRL-CAD: reads much better within if-statements. not as cool a name, but hopefully less
16:21.51CIA-53BRL-CAD: prone to logic errors. also add the counterpart bu_str_false() to have a
16:21.52CIA-53BRL-CAD: matching set and for readability.
16:24.13CIA-53BRL-CAD: 03starseeker * r42899 10/brlcad/branches/cmake/ (22 files in 14 dirs): Update cmake branch to trunk r42898 - need to do some manual checking, probably missed a few things earlier when working in both trees at once.
16:42.20CIA-53BRL-CAD: 03starseeker * r42900 10/brlcad/trunk/regress/repository.sh: have repository.sh look in TOPSRC for the INSTALL file too, not just configure.ac.
16:43.55CIA-53BRL-CAD: 03starseeker * r42901 10/brlcad/trunk/INSTALL: blt is no more
16:44.38CIA-53BRL-CAD: 03bob1961 * r42902 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Modified ArcherCore::updateRtControl to call rtcntrl's updateControlPanel instead of configuring -size.
16:45.31CIA-53BRL-CAD: 03starseeker * r42903 10/brlcad/trunk/ (INSTALL configure.ac): It's just tkhtml now
16:47.03CIA-53BRL-CAD: 03bob1961 * r42904 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added code to remember Archer's window size.
16:48.00CIA-53BRL-CAD: 03starseeker * r42905 10/brlcad/trunk/INSTALL: tkimg -> tkpng
16:49.41brlcad``Erik: ah, I see what you're saying about the casts
16:49.52CIA-53BRL-CAD: 03starseeker * r42906 10/brlcad/trunk/configure.ac: remove togl logic from configure.ac altogether - togl CMake logic is succeeding, and it is unlikely we will go back to do autotools version.
16:49.53brlcadyeah, casting a scanf probably isn't safe
16:50.20brlcadprobably need a temp var that can be set to the size_t after the scanf
16:52.00brlcadprinting casts should be fine, scanning casts probably not
16:52.08brlcadreviewing now
16:52.30CIA-53BRL-CAD: 03starseeker * r42907 10/brlcad/trunk/configure.ac: add alias for tktable
16:52.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:54.13CIA-53BRL-CAD: 03starseeker * r42908 10/brlcad/trunk/ (INSTALL configure.ac): add tkpng-build alias
17:01.13brlcadthat alias already exists
17:01.15brlcad"tktable-build"
17:01.23brlcadsee the comment before
17:01.39brlcad(it's not an alias, it's the actual)
17:01.52brlcadsame for tkpng
17:01.57starseekeroh, ok - sorry
17:03.26CIA-53BRL-CAD: 03starseeker * r42909 10/brlcad/trunk/configure.ac: remove unneeded alias lines
17:10.11*** join/#brlcad mafm_ (~mafm@72.Red-83-45-72.dynamicIP.rima-tde.net)
17:17.42CIA-53BRL-CAD: 03starseeker * r42910 10/brlcad/trunk/configure.ac: I imagine there are more of these issues, but it looks like rtgl should be a 'with', not an 'enable' in the build logic.
17:20.05CIA-53BRL-CAD: 03starseeker * r42911 10/brlcad/trunk/INSTALL: remainder of INSTALL documentation options - repository-regress should now succeed.
17:22.29CIA-53BRL-CAD: 03starseeker * r42912 10/brlcad/branches/cmake/ (5 files in 3 dirs): MFC 42911
17:35.50CIA-53BRL-CAD: 03starseeker * r42913 10/brlcad/branches/cmake/regress/CMakeLists.txt: Ah right, DEPENDS can't tell if the target's done anything if it's set up this way - just have regress run 'em all. Regression test fully succeeded.
17:35.52starseekerwoo-hoo!
17:35.56starseekerheads in
17:41.09dlomanIce clearing up?
17:42.31brlcadstarseeker: awesome, thanks for fixing those!
17:46.13brlcad--enable-* turns compilation of things on/off
17:46.26brlcads/things/code/
17:46.53brlcad--with-* turns usage of system components on/off
17:48.02brlcadwith/without X11, OpenGL, Mac Frameworks, particular threading types, etc
17:50.09brlcadenable/disable compiling things in our code like building src/other, compilation modes, subcompiles, etc
17:50.46brlcadanother way to think of it is --enable/--disable => internal   and   --with/--without => external
17:53.31CIA-53BRL-CAD: 03brlcad * r42914 10/brlcad/trunk/configure.ac: rtgl was okay as an --enable flag. enable/disable for inward code selection, with/without for outward system selection.
17:53.50``Erikmmm, pröst coma
17:54.57brlcadmmm
17:55.26brlcadI need to stop coding and get back to studying soon
18:04.43CIA-53BRL-CAD: 03erikgreenwald * r42915 10/brlcad/trunk/bench/pixcmp.c: break help message into two strings to bring it under 509 characters (ISO C90)
18:10.39CIA-53BRL-CAD: 03brlcad * r42916 10/brlcad/trunk/INSTALL: document rtgl and expand the explanation of configuration options to detail what is different between the enable and with options. reword a little for clarity too.
18:11.05CIA-53BRL-CAD: 03brlcad * r42917 10/brlcad/trunk/configure.ac: comment on rtgl option
18:30.29CIA-53BRL-CAD: 03brlcad * r42918 10/brlcad/trunk/src/libged/vdraw.c: scanning into a coerced pointer probably isn't a good idea, so revert back down to unsigned long for the scan and upconvert the comparisons accordingly
18:33.07CIA-53BRL-CAD: 03brlcad * r42919 10/brlcad/trunk/src/libged/wdb_vdraw.c: this duplication of effort really sucks. fix the same size_t uind issues that were in vdraw.c
18:34.50brlcadthat should do it, beginning another round of testing
18:36.16CIA-53BRL-CAD: 03tbrowder2 * r42920 10/brlcad/trunk/HACKING: stick with rough English translation--rest is covered in later parts
18:39.15brlcadmm, crit is full
18:40.05``Erikin /home ? there's some issue with rsync duping things or something
18:40.21brlcadintentional
18:40.27brlcadnot duping, just not deleting
18:40.34brlcadi'm cleaning up some space
18:41.23brlcadeasy enough to clear out the big offenders and let them re-rsync later .. checking usage now
18:51.45dlomananything i did?
18:53.17*** join/#brlcad Ralith (~ralith@d142-058-094-230.wireless.sfu.ca)
18:53.18``Eriknah
18:53.56``Erikstuff like me doing BRL-CAD builds, people collating/cleaning/deleting irc logs on bz and having dups show up on crit, etc
18:54.45``Erikthe way it's set up, if I go on bz and decide to compress every text file in a directory, crit will have both the compressed and uncompressed ones sitting next to eachother
18:57.11CIA-53BRL-CAD: 03brlcad * r42921 10/brlcad/trunk/HACKING:
18:57.11CIA-53BRL-CAD: split the difference. emphasize build breaking and maintainability concern in
18:57.11CIA-53BRL-CAD: the second point as developer mantra. also, add a brief hint to the first point
18:57.11CIA-53BRL-CAD: that it's speaking to people's character and the community, not just the code.
18:58.27epilegis there someone working on the creation of rpm package for fedora?
19:02.52brlcadthere, lots of space
19:03.11brlcad``Erik: big offender was a massive core dump that got syncd :)
19:03.58brlcadthere's 40GB
19:04.01``Erikahhh
19:04.21``Erikthat'd do it
19:05.50``Erikepileg: I think starseeker tried to set up a fedora image to try to get the spec.in up to date, it's not exactly a priority for us unless someone wants to step up and take care of it
19:06.33brlcadepileg: go for it ;)
19:06.57brlcadsh/make_rpm.sh  :D
19:12.59epilegOk, I'll try, but in rpm systems the situation is different than in debian like ones. They share the same packaging system (rpm), but the package nomenclature is different between distributions.
19:14.25epilegso, the fedora rpm package will be only for fedora, and not installable in opensuse
19:14.37``Erikstarseeker: dm-rtgl is chock full of GLX stuff, allowing it to try to build on winderz won't work
19:16.57CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r2454 10/wiki/Community_Publication_Portal: update date, still in draft
19:17.50brlcadepileg: ah, interesting -- didn't know that
19:18.32brlcadthere can be a --fedora or --generic flag to the script for making the other type
19:19.27brlcadright now, there is no rpm generation whatsoever, so it almost goes without saying that anything you do will be an improvement ;)
19:23.09``Erikwell, brlcad.spec.in and just run rpm -someflag on it, iirc, but it needs write access to like /usr/src/redhat/SOURCES/ and stuff, iirc
19:25.33brlcadso the script is probably a one-liner or maybe few-liner with error-checking on environment assumptions
19:25.49brlcadthat's still one line I don't want to memorize :)
19:26.43``Erikyeh, I built it into a make target a long time ago, um, dunno if it still exists in BRL-CAD, but I can dig it up in other old projects (if it's still even pertinent... I think the spec format changed, that's why starseeker was trying to work on it)
19:34.58brlcad*shrug*
19:35.36brlcadI don't think there's anything in brl-cad any more -- if something doesn't get maintained and can't be verified that it works, I generally yank it so it doesn't slow down the next guy
19:48.59``Erikmisc/brlcad.spec.in is there and it's still in the AC_OUTPUT *shrug*
19:50.33CIA-53BRL-CAD: 03brlcad * r42922 10/brlcad/trunk/HACKING: set jordi up as the .deb maintainer
19:50.38brlcadbut no rpm line hooking it in
19:50.45brlcadjust there for those that know what a spec file is
19:51.09``Erikline 159 of /Makefile.am
19:51.16``Erik:D
19:51.48brlcadah, okay very good then
19:51.57brlcadprobably should move that up into the make_rpm.sh script
19:52.17brlcadhm, distcheck is not happy on fbsd
19:52.50brlcadapparently its doing a "make distdir" on something in src/other that doesn't have that rule
19:57.25starseeker``Erik: gaaaahhh.  OK.
19:57.33starseekerrtgl is busted anyway
20:03.41CIA-53BRL-CAD: 03starseeker * r42923 10/brlcad/branches/cmake/CMakeLists.txt: Don't try rtgl unless we've got X11
20:06.16starseekergrrrrr.... now unistd.h and glxext.h are arguing on my Mac
20:07.10starseekermay be time to upgrade this baby
20:10.43brlcad``Erik: soo, guess what
20:10.56brlcadI'm upgrading crit to better hardware :)
20:11.16brlcadthey're going to attach the current hard drive via USB to the new hardware
20:11.21brlcadshould more than double the performance
20:13.12``Erikhah, cool
20:13.30``Erikwonders how many hw iterations the 'new server' will go through before migration O:-)
20:14.09``Erikmight try doing "gmake distcheck" instead of "make distcheck"?
20:14.28``Erikthere're still a couple flakey rough spots between bsdmake and auto*
20:18.18brlcadI'm hoping this motivates me since it's in context now
20:18.30brlcadplus hella faster and bigger
20:18.49brlcadless bandwidth, but even .bz will only consume about 50% on average
20:19.22brlcad1TB disk, dual P4 3.0, 2GB, 100Mbs
20:19.45brlcad500GB transfer cap
20:20.24``Eriknice, enough cpu that the load may drop below the number of cores O.O
20:21.17``Erikand enough memory that it won't be in swapland like bz
20:23.43*** join/#brlcad Ralith (~ralith@d142-058-076-096.wireless.sfu.ca)
20:29.04*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
20:37.01*** join/#brlcad Ralith_ (~ralith@d142-058-076-096.wireless.sfu.ca)
20:46.00CIA-53BRL-CAD: 03starseeker * r42924 10/brlcad/trunk/ (NEWS src/nirt/command.c): Ow. nirt units command was reporting all unit changes as invalid (even 'm') - this seems to fix it, but someone else should verify.
20:46.41CIA-53BRL-CAD: 03starseeker * r42925 10/brlcad/trunk/NEWS: # -> *
20:57.54*** join/#brlcad kanzure (~kanzure@131.252.130.248)
21:08.34CIA-53BRL-CAD: 03bob1961 * r42926 10/brlcad/trunk/src/ (libged/rect.c libtclcad/ged_obj.c): Call dm_draw_rect() only if grs_draw and grs_line width are not zero.
21:22.36brlcadserver transfer under way
21:25.41epilegwho's the maintainer of "misc/brlcad.spec.in"?
21:26.19brlcadepileg: "svn log misc/brlcad.spec.in" will say who all has edited the file
21:26.43epilegthanks
21:27.09brlcadstarseeker: remember that the last comment is the one that will show up in the configuraiton review report
21:29.05brlcadlooks like distcheck and release tests are passing on mac now with only one test needing investigating
21:29.24brlcadfastgen test is reporting "realpath: No such file or directory" several times
21:29.36brlcadfollowed by a Tcl_Init failure
21:30.13starseekerbrlcad: oh, sorry
21:30.32brlcadhttp://pastebin.mozilla.org/1015503
21:31.06CIA-53BRL-CAD: 03starseeker * r42927 10/brlcad/branches/cmake/src/other/step/CMake/SCL_Utils.cmake: Make the SCL install commands more generic
21:31.26brlcad``Erik: 8.1 is no longer pre-release, stable okay?
21:31.48``Erikstable is 8.2RC3 right n ow
21:32.01``Erikonce 8.2 comes out, I'll upgrade the system
21:32.12``Erikso any old 8.x, right? um
21:32.22brlcadcrit is presently 8.1-prerelease
21:32.42``Erikit's running 8.1-prerelease, it has 8.2rc2 installed iirc, I just haven't been rebooting it
21:32.44brlcadyou want 8.2RC3 or 8.1 stable?
21:32.54brlcador doesn't matter
21:32.59``Erikdoesn't matter
21:33.02brlcadk
21:33.28``Erikwe'll upgrade when 8.2 goes stable and lock on that branch for security updates until 8.3 comes out, right?
21:33.39starseekerwould be happy never to have to deal with path logic again...
21:33.45starseekerbrlcad: that's on a 10.6 mac?
21:33.51``Erikhttp://www.freebsd.org/releases/8.2R/schedule.html
21:38.32CIA-53BRL-CAD: 03starseeker * r42928 10/brlcad/trunk/NEWS: nirt units command was reporting all units as invalid - fixed
21:41.36brlcadstarseeker: yes
21:41.58starseekernevermind, I see it here too.
21:42.02starseekerg_diff is failing
21:42.56starseekerthat may be the tclcad_tcl_library() removal
21:44.23starseekerno, wait...
21:44.31starseekermaybe not g_diff...
21:44.47brlcadg_diff probably has its own tcl interpreter
21:45.00brlcadso if a change was made to bwish and mged, might need something there too
21:45.02starseekerit does, but running it in isolation succeeds
21:47.22starseekerah, there we go
21:47.36starseekerrunning it from toplevel dir succeeds, not from regress
21:47.40starseekerdigs...
21:55.00starseekerthat's why...
21:55.05brlcadrealpath blather found/fixed
21:55.10CIA-53BRL-CAD: 03brlcad * r42929 10/brlcad/trunk/src/libbu/brlcad_path.c: there's no need to perror() on realpath failure
21:56.59CIA-53BRL-CAD: 03starseeker * r42930 10/brlcad/trunk/src/gtools/g_diff.c: By the time g_diff was doing Tcl_FindExecutable, argv[0] referred to the first file supplied and not the executable name. Instead, use the 'invoked_as' string
21:57.00starseekerbrlcad: that should do it.
21:57.37starseekerhas to go take cats to vet...
21:57.50CIA-53BRL-CAD: 03brlcad * r42931 10/brlcad/trunk/configure.ac: comment tweak
21:57.55brlcadawesome, thanks!
21:58.13brlcadenjoy your delicious dinner ;)
22:06.22brlcadwell now that's really odd
22:07.07brlcadrunning "../src/gtools/g_diff fastgen_unix.g fastgen_dos.g" stand-alone works, but inside the script with the same pwd it blathers a tcl failure
22:09.46brlcader... someone changed the fastgen regression script
22:10.37brlcadsupposed to create a unix line-ending fastgen conversion, create a dos line-ending fast conversion, and compare the two
22:10.51brlcadit's creating the dos version by simply copying the unix version!
22:11.50epileg@MAJOR_VERSION@, @MINOR_VERSION@ and @PATCH_VERSION@ variables do not change when "misc/brlcad.spec" is created
22:14.10brlcadahh, my bad .. was reading the script wrong .. turning my internal alarm off
22:15.27brlcadepileg: those don't sound like the right variables
22:15.32``Erikhm, not being AC_SUBST'd anymore
22:15.33brlcadprobably out of date
22:15.50epilegaha
22:15.52``Erikprobably switch the version to @BRLCAD_VERSION@ and the release to '1' or something, or take release out
22:16.46epilegyes. where can i find the variable list?
22:18.06``Erikconfigure.ac
22:18.12epilegok, thanks!
22:18.14``Erikgrep AC_SUBST configure.ac
22:31.30CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r2455 10/wiki/Community_Publication_Portal: less is more. be briefer.
22:33.05CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r2456 10/wiki/Community_Publication_Portal: move note down to publication section
22:35.19CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r2457 10/wiki/Community_Publication_Portal: reduce intro further
23:34.44starseekergrowls... worst traffice I think I've ever run into on 22
23:34.50starseekermissed the appointment
23:35.04*** join/#brlcad Ralith (~ralith@d142-058-094-230.wireless.sfu.ca)
23:36.04starseekerbrlcad: it's still failing?  that should have fixed it...
23:47.33CIA-53BRL-CAD: 03starseeker * r42932 10/brlcad/branches/cmake/ (15 files in 9 dirs): MFC r42931
23:50.26CIA-53BRL-CAD: 03starseeker * r42933 10/brlcad/branches/cmake/ (. src/other/step/ src/other/tkhtml/): mergeinfo property is annoying, not using it - remove from cmake branch
IRC log for #brlcad on 20110203

IRC log for #brlcad on 20110203

00:28.45brlcadstarseeker: I just finished a clean recompile to test
00:28.48brlcadit's working
00:29.01brlcadthe problem is running tcl applications without having installed BRL-CAD first
00:29.21brlcadhave to make install BEFORE make test or it'll fail on OS X .. haven't figured out how to fix that yet
00:30.17brlcadit finds the system-installed Tcl at runtime
00:31.37starseekerah
00:32.21starseekeryeah, I'll usually test in CMake if I'm doing a non-installed trial..
00:35.03brlcadit should fail in cmake just the same actually unless they modify the LD paths accordingly
00:36.33starseekerI've got some RPATH settings enabled that seem to do wonders
00:37.24starseekeryou should give it a try sometime :-P
00:40.08brlcadoh, I believe ya -- another plus if they have better rpath management
00:41.12CIA-53BRL-CAD: 03brlcad * r42934 10/brlcad/trunk/m4/patch.m4: (log message trimmed)
00:41.13CIA-53BRL-CAD: sigh, no response from the libtool mailing list on this issue so restore the
00:41.13CIA-53BRL-CAD: hack that makes libtool binary wrapper scripts work on Mac OS X. we sneak in
00:41.13CIA-53BRL-CAD: paths to the Tcl/Tk compile-time lib directories so that they'll get
00:41.13CIA-53BRL-CAD: automatically added to DYLD_LIBRARY_PATH. due to suck in the way temp_rpath is
00:41.13CIA-53BRL-CAD: handled, the trailing ':' is required otherwise the path will get munged with
00:41.14CIA-53BRL-CAD: the next pathlist incorrectly. document why this oddity is even in here, why
00:42.50starseekerbrlcad: about the --enable-only-benchmark option... does that actively squash other options and turn on just what's needed for the benchmark build?
00:43.04starseeker(also, what's the advantage of that over a normal configure and make benchmark?)
00:45.09brlcadit only enables and builds exactly enough to run the benchmark
00:46.06brlcadgreatly shortens the build time (by less than a 10th iirc)
00:46.52brlcadreduces the configure tests and reduces compilation to approximately the minimum
00:47.37starseekerso the configure time is the difference between that and just doing a normal configure + make benchmark?
00:48.55brlcadmake benchmark still builds everything, then runs cd bench && make bench
00:49.15brlcad"everything" for an --enable-only-benchmark build is the bare minimum
00:49.26brlcadmged, asc2g, pixcmp, etc
00:49.26starseekerah.
00:50.00starseekerThe CMake build is set up so that a normal configure + make benchmark will build just what is needed for the benchmark and run it - is this an acceptable alternative?
00:50.13brlcadin theory, with cmake you should be able to describe a new benchmark rule that has the proper minimal dependencies
00:50.22starseekerdid :-)
00:50.29brlcadyep, that's fine
00:50.34starseekersweet
00:51.12brlcadthe only difference is probably that "make install" would only install the benchmark too :)
00:51.19``Erikless than 1/10th... before opennurbs? :)
00:51.54brlcadheh, don't know
00:52.13starseekeris betting yes - librt needs opennurbs, which is a large percentage of time
00:52.40brlcadstill gets to avoid step dir, half of src/other, hundreds of other utils
00:52.58starseekertrue
00:53.00``Erikum, it blindly does src/conv which has the step stuff, right?
00:53.13brlcaddon't recall
00:53.18brlcadit might
00:53.33starseekerwell, make benchmark is pretty quick in CMake - that does avoid step
00:53.44starseekerbut there's no escaping opennurbs :-P
00:53.57brlcadeasy enough for someone to test the difference if it mattered
00:54.20brlcadstarseeker: you have rough idea of how long a full build and benchmark-only build take?
00:57.32starseekerwith cmake or autotools?
00:57.55starseekeralso, benchmark skips all the static libs which makes a big difference
00:58.21brlcadeither
00:58.23brlcadboth
00:58.29brlcad<PROTECTED>
00:58.29brlcad<PROTECTED>
00:58.52brlcadouch.. that's a sad v4 flip case
00:59.18brlcad1 plithy object that failed to validate whether flipped or not causing trouble for everything else
00:59.24starseekerbrlcad: let me do some tests...
00:59.31starseekerouch
00:59.43starseekerthat reminds me - does the flip routine handle ars primitives?
01:00.02brlcadI talked to D, that's what I'm looking into
01:01.09starseekerah, cool
01:03.02*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
01:14.14starseekerCMake make -j3 benchmark, from beginning to start of actually running the benchmarks, not including configure time - ~2 minutes, maybe a bit less
01:18.33starseekerhmm - pulled in libpc on autotools...
01:20.57starseekerlittle over 4 minutes for the same thing with autotools
01:21.24starseekerappears it did not pull in step in either case
01:22.04starseekerboth of those times used system libs instead of building local copies
01:32.46brlcadstarseeker: technically, librt needs libpc
01:33.13starseeker8.5 minutes for an autotools build, no docbook
01:33.44brlcadfull cmake build takes how long?
01:33.44starseekerbrlcad: ah - I haven't set up that dependency in CMake yet - not a problem, just haven't done so yet
01:33.51starseekertrying that next
01:34.00starseeker(usually leave docbook on, messes with numbers)
01:34.10brlcadsure
01:34.57CIA-53BRL-CAD: 03brlcad * r42935 10/brlcad/trunk/regress/fastgen.sh: add diagnostic 'command prompts' to let you know what the important steps being taken are
01:36.06starseekeragain, using system libs for all builds (not enable-all)
01:36.20*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
01:43.34starseekerabout 6.5 minutes for the cmake build
01:45.15starseekerso about half the time for a benchmark build (once I throw libpc into the CMake build)
01:46.02starseekermaybe a bit less
01:46.35starseekeractually, the autotools build reports exact time - 8 min, 33 seconds
01:46.49starseekerlooks at CMake build...
01:56.02starseekerah right, only got it going for configure...
01:59.05brlcadyou don't calculate compilation time?! :)
02:02.26brlcadperhaps ironic, but I actually think cleanly and clearly reporting build time is very important for a variety of reasons
02:03.55brlcadpassive vs active metrics, interface feedback, completion confirmation
02:11.28starseekerbrlcad: it's a little tricky... working on it now
02:28.22*** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net)
02:29.43CIA-53BRL-CAD: 03brlcad * r42936 10/brlcad/trunk/include/raytrace.h: note the three unused debug bits remaining
02:34.31CIA-53BRL-CAD: 03brlcad * r42937 10/brlcad/trunk/src/lgt/lgt.h: lgt should not replicate raytrace.h debug values
02:35.42CIA-53BRL-CAD: 03brlcad * r42938 10/brlcad/trunk/ (include/raytrace.h src/librt/cut.c src/librt/prep.c): rename DEBUG_PLOTSOLIDS and DEBUG_PLOTBOX to DEBUG_PL_SOLIDS and DEBUG_PL_BOX respectively just because it's 1-char shorter and matches nmg.h
02:51.56CIA-53BRL-CAD: 03brlcad * r42939 10/brlcad/trunk/src/librt/ (db_corrupt.c librt.3): (log message trimmed)
02:51.56CIA-53BRL-CAD: the user needs SOME mechansim to override automatic behavior in case there is
02:51.56CIA-53BRL-CAD: some pressing need, so provide for a LIBRT_V4FLIP boolean environment variable.
02:51.56CIA-53BRL-CAD: if set, the value will be interpreted as an override to enable or disable
02:51.56CIA-53BRL-CAD: flipping so you can flip a file irrespective of the automatic detection.
02:51.56CIA-53BRL-CAD: setting the flag to false will revert to old behavior. setting to true will
02:51.57CIA-53BRL-CAD: flip even if the application provided no override and automatic detection would
02:54.39CIA-53BRL-CAD: 03starseeker * r42940 10/brlcad/branches/cmake/CMakeLists.txt: Remove the benchmark and rtserver-only options - benchmark is handled by proper dependencies for make benchmark. rtserver will also build minimally due to dependencies.
03:11.09CIA-53BRL-CAD: 03starseeker * r42941 10/brlcad/branches/cmake/src/CMakeLists.txt: Without the build options for benchmark and framework, the src/CMakeLists.txt logic simplifies down nicely
03:13.58CIA-53BRL-CAD: 03starseeker * r42942 10/brlcad/branches/cmake/ (4 files in 2 dirs):
03:13.58CIA-53BRL-CAD: Add a mechanism to print out the compilation time for CMake build. Works only
03:13.58CIA-53BRL-CAD: for make (e.g. make all) which appears to be consistent with autotools. Summary
03:13.58CIA-53BRL-CAD: information isn't as elaborate as the autotools output, but that can be added if
03:13.58CIA-53BRL-CAD: it's needed.
03:14.07starseekerbrlcad: there we go
03:48.56brlcadexample output?
03:49.25brlcadomg, this is delicious ..
03:49.42brlcadspam musubi
03:49.53brlcad"hawaiian sushi"
04:17.06CIA-53BRL-CAD: 03brlcad * r42943 10/brlcad/trunk/configure.ac: still having woes with debugging, perhaps the flip was to gstabs+ for 10.4+?
04:52.44*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
05:21.34*** join/#brlcad Stattrav (~Stattrav@122.172.33.253)
05:21.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:51.29CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r2458 10/wiki/Backstaff: backstaff beginnings
06:58.41CIA-53BRL-CAD: 03brlcad * r42944 10/brlcad/trunk/src/librt/db_open.c: past tense on endianness flippage
07:03.35CIA-53BRL-CAD: 03brlcad * r42945 10/brlcad/trunk/src/librt/db_corrupt.c:
07:03.35CIA-53BRL-CAD: be a lot more eager to flip the endian interpretation of v4 files now that
07:03.35CIA-53BRL-CAD: there's an environment variable override. if we merely detect that it'll help a
07:03.35CIA-53BRL-CAD: majority of objects, let the flip occur. Moreover, report all objects
07:03.35CIA-53BRL-CAD: containing matrices that are invalid regardless of flipping since they may just
07:03.35CIA-53BRL-CAD: actually be invalid. summarize how many objects are like that.
07:13.07CIA-53BRL-CAD: 03brlcad * r42946 10/brlcad/trunk/TODO: confirmed that ARS has a problem importing because it manages its own b-record serialization of dbfloat_t data. looks like old POLY objects will have a similar problem too. opendb is now fixed.
07:18.59CIA-53BRL-CAD: 03brlcad * r42947 10/brlcad/trunk/src/librt/primitives/ars/ars.c: there is no reason for rt_ars_rd_curve() to be public api. rename sans rt_ prefix and mark HIDDEN.
07:30.54CIA-53BRL-CAD: 03brlcad * r42948 10/brlcad/trunk/include/db.h: B_solid records don't actually seem to be used anywhere anymore. should be safe to remove from the union.
07:36.57CIA-53BRL-CAD: 03brlcad * r42949 10/brlcad/trunk/include/db.h: apparently not true. nothing refers to struct B_solid, but the bspline primitive does refer to and use the B union record. revert.
07:41.20CIA-53BRL-CAD: 03brlcad * r42950 10/brlcad/trunk/include/db.h: rename the B_resolution confusion starting point as it doesn't look to be actually used (at least by bspline). update comment and name, however, instead of changing the struct size just in case that matters.
07:43.41CIA-53BRL-CAD: 03brlcad * r42951 10/brlcad/trunk/TODO: that means bsplines won't auto-flip either
08:01.54*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
08:14.51*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:22.05d_rossbergstarseeker: because of the CMake build: i set BRLCAD_PREFIX to something (in the GUI) but "Prefix:" is empty in the configuration summary
09:07.17*** join/#brlcad mafm_ (~mafm@193.153.53.189)
13:06.05*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:21.28starseekerd_rossberg: you shouldn't need to use BRLCAD_PREFIX for anything anymore
13:21.44starseekerCMAKE_INSTALL_PREFIX should be respected now
13:27.03starseekerbrlcad: http://pastebin.mozilla.org/1018272
13:27.09starseekervery simple right now
13:27.43d_rossbergthere is no CMAKE_INSTALL_PREFIX declared, i can't access it via the CMake GUI
13:28.03starseekerum
13:28.11starseekerthis is on Windows?
13:29.58starseekerupdates his copy on windows to the latest...
13:30.31CIA-53BRL-CAD: 03d_rossberg * r42952 10/brlcad/trunk/include/common.h: there are unused parameters which are asserted
13:30.45d_rossbergthe cmake gui should be similar on all systems
13:31.08starseekeryes, it should
13:31.28starseekerbut there is conditional logic for path setup
13:31.49starseekeris checking
13:32.05starseekerI usually run from the command line, so it's possible I missed something
13:32.45d_rossbergfollowing my documentation CMAKE_INSTALL_PREFIX isn't a standard variable but CMAKE_ROOT is
13:35.28starseekeruh... http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_INSTALL_PREFIX
13:36.11starseekeram I missing something?
13:36.58starseekerI'm seeing CMAKE_INSTALL_PREFIX as the last entry in my gui here
13:40.54CIA-53BRL-CAD: 03d_rossberg * r42953 10/brlcad/trunk/src/conv/asc/g2asc.c:
13:40.54CIA-53BRL-CAD: B_resolution (now B_unused) seams to be unused
13:40.54CIA-53BRL-CAD: removed it
13:44.13d_rossbergi'm removing all my cache, build etc. files ...
13:44.50starseekeris trying on Windows to see if CMAKE_INSTALL_PREFIX perhaps isn't coming up there
13:49.31*** join/#brlcad mafm_ (~mafm@193.153.53.189)
13:50.40CIA-53BRL-CAD: 03d_rossberg * r42954 10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: removed disappeared function
13:54.04starseekerCMAKE_INSTALL_PREFIX is visible in my Windows setup too
13:57.58d_rossbergnow here too, it was probable a problem with an outdated configuration
14:00.36starseekernods. Yeah, a lot has changed over the past week
14:01.23``Erikbrlcad: did you take crit offline?
14:04.09CIA-53BRL-CAD: 03starseeker * r42955 10/brlcad/trunk/src/conv/asc/g2asc.c: fix formatting string
14:10.21CIA-53BRL-CAD: 03erikgreenwald * r42956 10/brlcad/trunk/TODO: The 'freebsd' (actually NDEBUG) strict issues are fixed. The metaball "shelling" bug is, as well.
14:35.17CIA-53BRL-CAD: 03starseeker * r42957 10/brlcad/branches/cmake/misc/CMake/BRLCAD_Util.cmake: Don't assume -Wno-error will always work, check for it first
14:57.31CIA-53BRL-CAD: 03starseeker * r42958 10/brlcad/trunk/src/liboptical/sh_toyota.c: Hmm - gamma shadows something in math.h on OSX 10.5, apparently...
15:00.23CIA-53BRL-CAD: 03starseeker * r42959 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: These ARE used, at least on Windows...
15:04.54CIA-53BRL-CAD: 03starseeker * r42960 10/brlcad/branches/cmake/ (18 files in 11 dirs): MFC r42959
15:35.45CIA-53BRL-CAD: 03starseeker * r42961 10/brlcad/branches/cmake/src/util/CMakeLists.txt: Can't do libpc on MSVC yet, so can't very well test it...
15:44.05d_rossbergstarseeker * r42955: ups :{
15:44.21starseekernp, happens
15:53.10brlcad``Erik: nope, they did
15:53.19brlcadnew server is now online
15:54.07brlcadmounting the drive and working on restoring passwd
15:54.14``Erikaight
15:54.27brlcadnew IP
15:59.54``Erikgoing to give it a new name and remove the old one, or update?
16:08.04CIA-53BRL-CAD: 03bob1961 * r42962 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Remember whether or not to show things like the view axes, model axes, view params, scale etc.
16:10.46brlcadyes :)
16:11.15brlcadjust got the drives mounted
16:11.25brlcadletting /home copy now
16:26.05*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
16:55.42CIA-53BRL-CAD: 03brlcad * r42963 10/brlcad/trunk/src/librt/primitives/ars/ars.c: this brings the ARS online with automatic v4 detection, though not a final solution since htons() will do nothing on other endian.
18:11.59CIA-53BRL-CAD: 03starseeker * r42964 10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Do a better job of generalizing the exec search options
18:14.33CIA-53BRL-CAD: 03starseeker * r42965 10/brlcad/branches/cmake/ (misc/CMake/FindTCL.cmake src/other/togl/CMake/FindTCL.cmake): ws, update togl copy of FindTCL.cmake
18:17.04``Erikstarseeker: that did the trick
18:17.21starseekercool
18:17.26starseekeris building now
18:32.07``Erikhm, more failures on fbsd, linux, and osX.6
18:32.23``Erik'src/other/tcl/unix/tclUnixPort.h:91:5: error: "TIME_WITH_SYS_TIME" is not defined' seems common
18:32.38starseekerCMake build or autotools?
18:32.51``Erikcmkae
18:48.19``Erikweeee, osX.6 GL.h has // style comments, so ogl fb craps itself with strict flags
18:48.28``Erik/System/Library/Frameworks/OpenGL.framework/Headers/gl.h:37:1: error: C++ style comments are not allowed in ISO C90
19:06.20CIA-53BRL-CAD: 03brlcad * r42966 10/brlcad/trunk/src/libbu/xdr.c: group pairings together. makes it more obvious that bu_glonglong() was never implemented (though there is a macro) but doesn't matter since this is all getting deprecated.
19:06.40CIA-53BRL-CAD: 03starseeker * r42967 10/brlcad/branches/cmake/misc/CMake/FindGL.cmake: We're not doing aqua based GL in these searches, so let's stay out of the opt/graphics directory and try /usr/X11
19:10.16CIA-53BRL-CAD: 03brlcad * r42968 10/brlcad/trunk/ (doc/deprecation.txt include/bu.h): deprecate the old eXternal Data Representation (xdr) API. the byteorder libc functions became IEEE Std POSIX.1-200x (with the exception of the long long pairing?) so set up the migration path.
19:14.14CIA-53BRL-CAD: 03brlcad * r42969 10/brlcad/trunk/src/librt/primitives/ars/ars.c: note the problem
19:15.38brlcad``Erik: yeah, that sucks
19:16.11brlcadwhere are you seeing it?
19:16.29brlcadI updated all of the places that gl.h gets included with ${STD_C99_FLAGS}
19:16.57brlcadthat should squash that error
19:17.10brlcadlibfb, libdm, and I think mged already have it
19:20.31brlcadahh, if you're testing cmake build -- starseeker, you'll have to add similar logic
19:21.32brlcadyou could actually just set c99 project-wide for cmake build since I'm close to doing that for autotools -- was waiting to squash the few remaining warnings after this release
19:24.01``ErikosX.6 using cmake, grabbing OpenGL.framework instead of /usr/X11R6/include/GL
19:24.58``Erikalways amusing hearing starseeker use words you never think he'd use :>
19:28.25CIA-53BRL-CAD: 03starseeker * r42970 10/brlcad/branches/cmake/misc/CMake/FindGL.cmake: Try the CMAKE_FIND_FRAMEWORK variable in FindGL
19:47.17``Erikbrlcad: using htons in ars.c will require winderz to link winsock.dll to librt
19:47.41``Erikand include Winsock2.h apparently
20:05.45CIA-53BRL-CAD: 03starseeker * r42971 10/brlcad/branches/cmake/misc/CMake/FindTCL.cmake: Need to reset variables if results aren't valid
20:08.50``Erik(and arpa/inet.h on *nix)
20:26.52starseeker``Erik: here's why it's crashing:  0x00000001004ea2bb in _X11TransWritev ()
20:29.09starseekerah, there's no escape - /usr/X11R6/include/GL/gl.h includes the framework gl.h
20:31.06starseekerthat's trying to display mac to mac
20:31.20starseekermac to Linux, wish itself gives up with a bad atom
20:40.35brlcad``Erik: that htons is not going to stay there
20:40.59brlcadworking on replacing that with something that'll actually work on big endian systems
20:44.22CIA-53BRL-CAD: 03brlcad * r42972 10/brlcad/trunk/src/librt/primitives/ars/ars.c: switch over to the xdr functions while the FIXME is being fixed so that we don't have windows build fail. don't want to hook up winsock for windows.
21:14.08starseeker``Erik: odd... runs on Windows for me here (VC++2010)
21:32.50brlcad``Erik: loads of reallocated sectors on the old filesystem .. apparently a bad or failing drive?
21:32.58brlcadthey're attempting a clone/recovery now
21:33.38brlcadit stalled hard 22GB into the restore earlier today and had to go diagnosing
21:43.07``Erikold fs? on crit or bz? bz was falling apart hardcore
21:43.08``Erikis
21:43.17CIA-53BRL-CAD: 03erikgreenwald * r42973 10/brlcad/branches/cmake/src/other/tcl/ (5 files in 2 dirs): regex.h -> regextcl.h to avoid fighting with /usr/include/regex.h
22:09.59CIA-53BRL-CAD: 03brlcad * r42974 10/brlcad/trunk/src/libbu/convert.c:
22:09.59CIA-53BRL-CAD: address FIXME, make cv() be public API, so rename to bu_cv(). provides a
22:09.59CIA-53BRL-CAD: simplified API means for converting between two specified formats, e.g. htons()
22:09.59CIA-53BRL-CAD: would be something like bu_cv(outbuf, "nss", sizeof(short), val, "hss", 1);
22:10.17CIA-53BRL-CAD: 03brlcad * r42975 10/brlcad/trunk/include/bu.h: expose the new bu_cv() function.
22:15.30*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
22:27.33CIA-53BRL-CAD: 03brlcad * r42976 10/brlcad/trunk/src/libbu/convert.c: no longer vert.c
22:39.42CIA-53BRL-CAD: 03starseeker * r42977 10/brlcad/branches/cmake/src/other/togl/src/CMakeLists.txt: Install the headers as well
22:45.30*** join/#brlcad mafm_ (~mafm@203.Red-88-22-160.staticIP.rima-tde.net)
23:04.38CIA-53BRL-CAD: 03brlcad * r42978 10/brlcad/trunk/src/librt/db_float.c: implement a simple flip_short() routine for flipping the bytes of a short. htons() isn't suitable because it won't flip bytes if host endain is network (i.e. big endian). this is private API.
23:05.44CIA-53BRL-CAD: 03brlcad * r42979 10/brlcad/trunk/src/librt/ (Makefile.am librt_private.h): add a new private header, librt_private.h, so we can have a common header for providing functions that can be used within librt but that shouldn't be public API.
23:09.04CIA-53BRL-CAD: 03brlcad * r42980 10/brlcad/trunk/src/librt/db_float.c: prepare for a rename to db_flip.c
23:10.50CIA-53BRL-CAD: 03brlcad * r42981 10/brlcad/trunk/ (5 files in 2 dirs): rename from db_float.c to db_flip.c since the file is being expanded with a few more flip functions that have nothing to do with floats
23:16.41*** join/#brlcad PrezKennedy (MK@whitecalf.net)
23:25.34CIA-53BRL-CAD: 03starseeker * r42982 10/brlcad/branches/cmake/src/other/togl/ (12 files in 5 dirs): Let's see if glew can handle some of the cross platform annoyances
23:28.51CIA-53BRL-CAD: 03starseeker * r42983 10/brlcad/branches/cmake/CMakeLists.txt: Turn Tk X11 requirement on if appropriate
23:41.43starseeker``Erik: hmm:  http://www.geodynamics.org/pipermail/cig-commits/2010-March/011594.html
23:52.19starseeker``Erik: here's a backtrace, if that helps:  http://pastebin.mozilla.org/1020171
23:57.06CIA-53BRL-CAD: 03brlcad * r42984 10/brlcad/trunk/src/librt/primitives/ars/ars.c:
23:57.06CIA-53BRL-CAD: this should fix interpretation for both big and little endian platforms. if
23:57.06CIA-53BRL-CAD: flipping is requested, we need to flip the bytes regardless of host/network
23:57.06CIA-53BRL-CAD: endianness. call the new private flip_short() function from db_flip.c
IRC log for #brlcad on 20110204

IRC log for #brlcad on 20110204

00:12.54CIA-53BRL-CAD: 03starseeker * r42985 10/brlcad/branches/cmake/ (CMakeLists.txt src/libbu/brlcad_path.c src/libbu/simd.c): Turn on C99 for CMake, plus two related tweaks
00:16.12brlcadbrlcad_path.c fix isn't right
00:17.34CIA-53BRL-CAD: 03brlcad * r42986 10/brlcad/trunk/src/libbu/brlcad_path.c: convert to an integer expression
00:20.50CIA-53BRL-CAD: 03starseeker * r42987 10/brlcad/branches/cmake/src/libbu/brlcad_path.c: Grab proper fix for brlcad_path from trunk
00:20.56starseekermy this is depressing: http://yro.slashdot.org/story/11/02/03/2044211/NC-Official-Sics-License-Police-On-Computer-Scientist-For-Too-Good-a-Complaint
00:33.50brlcadheh, and someone naturally posts his phone number, e-mail, and web link to a complaint form.  outstanding smack back expected.
01:13.04CIA-53BRL-CAD: 03jordisayol * r42988 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh):
01:13.04CIA-53BRL-CAD: added the option to create Fedora binary rpm files
01:13.04CIA-53BRL-CAD: minor changes on deb creation
01:14.17CIA-53BRL-CAD: 03starseeker * r42989 10/brlcad/branches/cmake/CMakeLists.txt: Not ready for C99 yet - variety of failures on Linux. Will need to rework this to apply C99 only to C files of BRL-CAD targets.
01:27.33CIA-53BRL-CAD: 03brlcad * r42990 10/brlcad/trunk/src/librt/librt_private.h: make the header safe for c++ compilation units too
01:30.12CIA-53BRL-CAD: 03brlcad * r42991 10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: add support for importing binary-incompatible v4 bspline objects. this flips all short record data values but still leaves the trailing dbfloat arrays that have no record id.
02:16.32CIA-53BRL-CAD: 03brlcad * r42992 10/brlcad/trunk/src/librt/ (db_flip.c librt_private.h): const on an intrinsic value is meaningless
02:29.24CIA-53BRL-CAD: 03brlcad * r42993 10/brlcad/trunk/src/librt/ (db_flip.c librt_private.h): implement flipping of single dbfloats (similar to rt_fastf_float but that one assumes triplets)
02:30.00CIA-53BRL-CAD: 03brlcad * r42994 10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: flip the first of two data arrays that trail after a bspline surface record
02:55.25CIA-53BRL-CAD: 03brlcad * r42995 10/brlcad/trunk/src/librt/db_flip.c: utilize flip_dbfloat() within to reduce the other functions substantially
03:21.27starseekerblinks - in if_ogl.c with C99, ipc.h is asking for either _SVID_SOURCE or _XOPEN_SOURCE
03:21.43starseekeralso, error: implicit declaration of function ‘getpagesize’
03:22.08starseeker(have to check if they're CMake problems, I suppose...)
05:12.03brlcadhttp://www.ehow.com/how_7870235_build-blueprint-software.html
05:12.17brlcadthat is just fscking ridiculous funny
05:12.37brlcadjust whip up some pseudocode, that's all it takes
05:33.22CIA-53BRL-CAD: 03brlcad * r42996 10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: and with this, bspline conversion should be complete. untested, though, because I don't have a sample corrupt v4 with a bspline.
05:55.14CIA-53BRL-CAD: 03brlcad * r42997 10/brlcad/trunk/src/librt/primitives/ehy/ehy.c: fix comment
06:23.05CIA-53BRL-CAD: 03brlcad * r42998 10/brlcad/trunk/src/librt/primitives/ehy/ehy.c: looks like a few other rarely used primitives might need some help too. more v4 conversion support sans testing due to lack of sample geometry.
06:29.10CIA-53BRL-CAD: 03brlcad * r42999 10/brlcad/trunk/src/librt/primitives/epa/epa.c: v4 conversion support for epa
06:33.14CIA-53BRL-CAD: 03brlcad * r43000 10/brlcad/trunk/src/librt/primitives/eto/eto.c: v4 conversion support for eto
06:37.16CIA-53BRL-CAD: 03brlcad * r43001 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: fix copy-paste typo
06:39.13CIA-53BRL-CAD: 03brlcad * r43002 10/brlcad/trunk/src/librt/primitives/rhc/rhc.c: v4 conversion support for rhc
06:39.58CIA-53BRL-CAD: 03brlcad * r43003 10/brlcad/trunk/TODO: down to just poly
06:42.27CIA-53BRL-CAD: 03brlcad * r43004 10/brlcad/trunk/src/librt/primitives/rpc/rpc.c: v4 conversion support for rpc
06:44.11CIA-53BRL-CAD: 03brlcad * r43005 10/brlcad/trunk/src/librt/primitives/sph/sph.c: remove dead code
06:45.39CIA-53BRL-CAD: 03brlcad * r43006 10/brlcad/trunk/src/librt/primitives/submodel/submodel.c: more dead code
06:48.24CIA-53BRL-CAD: 03brlcad * r43007 10/brlcad/trunk/src/librt/primitives/superell/superell.c: not bloody likely there are any v4 super ellipsoids, but go ahead and fix the two parameters that weren't being serialized properly anyways
07:00.24CIA-53BRL-CAD: 03brlcad * r43008 10/brlcad/trunk/src/librt/primitives/poly/poly.c: aaaand, this should be the last solid. add support for v4 conversion of polysolids
07:02.45CIA-53BRL-CAD: 03brlcad * r43009 10/brlcad/trunk/src/librt/primitives/ (ars/ars.c bspline/bspline.cpp ehy/ehy.c epa/epa.c): didn't catch this until part-way through. private headers should be relative references (src/librt should not be on search path).
07:06.39CIA-53BRL-CAD: 03brlcad * r43010 10/brlcad/trunk/TODO: should be good to go! beginnning final round of distchecking and testing.
07:12.27CIA-53BRL-CAD: 03brlcad * r43011 10/brlcad/trunk/src/librt/comb/db_comb.c: fix region ids, air codes, material ids, and line of sight values so they'll open via corrupt v4 flippage too
07:13.21*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
07:16.45CIA-53BRL-CAD: 03brlcad * r43012 10/brlcad/trunk/src/librt/db_scan.c: material records have high/low shorts that need to be accounted for
07:51.10*** join/#brlcad yukonbob1 (~bch@20-144.wireless.kamloops.net)
08:30.31*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
10:35.34*** join/#brlcad ibot (ibot@rikers.org)
10:35.34*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
11:00.32*** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net)
12:37.20*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:03.07starseekerd_rossberg: on what platform?  They should turn on by default if not detected
13:13.26*** join/#brlcad PrezKennedy (MK@whitecalf.net)
13:40.01starseekerd_rossberg: what variable specifically are you looking for?
13:54.55CIA-53BRL-CAD: 03brlcad * r43013 10/brlcad/trunk/src/librt/comb/db_comb.c: missing header
15:59.59*** join/#brlcad ibot (ibot@rikers.org)
15:59.59*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
16:28.32CIA-53BRL-CAD: 03jordisayol * r43021 10/brlcad/trunk/ (5 files in 2 dirs): update desktop on install/remove scripts. changes deb/rpm description
17:31.28epilegI've created and uploaded 2 tested Fedora rpm packages at:
17:31.28epileghttp://code.google.com/p/brl-cad-packages/downloads/list
17:31.28epilegYou can to upload to sourceforge, if You want.
18:21.29*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
18:36.50CIA-53BRL-CAD: 03brlcad * r43022 10/brlcad/trunk/misc/debian/ (brlcad.postinst brlcad.postrm brlcad.sh): use text/x-sh instead of application/x-shellscript for shell script mime types so that subversion will calculate text diffs
18:37.26brlcadepileg: awesome
18:37.54brlcadepileg: try to use text/* mime types when you add new files if they're text files, otherwise they'll get processed as binary files
18:38.12brlcadtext/plain  text/xml  text/x-sh  all pretty common
18:38.56brlcadthere's no utility in setting a binary mime-type; especially if it's something readable by a text editor
19:07.29epilegsorry, just i add the exactly same mime type that linux report
19:07.37epilegdid you correct this?
19:08.12epileghmmmm, yes...... :-/
19:24.03CIA-53BRL-CAD: 03brlcad * r43023 10/brlcad/trunk/src/ (librt/db_open.c mged/mged.c): let the user know that the database was intentionally converted to read-only. not a permissions issue. mixed encoding would be very bad.
19:25.22*** join/#brlcad PrezKennedy (MK@whitecalf.net)
19:45.15CIA-53BRL-CAD: 03brlcad * r43024 10/brlcad/trunk/include/ged.h: add some rather old high-level whiteboard data structure notes on a simple organization for libged.
19:45.36brlcadepileg: yeah, I realize that -- not a problem, just not a useful mime type for revision control
19:47.15epilegwell, there are some other binary mime type files that are really text, from my other day commit
19:47.24epilegI'll check all of them
19:49.23CIA-53BRL-CAD: 03davidloman * r43025 10/rt^3/trunk/tests/GS/GeometryServiceTest.cxx: More remnants of work that are attempts in getting the test harness working with the gs libs.
19:52.30*** join/#brlcad mafm (~mafm@115.Red-81-32-105.dynamicIP.rima-tde.net)
20:00.53*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
20:30.32CIA-53BRL-CAD: 03bob1961 * r43026 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added an fbclear command.
20:59.38``Erikhttp://www.youtube.com/watch?v=67tNwTtH0qE
21:00.10epileg``Erik: can You help me please?
21:12.17epilegI've a problem, I try to upload two new rpm files to sourceforge, but my firefox frozen during the process, and now the files are downloadable but with less than HALF size!!!
21:12.53epileghow do I proceed?
21:26.06``Erikcan you delete them?
21:28.07epilegYes, i can, but brlcad tell me that Is almost forbidden to delete files, and now I do not  now what to do.
21:28.34``Erika partial upload would need to be deleted and re-uploaded
21:29.09epilegAre You sure that this is the correct procedure?
21:30.34``Erikreasonably
21:31.12epilegI'm a bit stressed right now, and I don't wan to make something wrong. Hope You understand me
21:31.52``Erikyeh, I getcha, I'd delete them but I'm having some computer issues at the moment
21:32.11``Erikif you have a pointy stick, you can jab brlcad until he helps? :D
21:33.30epilegok, answer from Sean, I can delete them. puffffff
21:35.57epilegthank a lot ``Erik ;-)
21:40.45CIA-53BRL-CAD: 03erikgreenwald * r43027 10/brlcad/trunk/src/bwish/main.c: verify the ::itcl namespace exists before trying to delete it.
22:06.24CIA-53BRL-CAD: 03erikgreenwald * r43028 10/brlcad/trunk/src/libfb/if_ogl.c: __BSD_VISIBLE has to be before sys/types.h
22:15.08starseeker``Erik: nice
22:19.55CIA-53BRL-CAD: 03erikgreenwald * r43029 10/brlcad/trunk/src/mged/setup.c: verify the ::itcl namespace exists before trying to delete it.
22:22.53``Erikhm, archer issues, but ah surpose that can wait
22:23.00starseekerit's possible that the package require failure is nicer about cleanup than the old C call to Itcl
22:23.07starseeker``Erik: what issues?
22:24.12``Erikhttp://paste.lisp.org/display/119385
22:24.37``Erikon fbsd, installed to /usr/brlcad/HEAD with ln -s /usr/brlcad/HEAD/* /usr/brlcad/
22:25.01starseekerhmmm
22:25.12starseekerCMake or trunk?
22:26.37``Eriktrunk
22:26.44starseekersounds like it's not finding the archer tcl scripts
22:27.02``Erikyeah, there was a dialog that said unable to find plugins or something
22:27.03starseekerhopes like heck it's not yet another bu_brlcad_data problem...
22:27.20``Erik*shrug* time to head home, though... hasta
22:27.25starseekerlater
22:32.34CIA-53BRL-CAD: 03starseeker * r43030 10/brlcad/branches/cmake/ (14 files in 9 dirs): MFC 43029
23:31.47*** join/#brlcad ibot (ibot@rikers.org)
23:31.47*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
IRC log for #brlcad on 20110205

IRC log for #brlcad on 20110205

01:04.13CIA-53BRL-CAD: 03starseeker * r43031 10/brlcad/branches/cmake/misc/CMake/test_srcs/builddelta_end.c.in: Eh, why not. Make the CMake build summary match the autotools printout.
01:44.55starseekerbrlcad: there is a bit of a philosophical issue with CPack vs the dist logic - CPack just packs whatever is in the source tree into the source tarball, except for what you tell it to exclude.  The autotools build lists every file that is supposed to be included
01:45.41starseekerto me, this looks like a consequence of autotools not doing a fully clean out-of-directory build, or rather allowing an in-source-tree build that also generates a clean tarball
01:46.57starseekerwouldn't it be cleaner to just go with the separate build directory and allow the source tarball generation to just pack the source tree?
05:53.10*** join/#brlcad ibot (ibot@rikers.org)
05:53.10*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
08:52.30*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
09:51.57*** join/#brlcad mafm (~mafm@85.Red-83-38-35.dynamicIP.rima-tde.net)
12:26.22*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:58.56CIA-53BRL-CAD: 03starseeker * r43036 10/brlcad/branches/cmake/bench/CMakeLists.txt: Tack on 'how to clean' message to benchmark output
15:07.41CIA-53BRL-CAD: 03starseeker * r43037 10/brlcad/branches/cmake/CMakeLists.txt: Try adding the benchmark to distcheck
15:21.19starseekeroh, I see now... files added to the repository but not added to the build logic...
15:21.23starseekerhrm
15:25.34CIA-53BRL-CAD: 03starseeker * r43038 10/brlcad/branches/cmake/CMakeLists.txt: Whoops, tell it to run
15:26.27starseekeraccidents like new .tcl scripts not being copied, that logic avoids those issues...
15:26.35starseekerho boy
15:26.39starseekerstarts thinking
16:42.25*** join/#brlcad WhiteCalf (~MK@whitecalf.net)
22:59.42*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20110206

IRC log for #brlcad on 20110206

01:21.50*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
04:01.39*** join/#brlcad DX^ (~DX@c-71-59-50-121.hsd1.ga.comcast.net)
04:37.33*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
14:40.01*** join/#brlcad Elrohir (~kvirc@p5B149628.dip.t-dialin.net)
14:48.52CIA-53BRL-CAD: 03starseeker * r43039 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/distcheck_buildsys.cmake.in):
14:48.53CIA-53BRL-CAD: First steps towards a comprehensive system to check for files missing from the
14:48.53CIA-53BRL-CAD: build logic. Still quite a lot to do here, and even when the system is fully in
14:48.53CIA-53BRL-CAD: place have to go back and list all the stuff not referred to now (what in
14:48.53CIA-53BRL-CAD: autotools would be the EXTRA_DIST entries)
15:28.33*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
16:24.25CIA-53BRL-CAD: 03starseeker * r43040 10/brlcad/branches/cmake/ (7 files in 6 dirs):
16:24.26CIA-53BRL-CAD: Add more of the machinery for distcheck file checking - modify macros, add
16:24.26CIA-53BRL-CAD: specific macros for ignoring things not otherwise covered by macros or build
16:24.26CIA-53BRL-CAD: logic. Fail in distcheck if an ignored file is represented elsewhere in the
16:24.26CIA-53BRL-CAD: build logic - may indicate a previously unused file is now in use and shouldn't
16:24.26CIA-53BRL-CAD: be ignored any longer.
16:27.12*** join/#brlcad Guest66717 (~peppe@host101-161-dynamic.10-87-r.retail.telecomitalia.it)
16:29.47CIA-53BRL-CAD: 03starseeker * r43041 10/brlcad/branches/cmake/misc/CMake/BRLCAD_Util.cmake: Don't allow ignoring of files that don't exist - enforces a 'no clutter' policy
18:42.29CIA-53BRL-CAD: 0370.239.88.156 07http://brlcad.org * r2459 10/wiki/STEP: /* Existing Open Source Tools */ - add NIST/NASA/ESA info
18:43.34CIA-53BRL-CAD: 0370.239.88.156 07http://brlcad.org * r2460 10/wiki/STEP: /* These tools generate C++ from an EXPRESS schema */
18:45.57CIA-53BRL-CAD: 0370.239.88.156 07http://brlcad.org * r2461 10/wiki/STEP: /* Existing Open Source Tools */
18:57.06CIA-53BRL-CAD: 03starseeker * r43042 10/brlcad/branches/cmake/ (6 files in 6 dirs): Take things one step further - if a CMakeLists.txt file is including files from subdirectories, scanning those subdirectories for un-accounted-for files becomes the responsibility of that CMakeLists.txt file.
18:58.49*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
19:04.56CIA-53BRL-CAD: 03starseeker * r43043 10/brlcad/branches/cmake/misc/CMake/ (BRLCAD_Util.cmake distcheck_buildsys.cmake.in): tweaks, remove debug printing
19:38.20CIA-53BRL-CAD: 03starseeker * r43044 10/brlcad/branches/cmake/ (4 files in 3 dirs): Start the slog of listing files. cheat a little with iwidgets - use the macro even though it's in src/other, otherwise it's totally ignored by the system.
20:26.20CIA-53BRL-CAD: 03starseeker * r43045 10/brlcad/branches/cmake/src/other/CMakeLists.txt: First pass at setting up src/other. Probably should separate out this file into various .cmake files that are included, just to improve readibility.
20:53.38CIA-53BRL-CAD: 03jordisayol * r43046 10/brlcad/trunk/misc/debian/application-x-brlcad-extension.xml: changed mime type from binary to text
21:38.44CIA-53BRL-CAD: 03starseeker * r43047 10/brlcad/branches/cmake/ (59 files in 58 dirs): Not perfect, but demonstrates a working mechanism to spot files present in the source tree but not accounted for in CMakeLists.txt files.
21:51.14CIA-53BRL-CAD: 03starseeker * r43048 10/brlcad/branches/cmake/misc/CMake/distcheck_buildsys.cmake.in: Flesh out the error message a little more - make it fatal now.
21:53.04*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
21:57.54CIA-53BRL-CAD: 03starseeker * r43049 10/brlcad/branches/cmake/CMakeLists.txt: Add some cleanup to the distcheck target
22:34.08CIA-53BRL-CAD: 03starseeker * r43050 10/brlcad/branches/cmake/CMakeLists.txt: Clean up benchmark, add printout for successful distcheck.
22:34.48CIA-53BRL-CAD: 03starseeker * r43051 10/brlcad/branches/cmake/misc/CMake/distcheck_success_message.cmake.in: Whoops, add the cmake file.
22:42.30CIA-53BRL-CAD: 03starseeker * r43052 10/brlcad/branches/cmake/CMakeLists.txt: Whoops - install, not build for this test.
22:50.43CIA-53BRL-CAD: 03starseeker * r43053 10/brlcad/branches/cmake/CMakeLists.txt: It's a better test if the install directory is on its own.
23:05.41CIA-53BRL-CAD: 03starseeker * r43054 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/svncheck.cmake): More tweaks
23:31.37*** join/#brlcad ibot (ibot@rikers.org)
23:31.37*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
23:36.12CIA-53BRL-CAD: 03starseeker * r43055 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/distcheck_buildsys.cmake.in): Ah, toplevel directory was escaping. Probably a cleaner way to do this, but this will work.
23:37.17*** join/#brlcad roberthl (~robert@v001.rhl.me.uk)
23:37.17*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
23:59.01*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
IRC log for #brlcad on 20110207

IRC log for #brlcad on 20110207

00:10.08*** join/#brlcad roberthl (~robert@v001.rhl.me.uk)
00:10.09*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
01:14.44*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
02:50.34*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
03:33.24*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
03:44.22*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
04:22.42CIA-53BRL-CAD: 03starseeker * r43056 10/brlcad/branches/cmake/ (3 files in 2 dirs): Nevermind the ignore thing for now - it's of questionable use and a complication
04:23.55CIA-53BRL-CAD: 03starseeker * r43057 10/brlcad/branches/cmake/misc/CMake/distcheck_buildsys.cmake.in: More simplification
04:29.29CIA-53BRL-CAD: 03starseeker * r43058 10/brlcad/branches/cmake/misc/CMake/distcheck_buildsys.cmake.in: Whoops, don't break the logic in the process...
05:06.06*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
11:26.28CIA-53BRL-CAD: 03davidloman * r43059 10/rt^3/trunk/src/other/sqlite_3_7_4/: Added the sqlite .so to svn:ignore.
11:27.18dlomanMernin all!
12:05.09starseekerdloman: morning!
12:13.35CIA-53BRL-CAD: 03starseeker * r43060 10/brlcad/branches/cmake/ (CMakeLists.txt src/other/CMakeLists.txt): Tweak settings for Jove
12:24.19CIA-53BRL-CAD: 03starseeker * r43061 10/brlcad/branches/cmake/src/libfb/CMakeLists.txt: Conditionalize building of specific if_* files on build settings.
12:27.08starseekerbrlcad: have you tried building lately without X11 enabled?  I'm seeing some warnings in libfb about unused parameters, which I think are due to all the code being conditionalized out by the IF_* wrappers not being turned on
12:34.10*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
12:35.39*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:38.02CIA-53BRL-CAD: 03starseeker * r43062 10/brlcad/branches/cmake/src/libdm/CMakeLists.txt: Same deal with libdm - don't build files we don't need
12:49.19CIA-53BRL-CAD: 03starseeker * r43063 10/brlcad/branches/cmake/src/other/CMakeLists.txt: If we aren't using Tk, then as far as C is concerned we don't have it.
12:50.22CIA-53BRL-CAD: 03starseeker * r43064 10/brlcad/branches/cmake/src/mged/attach.c: Without the tk.h header, Tk_GenericProc isn't a valid type - wrap in ifdef. This lets mged compile without any display manager (except nu) or gui
12:53.28CIA-53BRL-CAD: 03starseeker * r43065 10/brlcad/branches/cmake/db/CMakeLists.txt: Respect the BRLCAD-INSTALL_EXAMPLE_GEOMETRY flag
13:04.34CIA-53BRL-CAD: 03starseeker * r43066 10/brlcad/branches/cmake/TODO.cmake: Update TODO.cmake
13:54.08CIA-53BRL-CAD: 03starseeker * r43067 10/brlcad/branches/cmake/configure.cmake.sh: Add beginnings of simple wrapper to allow '../configure --stuff' invocation of CMake configure process.
14:05.58CIA-53BRL-CAD: 03davidloman * r43068 10/rt^3/trunk/cmake/ (7 files): First round of year 2010 to 2011 text updates. Will be in a series of commits because, for some reason, one large commit seems to continually fail.
14:07.04CIA-53BRL-CAD: 03davidloman * r43069 10/rt^3/trunk/ (CMakeLists.txt COPYING tests/CMakeLists.txt): Continuing year 2010 to 2011 text updates.
14:10.42CIA-53BRL-CAD: 03davidloman * r43070 10/rt^3/trunk/tests/ (15 files in 4 dirs): Continuing year 2010 to 2011 text updates.
14:11.42CIA-53BRL-CAD: 03davidloman * r43071 10/rt^3/trunk/tests/ (8 files in 4 dirs): Continuing year 2010 to 2011 text updates.
14:15.10CIA-53BRL-CAD: 03davidloman * r43072 10/rt^3/trunk/ (6 files in 2 dirs): Continuing year 2010 to 2011 text updates.
14:18.16CIA-53BRL-CAD: 03davidloman * r43073 10/rt^3/trunk/m4/ (9 files): Continuing year 2010 to 2011 text updates.
14:20.37CIA-53BRL-CAD: 03davidloman * r43074 10/rt^3/trunk/include/brlcad/ (20 files): Continuing year 2010 to 2011 text updates.
14:21.41CIA-53BRL-CAD: 03davidloman * r43075 10/rt^3/trunk/include/ (21 files): Continuing year 2010 to 2011 text updates.
14:41.37CIA-53BRL-CAD: 03davidloman * r43076 10/rt^3/trunk/include/ (18 files): Continuing year 2010 to 2011 text updates.
14:44.27CIA-53BRL-CAD: 03davidloman * r43077 10/rt^3/trunk/include/ (29 files): Continuing year 2010 to 2011 text updates.
14:47.38CIA-53BRL-CAD: 03davidloman * r43078 10/rt^3/trunk/ (9 files in 2 dirs): Continuing year 2010 to 2011 text updates.
14:51.35CIA-53BRL-CAD: 03davidloman * r43079 10/rt^3/trunk/src/ (133 files in 13 dirs): Continuing year 2010 to 2011 text updates.
14:55.19*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
15:02.41CIA-53BRL-CAD: 03davidloman * r43080 10/rt^3/trunk/src/ (60 files in 13 dirs): Last of year 2010 to 2011 text updates.
15:02.41``Erikhuh, debian 6.0 GNU/kFreeBSD O.o
15:34.03CIA-53BRL-CAD: 03starseeker * r43081 10/brlcad/branches/cmake/CMakeLists.txt: Heh - distcheck caught it. Add the new configure script to the ignore list.
15:36.24``Erikis this release done yet? O.o
15:37.08starseekerhmm?  dunno, that's the new distcheck in the CMake branch
15:37.41``Erikyeah, wasn't referring to the cmake branch... TODO says 'nada!', and I'm itching to commit this merge :D
15:37.55starseekeroh, gotcha
15:46.45CIA-53BRL-CAD: 03davidloman * r43082 10/rt^3/trunk/: Added the CmakeTmp folder to svn:ignore.
15:47.56CIA-53BRL-CAD: 03starseeker * r43083 10/brlcad/branches/cmake/src/ (CMakeLists.txt libdm/CMakeLists.txt libfb/CMakeLists.txt): Couple more distcheck tweaks.
15:57.07CIA-53BRL-CAD: 03starseeker * r43084 10/brlcad/branches/cmake/ (CMakeLists.txt misc/CMake/svncheck.cmake): Try conditionalizing the svn part of the distcheck - only want to do this if a) we have svn and b) we're building from an svn repository
16:07.17CIA-53BRL-CAD: 03starseeker * r43085 10/brlcad/branches/cmake/ (3 files in 2 dirs): Fix and simplify svn checking logic - doing it this way, temp file isn't needed.
16:08.50dlomanbrlcad: I 'hate' you now.  I'm hooked on Zombie Trailer park.....
16:33.51*** join/#brlcad dli (~dli@66.49.141.114)
16:42.13*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
17:52.08``Erikhah
17:56.11CIA-53BRL-CAD: 03starseeker * r43086 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Few more distcheck files from checking on Mac.
18:17.29CIA-53BRL-CAD: 03starseeker * r43087 10/brlcad/branches/cmake/CMakeLists.txt: provide a make distclean target for cleanup after an aborted make distcheck
18:20.25CIA-53BRL-CAD: 03starseeker * r43088 10/brlcad/branches/cmake/misc/CMake/distcheck_buildsys.cmake.in: Don't be completely quiet in the case of success.
18:26.21*** join/#brlcad Ralith (~ralith@d142-058-095-100.wireless.sfu.ca)
19:19.53CIA-53BRL-CAD: 03starseeker * r43089 10/brlcad/branches/cmake/CMakeLists.txt: (log message trimmed)
19:19.53CIA-53BRL-CAD: Clean up the Aqua logic a little. Punt on Aqua for now, since a) it's not
19:19.53CIA-53BRL-CAD: working anyway b) there's a fair bit of work to do with the tcl/tk CMake logic
19:19.53CIA-53BRL-CAD: to enable Aqua c) the Aqua layer for Tcl/Tk is in flux (moving from Carbon to
19:19.53CIA-53BRL-CAD: Cocoa) and it's not clear that the older Carbon backend in 8.5 will work on
19:19.54CIA-53BRL-CAD: newer OSX systems (all new development effort is focused on the Cocoa backend).
19:19.55CIA-53BRL-CAD: Togl will need to be made to work with the new Cocoa backend once it appears as
19:25.22CIA-53BRL-CAD: 03starseeker * r43090 10/brlcad/branches/cmake/ (CMakeLists.txt TODO.cmake): Mark aqua option as advanced regardless, move TODO.cmake item
19:28.17CIA-53BRL-CAD: 03starseeker * r43091 10/brlcad/branches/cmake/ (CMakeLists.txt configure.cmake.sh): remove stray debug message
19:32.06*** join/#brlcad Ralith (~ralith@d142-058-095-100.wireless.sfu.ca)
19:33.50CIA-53BRL-CAD: 03starseeker * r43092 10/brlcad/branches/cmake/CMakeLists.txt: else, not elseif
19:34.08*** join/#brlcad willdye (~willdye@fern.dsndata.com)
19:39.20brlcaddloman: hahaha
19:39.33brlcadthat fourth level took me quite a while to finally beat
19:40.48brlcadfor release, I had a final build distcheck going on saturday and haven't checked in on it since -- looking now
19:44.08dlomanbrlcad: Getting my rear end handed to be on level 3.
19:44.24dlomanLooks like, in a zombie apocalypse, I wouldn't last long as a leader :)
19:49.03CIA-53BRL-CAD: 03brlcad * r43093 10/brlcad/trunk/BUGS:
19:49.03CIA-53BRL-CAD: this might be intentional behavior but it feels like a bug. create a jumbled
19:49.03CIA-53BRL-CAD: mess of primitives all at the origin and they'll seem to render wrong,
19:49.03CIA-53BRL-CAD: particularly if you union them all into a region. might have something to do
19:49.03CIA-53BRL-CAD: with the halfspace.
19:49.23brlcadthe key to all the levels is to build those money-maker's as fast as absolutely possible
19:50.17brlcadonly sending guys and only building the bare minimum until they're all built
19:54.00CIA-53BRL-CAD: 03starseeker * r43094 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Tweak OSX hack for debug flags
20:01.01CIA-53BRL-CAD: 03starseeker * r43095 10/brlcad/branches/cmake/ (CMakeLists.txt configure.cmake.sh): Add a few more config options, remove commented out C99 stuff (belongs in CompilerFlags.cmake)
20:05.20CIA-53BRL-CAD: 03brlcad * r43096 10/brlcad/trunk/BUGS: more details on how to reproduce the badness. the rendering of 'primitives' is presently crashing inside rt_bot_makesegs_double() for me.
20:27.35CIA-53BRL-CAD: 03brlcad * r43097 10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: remove dead code. not documented why we'd keep old or new.
20:49.21CIA-53BRL-CAD: 03starseeker * r43098 10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Add a couple flags identified in the old libtcl.vcproj file for 64 bit
20:52.32CIA-53BRL-CAD: 03starseeker * r43099 10/brlcad/branches/cmake/src/other/tk/CMakeLists.txt: Add same flags for tk
21:09.48starseekerdloman: is d_rossberg actively using anything in the rt^3 branch in production?
21:10.07starseekerif so, I'd probably better branch before I start mucking too much
21:25.42brlcadyes, he is -- the geometry engine code is in there
21:25.58brlcadthe c++ interface he's been working on
21:26.10starseekerk
21:26.40starseekerbrlcad: I seem to have a fairy functional distcheck now
21:26.55brlcadgreat
21:30.22starseekerI'll update the various docs, and then I'll need someone to do a review for merge
22:06.01CIA-53BRL-CAD: 03starseeker * r43100 10/brlcad/branches/cmake/CMakeLists.txt: Set policy CMP0007 so FindTCL won't trigger warning messages
22:18.53brlcad(still build-testing)
22:19.14brlcadepileg: you can download the current and re-upload
22:19.26epilegok
22:30.03CIA-53BRL-CAD: 03starseeker * r43101 10/brlcad/branches/cmake/src/librt/opennurbs_ext.h: Hmm - looks like this attribute line isn't entirely portable.
22:33.03starseekerhttps://bugzilla.redhat.com/show_bug.cgi?id=147446
22:45.17*** join/#brlcad Ralith (~ralith@d142-058-081-182.wireless.sfu.ca)
23:36.20CIA-53BRL-CAD: 03starseeker * r43102 10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt:
23:36.20CIA-53BRL-CAD: Comment out the parts that break Xcode generator in Tcl build - will have to
23:36.20CIA-53BRL-CAD: figure out something else, probably limited config.h header (perhaps this is why
23:36.20CIA-53BRL-CAD: there is logic in the tcl/tk makefiles on apple for a config header)
IRC log for #brlcad on 20110208

IRC log for #brlcad on 20110208

00:32.33CIA-53BRL-CAD: 03starseeker * r43103 10/brlcad/branches/cmake/TODO.cmake: Add todo note for XCode
01:14.48CIA-53BRL-CAD: 03starseeker * r43104 10/brlcad/branches/cmake/CMakeLists.txt: try ORIGIN first - if the binary is running locally, pulling a system lib would be both subtly unexpected and potentially subtly wrong.
01:47.14*** part/#brlcad epileg (~epileg@unaffiliated/epileg)
01:52.31*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
02:03.14CIA-53BRL-CAD: 03starseeker * r43105 10/brlcad/branches/cmake/CMakeLists.txt: quote the flag string - it's not a list in the CMake sense
02:05.11*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
02:10.02*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:12.37CIA-53BRL-CAD: 03starseeker * r43106 10/brlcad/branches/cmake/ (INSTALL README configure.cmake.sh): Start working on docs - part way through install, but there are a lot of options to cover...
02:27.22CIA-53BRL-CAD: 03starseeker * r43107 10/brlcad/branches/cmake/CMakeLists.txt:
02:27.23CIA-53BRL-CAD: Was right the first time - can't be sure what impact symbolic links and the
02:27.23CIA-53BRL-CAD: links may have on ORIGIN. Have to go with the install path first, and just make
02:27.23CIA-53BRL-CAD: sure it doesn't conflict with a system path if the idea is to make something
02:27.23CIA-53BRL-CAD: relocatable.
03:53.51brlcadstarseeker: that bug doesn't seem entirely relevant
03:54.27brlcador did you hit the "unimplemented" message?
03:55.01brlcadeither way, a different fix is likely going to be needed -- merging that back to trunk will likely break optimized (strict) build
03:59.01brlcads/likely/should/
03:59.22brlcadthat was specifically added to fix an inline failure
04:07.06starseekerI hit the unimplemented message
04:07.11starseekerrefused to compile at all
04:38.38*** join/#brlcad jmoore (~jmoore@cpe-184-57-8-75.columbus.res.rr.com)
04:45.24jmooreHi. Is their a simple way to get a list of leaf's and combs using c? tying to duplicate the functionality ls in mged for use in another function.  I found the tree walk function but they take a starting dir and I am having truble figering out how to exrract all of the used ones in dbi_Head
04:56.27brlcadstarseeker: goes without saying, though, that another fix will be needed -- you just shifted the failure from one platform over to another
04:57.55brlcadjmoore: there are about a half dozen differen tree walkers for that purpose -- you can see how the ls command does it, for example, in src/libged/ls.c (ged_ls())
04:59.34brlcadthe src/libged commands build on top of the underlying librt API
05:01.01brlcadjmoore: probably more useful than the ls command, however, is the "l" aka "list" command -- src/libged/list.c
05:01.45brlcadends up calling rt_functab[id].ft_describe() which writes the listing to a string
05:02.17jmoorethanks
05:03.29brlcadjmoore: have you seen this: http://brlcad.org/wiki/Example_db_walk_tree
05:04.10brlcadnot entirely what you're asking as you don't need to walk recursively to just display members of a combinatino
05:08.19brlcadjmore: db_lookup() + rt_db_get_internal() + db_flatten_tree() will give you a simple array of the combination elements listing the CSG operator and the name of the object
05:08.50jmooreNo I had not. I looks like a starting point good you all redy have a base shape's name.
05:10.00brlcada couple more useful dev resources including a ray-shooting example at http://brlcad.org/wiki/Developing_applications
05:10.08jmoorebeen piling threw http://brlcad.org/wiki/Example_db_walk_tree
05:10.16jmoorehttp://brlcad.org/xref/ident
05:11.13brlcadit's a huge API to traverse that way -- encourage you to ask questions here or on the devel mailing list
05:16.08brlcad2000+ public functions across a dozen different libraries, numerics, generic routines, ray tracing, geometry, image processing, .... it's easy to get lost
05:17.19jmoorek thanks.
05:17.40jmoorethat is for suer.
08:40.49*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:42.53d_rossbergstarseeker: first the good news: i was able to build ALL_BUILD in reasonable time, INSTALL it, run mged, load a database there and raytrace into a pupup window :)
08:44.20d_rossbergand i was able to reproduce the OPENNURBS & UTAHRLE error: http://paste.ubuntu.com/564291/
08:45.45d_rossbergafter removing all from the installation directory the configuration went through
11:24.45*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
11:40.28*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:31.24*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:03.39starseekerd_rossberg: what's happening there is the find routines are identifying previously installed BRL-CAD files
13:04.18starseekeris your CMAKE_INSTALL_PREFIX set to C:/brlcad.cmake/aInstall ?
13:06.13starseekerlooks like the summary thinks it is...
13:10.01CIA-53BRL-CAD: 03starseeker * r43108 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Don't try getting properties from openNURBS unless we're actually building it.
13:10.28starseekerthat may fix the error (and was legit enough) but the real issue is why it's looking in the install path
13:11.04starseekerlogic in the root CMakeLists.txt file starting line 116 is intended to prevent that
13:49.46d_rossbergright: my CMAKE_INSTALL_PREFIX is set to C:/brlcad.cmake/aInstall
13:50.31d_rossbergmy build directory is C:/brlcad.cmake/aBuild
13:51.11d_rossbergmy brlcad checkout directory is C:/brlcad.cmake (for the cmake build)
14:32.19CIA-53BRL-CAD: 03starseeker * r43109 10/geomcore/: Since parts of rt^3 are being used, make a branch of it to thrash around in.
14:36.06CIA-53BRL-CAD: 03starseeker * r43110 10/geomcore/trunk/src/other/ (CMakeLists.txt ogre/ ois/): Don't need ogre and ois in here right now, dated anyway
14:36.55CIA-53BRL-CAD: 03starseeker * r43111 10/geomcore/trunk/src/g3d/: This is in the other branch, not the focus of current efforts - remove from this one
14:38.17CIA-53BRL-CAD: 03starseeker * r43112 10/geomcore/trunk/src/ (rt^3/ rt^3d/ rt^3dbd/ scratch/): Not added by CMakeLists.txt, confusingly named - remove
15:01.11CIA-53BRL-CAD: 03jordisayol * r43113 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): add the option to build openSUSE rpm packages
15:12.20*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
15:39.45dlomanoh, one last thing starseeker and ``Erik :  No laughing at my code, I have thin skin and a violent temper!
15:39.49dloman=D
15:39.56starseekeryou too?
15:40.06``ErikI laugh at everyones code, even my own :D
15:41.16starseekerdloman: is the signals and slots TODO taken care of?
15:41.39dlomanquite likely
15:41.48starseekerk - rewording to make more general
15:41.53dlomani haven't been keeping that file uptodate
15:43.36dlomanchecks out Geomcore....
15:43.43dloman...slowly, lol
15:43.53starseekershould be faster without ogre in there...
15:44.27dlomanyeah, it is.  Network pipe or SF is slow though.
15:44.46dlomanI keep my personal projects/code on a friends server... svn is wiked fast.  
15:44.57dlomanonly has to deal with 10 or so projects, nothing like SF's load
15:44.57CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r2462 10/wiki/Community_Publication_Portal: article on rpm/deb efforts by jordi
15:45.12dlomanso.... Im super spoiled and think that SF svn is wicked slow
15:45.18starseekerheh
15:45.28starseekerit is a bit slow, must admit
15:45.53brlcadsvn from sf.net is slow, but it still far beats having to manage it ourselves
15:47.14brlcadserver availability, svn upgrades, security, web services, hardware backup recovery, ... lots of "one less thing" to worry about at the cost of a little waiting during update/checkin
15:47.39dlomanroger that.  Just sayin' =D
15:48.00CIA-53BRL-CAD: 03starseeker * r43114 10/geomcore/trunk/ (AUTHORS COPYING HACKING INSTALL NEWS README TODO): Lot more to do here - quick scrub to set up focus on geometry engine and geometry server.
15:48.28brlcadit actually encourages better commit practices, since the delay is worse with bigger commits
15:48.54brlcadsmaller frequent commits and the delays aren't really an issue, especially svn commit -m "asdf" &
15:49.10starseekertrue
15:49.15starseekerhadn't thought of that
15:51.39dlomanbrlcad: I'm spreading the infection.  Got a friend in WA hooked on Zombie Trailer Park now :)
15:51.55brlcadexcellent
15:52.01dlomanand he works at MS with a bunch of guys, so lets see how viral it will go!
15:52.06brlcaddloman: beat level 4 yet?
15:52.11dlomanha, nope.
15:52.39dlomanverizon started screwing with the lines in my development yesterday afternoon.  Internet and phone dropped out around 3pm :/
15:54.52starseekerdloman: are the docs  you've been working on the last couple weeks in the docs subdirectory, or just on the wiki?
15:56.03dlomanbeen keeping thr graphics in the docs dir, text on the wiki
15:56.10dlomans/thr/the/
15:56.37starseekerdloman: k.  I may snarf it and stick in docbook, if that's OK
15:56.57dlomansure, they were quickei photochop's, so take that for what it is :)
15:57.15starseekerno problem :-)
15:57.38CIA-53BRL-CAD: 03ronaldbowers * r43115 10/jbrlcad/trunk/src/main/java/org/brlcad/geometryservice/ (5 files): - splitting GeometryService into basic functionality and a caching layer. The caching will be relocated to Gomez.
16:02.56dloman``Erik: would it be good/bad practice to make a dir (save level as src/) to hold all the 'interface' libs?
16:03.21``Erikum, ya mean src/client/{c,java,python,ruby}/ ?
16:03.43dlomanya those
16:03.54dlomanor would src/interfaces/* be better?
16:05.02``Erikd'no *shrug*
16:05.53CIA-53BRL-CAD: 03erikgreenwald * r43116 10/geomcore/trunk/src/client/ (CMakeLists.txt c/ c/CMakeLists.txt c/gsclient.c c/gsclient.h): C stuff stubbed
16:12.32dlomanpreference?
16:12.48starseekerlikes interfaces
16:30.08dloman``Erik: preference?
17:45.35*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
17:56.13``Erikhave none
17:57.52CIA-53BRL-CAD: 03starseeker * r43117 10/geomcore/trunk/src/ (client/ interfaces/): move client to interfaces
17:58.49CIA-53BRL-CAD: 03starseeker * r43118 10/geomcore/trunk/src/CMakeLists.txt: Update build reference
18:10.08CIA-53BRL-CAD: 03starseeker * r43119 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: Try finline-limit expansion instead of the always_inline attribute - perhaps this will be more portable
18:10.28dlomanokie then
18:10.53dlomanstarseeker: we dropping coreInterface out of Geomcore?
18:14.27starseekerdloman: uh, whoops - did I chop too much?
18:15.05dlomannope.  Just saw coreInterface in geomcore/src and figured i'd ask.
18:15.19starseekerare we using it?
18:15.31dlomannot to my knowledge
18:16.06starseekerum... not sure about that one yet.  It's not a slam dunk the way ogre was
18:16.30dlomanokie, no worries.  like I said, just askin.
18:16.47starseekernods - fair question, I just don't know enough to answer it yet
18:23.34CIA-53BRL-CAD: 03davidloman * r43120 10/geomcore/trunk/src/interfaces/java/README: Add README with small blurb about intent and design
18:23.58CIA-53BRL-CAD: 03davidloman * r43121 10/geomcore/trunk/src/interfaces/java/CMakeLists.txt: Removed iBME verbage. Stopped using that acronym a while ago as it doesn't describe the GS project correctly.
18:25.18CIA-53BRL-CAD: 03davidloman * r43122 10/geomcore/trunk/src/interfaces/java/src/ (. org/ org/brlcad/ org/brlcad/geometryservice/): Add in packages
18:25.39dlomanHrm.  Should the interfaces ALL bewired into cmake?  That might make the cmake build a living hell....
18:26.02starseekerdloman: how so?
18:26.38dlomanruby, java, etc... wouldn't cmake need to know how to compile all of those languages?  ...or does it already?
18:26.55``Erikruby isn't compiled, there're hacks to call javac for java
18:27.08``Erik(but not all machines necessarily have java)
18:27.16dlomanwell that's my point.
18:27.28starseekeryou conditionalize on finding java - BRL-CAD cmake build already does that
18:27.33dlomanplus, those that do might not have the same java.... but thats a different can of worms.
18:28.02starseekerdloman: don't worry too much - we have to do SOMETHING to build them all, and CMake is probably as good as any
18:28.04``Erikwell, I'd hope the implementation would be in java 1.4, which should be an ok baseline for everywhere
18:28.26dlomanthe other angle i was thinking about was:  if someone is looking for an interface to the GS, they might not be interested building the rest of hte code.
18:29.05``Erikso'z they  copy the file(s) and wire them into their own build systems? :)
18:29.14starseekerOPTION(ENABLE_INTERFACES "Enable external language interfaces" OFF)
18:29.24dlomanokie.
18:29.58dlomanjust thinking about 'should the interfaces be wired into the main build or not'  ...thats all :)
18:30.09starseekernods - it's OK if they aren't initially
18:30.48CIA-53BRL-CAD: 03davidloman * r43123 10/geomcore/trunk/src/interfaces/java/ (. GSClient.java src/org/brlcad/geometryservice/GSClient.java): Move GSClient into proper package structure.
18:31.00CIA-53BRL-CAD: 03erikgreenwald * r43124 10/geomcore/trunk/src/GE/CMakeLists.txt: no QT used here, remove flags for it
18:38.29CIA-53BRL-CAD: 03davidloman * r43125 10/geomcore/trunk/src/interfaces/java/README: Keep it simple and, rather than copy classes that are under development, make jBRLCAD an dependency. Hopefully this will change in the near future.
18:40.36CIA-53BRL-CAD: 03davidloman * r43126 10/geomcore/trunk/src/interfaces/java/test/ (. org/ org/brlcad/ org/brlcad/geometryservice/): Add in test dir structure
18:42.14CIA-53BRL-CAD: 03davidloman * r43127 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (. msg/): Add in net and net.msg packages for upcoming work on implementing the GSNet protocol in java.
18:58.06CIA-53BRL-CAD: 03davidloman * r43128 10/geomcore/trunk/src/interfaces/java/auto-props.cfg: Add an autoprops file
19:08.03CIA-53BRL-CAD: 03davidloman * r43129 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (GSClient.java GSStatics.java): Create dedicated statics class. Move statics into it.
19:13.01CIA-53BRL-CAD: 03erikgreenwald * r43130 10/geomcore/trunk/src/ (date/CMakeLists.txt libPkgCpp/CMakeLists.txt): remove unnecessary QT references
19:26.39CIA-53BRL-CAD: 03bob1961 * r43131 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Override ArcherCore::zap
19:28.28CIA-53BRL-CAD: 03starseeker * r43132 10/geomcore/trunk/src/date/: Remove date - not been used in a while, and if it's for build config we have other approaches
19:32.05CIA-53BRL-CAD: 03davidloman * r43133 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (3 files): Add in ByteBuffer helper classes. These will be needed for serialization/deserialization of AbstractNetMsg subclasses.
19:36.10CIA-53BRL-CAD: 03davidloman * r43134 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (ByteBufferReader.java ByteBufferWriter.java): Add read/write support for java's UUID to ByteBuffer helper classes.
19:37.10CIA-53BRL-CAD: 03starseeker * r43135 10/geomcore/trunk/src/other/ (CMakeLists.txt sqlite/ sqlite_3_7_4/): Let's not use the version number in the directory name
19:40.22CIA-53BRL-CAD: 03davidloman * r43136 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (ByteBufferReader.java ByteBufferWriter.java): Add explicit read/write support for java's Boolean to ByteBuffer helper classes.
19:40.23CIA-53BRL-CAD: 03starseeker * r43137 10/geomcore/trunk/src/other/sqlite/ (shell.c sqlite3.c sqlite3.h): Update sqlite to sqlite-amalgamation-201101281703, add sqlite3.h
19:55.16CIA-53BRL-CAD: 03davidloman * r43138 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (GSClient.java net/msg/NetMsgTypes.java): Move NetMsg types out of GSClient and into a dedicated class in the .net.msg package.
19:56.21CIA-53BRL-CAD: 03davidloman * r43139 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/AbstractNetMsg.java: First cut at implementation of AbstractNetMsg in java.
20:02.00CIA-53BRL-CAD: 03davidloman * r43140 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferReader.java: Add helper cstr to ByteBufferReader that defaults endian flip to false.
20:02.14*** join/#brlcad PrezKennedy (MK@2607:f0d0:3001:68::2)
20:04.46CIA-53BRL-CAD: 03erikgreenwald * r43141 10/geomcore/trunk/src/CMakeLists.txt: date is gone
20:09.18CIA-53BRL-CAD: 03davidloman * r43142 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java: Stub in the skeleton for a simple netMsg factory.
20:43.08CIA-53BRL-CAD: 03davidloman * r43143 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Stub in the first round of GSConnection work. Nowhere near functional yet, still building infrastructure.
20:43.56CIA-53BRL-CAD: 03davidloman * r43144 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Import cleanup.
21:35.26``Erikcd src/libNe
21:35.28``Erikwoops
21:38.15CIA-53BRL-CAD: 03starseeker * r43145 10/geomcore/trunk/ (41 files in 14 dirs): Start rework of the CMake build - no longer generating libutility.h and friends, so update the code accordingly
21:47.10CIA-53BRL-CAD: 03starseeker * r43146 10/brlcad/branches/cmake/ (6 files in 5 dirs): MFC 43145
22:16.15brlcadoutstanding, looks like distcheck is clean 32-bit and 64-bit now
22:16.26brlcadstarting release
22:41.08CIA-53BRL-CAD: 03starseeker * r43147 10/geomcore/trunk/src/other/uuid/ (50 files): Preliminary steps to getting off of using Qt's uuid feature - use ossp uuid, but there's a complex test for va_copy that I haven't reproduced in CMake yet.
22:46.16CIA-53BRL-CAD: 03starseeker * r43148 10/geomcore/trunk/src/other/uuid/CMakeLists.txt: give uuid a project setting. Also note that there was a change to the source of uuid_str.c - a couple of #if statements were changed to #ifdef
23:07.01CIA-53BRL-CAD: 03starseeker * r43149 10/geomcore/trunk/src/other/ (CMakeLists.txt uuid/CMakeLists.txt uuid/uuid_ac.h): Add uuid to build, also switch uuid's config.h to uuid_config.h to avoid conflicts with the main config file
IRC log for #brlcad on 20110209

IRC log for #brlcad on 20110209

01:00.15*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
01:45.21*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
01:53.11starseeker``Erik: unless BSD has done some serious hacking, APR and APR-util are mandatory for subversion
02:01.49*** join/#brlcad dli (~dli@66.49.141.114)
02:07.28dlihi, I wonder whether it's possible to add openGL support for brlcad, so rendering, can be in real time
02:11.30starseekerthat depends on what you mean by rendering
02:11.51starseekerif you mean 3D shaded display, the hard part is converting our geometry to the triangles needed to feed OpenGL
02:12.15starseekerif you mean raytracing, you may want to take a look at adrt
02:12.55dlistarseeker, raytracing is still slow, I know this part. I just mean to use more features from modern video cards
02:13.35starseekerrobust tessellation is a foundation for any shaded display using OpenGL, unless you're talking about raytracing using the GPL
02:13.39starseekerer GPU
02:13.59starseekerwe haven't done much in the raytracing with GPU direction
02:14.22dlistarseeker, no, I don't expect raytracing on GPU, too much work :(
02:15.21dlistarseeker, so, you think it's possible. if true, it would very much exciting, CAD can be a real time simulator then
02:15.50starseekerit's certainly possible, but robust tessellation of CSG geometry is not a simple problem
02:17.04dlistarseeker, which level is the cause of problems? conceptual, algorithm, or just have to rewrite a lot?
02:19.07CIA-53BRL-CAD: 03starseeker * r43150 10/geomcore/trunk/src/other/subversion/COPYING: Whoops - add the subversion COPYING file
02:19.22starseekerdli: both algorithmic and lot of code to wrangle
02:19.33starseekertake a look at the nmg code in librt to get an idea
02:20.47dlistarseeker, I will try. I hope I can understand something first
02:21.23starseekerdli: brlcad may be able to give you a better overview of the various options and where a good starting point is
02:21.53starseekermost of the issues I'm familiar with involving tessellation and shaded displays involve "diving off the deep end"
02:22.44dlistarseeker, yes, long time ago, I wanted to contribute to this project, but too busy at that time. now, I have should have some time for algorithm and coding
02:23.22dlistarseeker, thanks a lot, I will talk to brlcad later
02:23.33starseekerdli: awesome :-)
02:24.09starseekerdli: one good starting point might be to look at one of the convertors in src/conv
02:24.21starseekermost of them invoke tessellation logic
02:24.50dlistarseeker, sure, I will try to read as much as possible, to help understanding
02:33.36starseekerlooks at the apr configure process and turns white
02:36.56starseekerchecks the subversion code a little...
02:41.07starseeker``Erik: yeah, there's no way they've avoided requiring apr - the entire code base is thick with apr types and calls
02:41.20starseekerremoving apr would amount to a total rewrite
03:35.52brlcaddli: technically, we already have opengl support -- you can see it in action with a private debug setting on an opengl-enabled build
03:36.54brlcadthe problem is that the way it's currently implemented is at least np-hard, error-prone to numeric drift, slow as balls, and not robust (because it's np-hard)
03:37.25dlibrlcad, I see, so, it's not really useful as is
03:37.32brlcadso you can either work on making it more robust (which would be fantastic, but hard) then make it faster (probably the easiest part)
03:38.10brlcadthe problem is mostly algorithmic
03:39.12brlcadconsider two overlapping spheres, for example, simply defined by a point and a radius, unioned together
03:39.16dlibrlcad, I will read the code first :)
03:40.21brlcadcurrent approach basically turns each of the two spheres into a set of polygons (trivial) then evaluates interior, exterior, and overlapping polygons
03:40.36starseekerreluctantly concludes libgit2 is too immature feature wise to be an option for some time, even if we could switch horses now (which we can't)
03:40.36brlcadthat's also trivial/easy
03:41.04dlibrlcad, how could this be NP?
03:41.06brlcadsince it's a union, it throws away the interior polygons, keeps the exterior, and stitches together the overlapping ones trimming away and splicing together correctly
03:41.33brlcaddli: I'm showing you one of the very most simple cases just for understanding of the basic algorithm
03:42.00brlcadit's actually a relatively simple algorithm, but the devil is in the details
03:42.53dlibrlcad, because we build the geometry part by part, I suppose the complexity of adding one more primitive is O(N), for N existing primitives
03:42.57brlcadit's not robust for a variety of problems, including floating point drift during the trimming/splicing stage but also because we're evaluating the boolean AFTER tessellating all primitives where we're no longer matching the original surface
03:43.30brlcadthat'd be linear complexity, which it is not :)
03:43.52brlcadit's exponential to evaluate the N+1 primitive against the previous N set
03:45.24brlcadthere are tons of optimizations possible, you could get the performance down to reasonable levels with some basic space partitioning -- in fact the current code does this for some cases
03:45.31dlibrlcad, the complexity of voronoi cell analysis is N log(N), I feel it's similar
03:45.57brlcadthe problem with the approach, however, is that it's still basically a lossy approach
03:46.47brlcadso even if you solved the robustness problem with careful numerics and consistently handling all edge cases, there are STILL going to be some comparisons that fundamentally cannot be solved without making a blind guess
03:47.00brlcadthat's where NURBS comes in
03:47.26brlcadit's the new approach that will eventually make the current approach obsolete -- the boolean is evaluated prior to tessellation
03:48.49brlcadinstead of converting each primitive to a mesh, each is converted to a spline surface, surface-surface intersection calculations are performed (just like done with meshes, marking interior/exterior/overlapping surfaces), surfaces are trimmed according to the boolean, and the resulting *evaluated* surfaces are then trivially tessellated
03:48.51dlibrlcad, sounds very interesting to me, I feel I could contribute something here. I did molecular dynamics, genetic aglorithm, voronoi cells, and have some time for coding now
03:49.54brlcaddli: that's fantastic, there are plenty of places you could jump in
03:50.47dlibrlcad, give me some clues :)
03:51.12brlcadbasically you can either work on our mesh support (i.e., the current approach, which will still be needed even with nurbs, for polygonal surfaces) or..
03:51.37brlcadyou can work on the various outstanding issues with our new nurbs support
03:52.36brlcadsurface-surface intersection calculations to derive an intersection curve is one problem still TBD -- robustly tessellating a nurbs surface is another
03:53.07dlibrlcad, under src/others/openNURBS/ ?
03:53.10brlcadthe mesh processing is much more approachable but will require systematically reviewing thousands and thousands of lines of code, hundreds of functions
03:53.46brlcaddepends what your exact goal is :)
03:54.33brlcadI'd set a specific small goal and then it'll be easier to point you in the right direction towards implementing that goal
03:55.09dlibrlcad, I think I would try the surface-surface intersection first
03:55.59brlcadokay
03:56.34brlcadthen your starting point is probably:  http://en.wikipedia.org/wiki/Surface-to-surface_intersection_problem
03:57.13brlcadthere are tons of approaches and research on the subject, but that's a good primer
03:57.55starseekerdli: I have a few links to papers I can dig up tomorrow
03:57.57brlcadcode-wise, src/other/openNURBS is a good starting point along with where we hook openNURBS into our code for ray-tracing at src/librt/primitives/brep
03:58.24dlistarseeker, thanks
03:58.54brlcadyou're basically writing a function that takes two ON_Brep objects and returns an ON_Curve
03:59.11brlcador an ON_Surface or similar "intersection result"
03:59.19starseekerdli: ah, wait - found it :-) http://www.cs.berkeley.edu/~hling/research/paper/intersection.htm
03:59.47dlibrlcad, nice, quite specific at this stage
04:00.13brlcaddli: you can start with src/proc-db/brep_simple.cpp
04:00.29brlcadthat shows how one manually creates a b-rep box using openNURBS
04:01.04brlcadyou could easily extend that example to just create two surfaces, then evaluate their intersection
04:02.03brlcada summer student attempt this about a year and a half ago, their effort is in src/proc-db/surfaceintersect.cpp
04:02.20CIA-53BRL-CAD: 03starseeker * r43151 10/geomcore/trunk/src/other/subversion/CMake/ThirdParty.cmake:
04:02.20CIA-53BRL-CAD: Chop third party macro stuff down to just autoconf - need to sync with the newer
04:02.20CIA-53BRL-CAD: one in BRL-CAD, but this has specific improvements to the autoconf routines that
04:02.20CIA-53BRL-CAD: will need to be merged back into the main version (BRL-CAD trunk no longer does
04:02.20CIA-53BRL-CAD: third party builds with autoconf, but apr and friends look to be very difficult
04:02.21CIA-53BRL-CAD: conversion prospects for CMake.)
04:03.09dlibrlcad, good enough :) so, I will read the brep_simple.cpp, and figure out the data structures, then, write a function to to find intersection of two ON_Brep objects
04:03.30starseekerbrlcad: we may have to settle for building apr using their Visual Studio files on Windows as a precursor to building our subversion stuff - I don't know that I've found any successful examples of external projects in Visual Studio, although I can't yet say that for certain
04:08.55brlcadmore info at http://mae.ucdavis.edu/~farouki/foils.pdf or with more rigor ftp://ftp.cs.unc.edu/pub/users/manocha/PAPERS/INTERSECT/IJCGA.pdf  (he's published an update in 1997, but don't have a link for it)
04:09.53brlcadstarseeker: not worried about external deps for GS until it's fully implemented -- dev rule can simply be "install it first" in the meantime
04:10.06dlibrlcad, got them. some reading time now
04:10.26brlcadrun cmake test(s), if not found -- print a message saying they need to install it
04:11.30brlcadbuild system integration isn't an issue until it's time for public deployment (which isn't on the table this year)
04:11.38brlcaddli: great
04:17.37brlcaddli, if you start making progress on code, let me know and we can get you set up with commit access so your efforts can be incrementally visible to others, traceable, and easier to understand the end-result
04:18.31dlibrlcad, sure, we will see :)
04:25.55*** join/#brlcad jmoore (~jmoore@cpe-184-57-8-75.columbus.res.rr.com)
04:25.55*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
04:25.55*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
04:25.55*** join/#brlcad kanzure (~kanzure@131.252.130.248)
04:25.55*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
04:25.55*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
04:25.55*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
04:25.55*** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl)
04:25.55*** join/#brlcad piksi (piksi@pi-xi.net)
04:30.27*** join/#brlcad IriX64 (~IriX64@70.52.228.89)
04:32.38*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
05:26.40CIA-53BRL-CAD: 03brlcad * r43152 10/brlcad/trunk/NEWS: include write-up highlights for 7.18.2 emphasizing the v4 compatibility work along with the platform integration efforts from new contributor jordi sayol.
05:28.08CIA-53BRL-CAD: 03brlcad * r43153 10/brlcad/trunk/NEWS: jordi also improved platform support on Fedora, so call it out. leave openSUSE for the next release since it's not as well-tested.
05:31.51CIA-53BRL-CAD: 03brlcad * r43154 10/brlcad/trunk/include/conf/PATCH: bump patch to .2 for release 7.18.2, final stages
05:32.23CIA-53BRL-CAD: 03brlcad * r43155 10/brlcad/trunk/ChangeLog: update ChangeLog for release 7.18.2
05:42.04CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r2463 10/wiki/Community_Publication_Portal: initial notes for 7.18.2
05:44.38CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r2464 10/wiki/Community_Publication_Portal: not a pre section
06:09.59*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
06:15.41CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r2465 10/wiki/Community_Publication_Portal: /* Sean Morrison: Release 7.18.2 */ expand, reorganize, and reword accordingly
06:15.58brlcadgah, svn: Revision 43155 doesn't match existing revision 43150 in 'src/other/togl'
06:17.28brlcadthat's why it's bad to delete and readd directories, even when updating revisions -- they have to be merged
06:20.06CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r2466 10/wiki/Community_Publication_Portal: /* Sean Morrison: Release 7.18.2 */
06:27.01CIA-53BRL-CAD: 03Sean 07http://brlcad.org * r2467 10/wiki/Community_Publication_Portal: final draft, ready for posting as soon as merge completes
06:37.07brlcadapparently a problem that was fixed in a later 1.4 version of subversion
06:40.09*** join/#brlcad jmoore (~jmoore@cpe-184-57-8-75.columbus.res.rr.com)
11:47.51dlomanMerning all!
11:57.01dloman*readreadread*
12:10.52dlomanstarseeker / ``Erik either of you good with threading?  I just remembered that GS's JobManagement system is backed by QThread objects
12:37.48CIA-53BRL-CAD: 03davidloman * r43156 10/jbrlcad/trunk/libs/ (. jscience-4.3.1.jar junit-4.1.jar): Added a libs dir with the two required .jars for compilation. jScience 4.3.1 is antiquated and no longer available to the general public but we still want the average jBRLCAD to be able to jump in, compile and help out.
12:38.53CIA-53BRL-CAD: 03davidloman * r43157 10/jbrlcad/trunk/src/test/java/org/brlcad/ShootTest.java: Add in missing package statement.
12:40.33CIA-53BRL-CAD: 03davidloman * r43158 10/jbrlcad/trunk/src/test/java/org/brlcad/geometry/HitTest.java: Import cleanup.
12:54.23starseekerdloman: probably want to look at pthread-win32 + system pthreads on other platforms
12:54.38*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:10.42*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
13:37.19dlomanYeah, but isn't that swapping the dep on QT for a dep on something else?
13:38.35dlomanhangs a Chicken Bone Necklace on his monitor.
13:38.40dlomango go slow network!
13:41.31dlomanfinishes 1.5 hours of timesheets and other red tape :/
14:02.42brlcadfinishes resolving his first tree conflict
14:04.11brlcadat least one of the new svn 1.6 variety
14:05.17starseekerdloman: pthread-win32 is much smaller than Qt
14:07.15brlcaddloman: you know that jbrlcad doesn't have support for all object / primitive types?
14:07.24brlcadit has support for just four of them
14:07.29dlomanyuppers :)
14:07.50brlcadk
14:08.07dlomanthe OCD in me couldn't stand the fact that jbrlcad is linked against libraries that are only stored in 'their' private repositories
14:08.46dlomanso i pulled the antiquated version of jScience (4.3.1) and checked it into the jBRLCAD module.
14:09.02brlcadsaw that but was more referring to a commit I saw yesterday
14:09.08dlomanthis way, 'anyone' can compile jbrlcad properly.
14:09.10dlomanwhich one?
14:09.15brlcadlooked like you're using jbrlcad in the java bridge to GS?
14:09.36dloman...not to my knowledge.  That's not my intent.  Likely bad wordage on my part then.
14:09.46dlomanIm not very good at engrish
14:10.29brlcadr43125
14:10.38brlcad"Keep it simple and, rather than copy classes that are under development, make jBRLCAD an dependency.  Hopefully this will change in the near future."
14:11.31dlomanwas talking about the interface that Ron created in jbrlcad/src/geometryservice
14:11.47dlomanthats the 'interface' we are both coding to.
14:12.10dlomansince its likely going to change, i figured copy/paste from jbrlcad into rt3 was a maintenance issue.
14:12.30dlomanI need to work with Ron on getting all the java source into one place.
14:13.03brlcadwhere the java code lives isn't really a major concern
14:13.34dlomantrue, but if its living in two places, that's annoying and makes life harder.  But that's my problem =D
14:13.36brlcadit's the reliance on there basically needing to be a librt written in java (which is basically what jbrlcad is)
14:14.37dloman... that's 'their' issue... right?
14:15.55brlcadwell, yes and no -- more than likely a misuse of the geometry service since it's supposed to avoid managing geometry on their end
14:16.05brlcadgeomcore/trunk/src/interfaces/java
14:16.12brlcadis that what ron is working on?
14:16.24brlcador is that the bridge you're working on?
14:21.38dlomansorry, got attacked by red tape again
14:21.52dlomangeomcore/trunk/src/interfaces/java is what I/we are working on
14:22.16dlomanRon checked his 'bridge definition' into jbrlcad
14:22.31brlcadso r43125 applied to that path and is where you have the comment about it using jbrlcad
14:23.05dlomancorrect.  in jbrlcad/src/main/org/brlcad/geometryservice
14:23.27dlomanthere is a java Interface (aka pure virtual class) called GeometryService.java
14:23.31brlcadif it's using jbrlcad, then it sounds like there's a problem -- what's it using?
14:24.20dlomanrather than copying that file over to geomcore/src/interfaces/java, i chose to simply make jbrlcad an ext dep untill we can get all the java code into one place.
14:24.22brlcadthe issue is the dev path forward -- if it's using it for geometry management, while only supporting 10% of geometry, then there's a future cost that will have to be realized before it's complete
14:24.29dlomanits a temporary thing for now.
14:24.46dlomanheh, you're way over thinking it :)
14:24.52brlcadprobably
14:25.13dlomani just need that file and don't want to (possibly) dev against antiquated Interface
14:25.29brlcadjust trying to understand what's going on, since this is potentially a low risk / high risk changer that I'd have to report on and/or address
14:25.41dlomanits a non-factor
14:25.48brlcadso if it's just that one interface, why not move it?
14:26.11dlomancause 'they' need it to, and 'they' are developing in jbrlcad module
14:26.19dlomans/to/too/
14:29.02brlcadsounds like something that will need to be discussed in more detail
14:29.19brlcadthat's their perrogative, but implies the GS isn't doing something they need
14:30.32brlcador that they're crossing over into geometry management land on the java side, which they're not supposed to be doing
14:31.53brlcadeither way -- a "GeometryService" class makes no sense in jbrlcad other than as a commit location for all java code
14:32.52brlcadit'd imply either moving the java code you're working on over to the jbrlcad module or moving that class out of jbrlcad into where you're using it and providing it as an interface from there
14:33.32brlcadI suspect it was just added just as a dumping ground for all geometry-related java code, not because it made sense
14:34.57dlomannaming-wise, I agree.  GeometryService is a rather incorrect name for an Interface that will be sitting in their code base
14:36.05dlomanGSAccessPoint perhaps
14:36.45brlcadeven with that name, that doesn't really have anything to do with "jbrlcad"
14:36.54dlomantrue :)
14:37.08brlcadit's a GS thing so it should live with the GS code
14:37.57dlomani think i am going to 'out-dev' them rather rapidly, so I'll likely just take any/all GS related java code out of jBRLCAD module anyways.
14:38.58brlcadit's basic "separation of concerns"
14:39.18brlcadsounds like a communication needing to be had regardless
14:39.42dlomanagreed.  I'll zip an email up to Ron John (*snicker*) or walk up there later
14:40.24*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:41.43CIA-53BRL-CAD: 03brlcad * r43159 10/brlcad/trunk/misc/debian/application-x-brlcad-extension.xml: set eol-style
14:42.02brlcad15 minute commit ruined by a single line ending failure
14:42.52dlomanhttp://assets.head-fi.org/f/fd/fd9be1b5_fuuuuuuuu.jpg  =D
14:43.50CIA-53BRL-CAD: 03davidloman * r43160 10/geomcore/trunk/src/interfaces/java/.settings/ (. org.eclipse.jdt.ui.prefs): Putting in Eclipse .settings directory. Contains project settings that are not machine specific, but allows for auto insertion of BRLCAD header.
14:45.21dlomanFYI, Ed's in today.
14:47.04CIA-53BRL-CAD: 03davidloman * r43161 10/geomcore/trunk/src/interfaces/java/auto-props.cfg: Update sample auto-props file with more mime-types.
14:49.53CIA-53BRL-CAD: 03davidloman * r43162 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (9 files in 3 dirs): Clean up existing and add missing headers.
14:59.35brlcaddloman: heh, what's with the sample auto-props?
15:00.47dlomangetting autoprops on winderz is a PITA, especially here at work.  so i figgered i'd put in a file to help
15:00.52brlcadmuch more extensive "sample" on the website: http://brlcad.org/wiki/Mime-types
15:01.55dlomankk, i'll link that.  danke.
15:03.48brlcadbegins final release distcheck
15:04.37dlomanthe word 'distcheck' still makes me take look twice
15:06.33brlcadyou have to look twice to find it?
15:06.45brlcadoh SNAP! no he didn't
15:07.17dlomanohnoe u dint!  (repeat x4)
15:09.23CIA-53BRL-CAD: 03brlcad * r43163 10/brlcad/branches/STABLE/ (4855 files in 354 dirs): merge trunk to STABLE from r41558 to HEAD r43158
15:18.04starseekerbrlcad: heh - ruined commits due to prop issues suck - I still wish svn let us check that before we go through the network process...
15:18.18starseekerespecially fun when upgrading tcl/tk
15:21.55``Erik*readreadread* np my ass
15:23.39dlomaneh?
15:25.03``Erikdlo: I think, uh, we'll move GS to bu, then fix win32 bu threading
15:25.20dlomanokie.
15:25.33dlomanI was just thinking about all the areas that QT is in
15:25.41dlomanand realized its in the threading also.
15:25.51``Erikjbrlcad is, uh, ... probably not very relevant
15:28.42``Erikaight, all caught up
15:29.10``Erikyeh, I'm de-qt'ing it pretty heavily, it winds all up and down, but we'll get there :) 'sall good
15:30.22``Erik(the np comment was about tesselation, I'm fairly certain it's not np, I'm thinking more in the n^2 or nlgn if done right... we have a feeble implementation)
15:38.58CIA-53BRL-CAD: 03starseeker * r43164 10/geomcore/trunk/src/other/sqlite/ (CMake/ CMake/ResolveCompilerPaths.cmake CMakeLists.txt): Try looking for dl for sqlite
15:41.26starseekerdloman: does that help?
15:41.33dlomanone sec
15:42.43dlomanSure does!  *thumbs up*
15:47.52CIA-53BRL-CAD: 03starseeker * r43165 10/geomcore/trunk/cmake/FindTCL.cmake:
15:47.52CIA-53BRL-CAD: Ironically, our new FindTCL isn't suitable for finding BRL-CAD's tcl/tk, since
15:47.52CIA-53BRL-CAD: it requires the .sh config files from Tcl and the new CMake build isn't
15:47.52CIA-53BRL-CAD: generating or installing them (did our autotools build, for that matter?). Need
15:47.52CIA-53BRL-CAD: to have the CMake build for tcl/tk generate those .sh files
15:55.38``Erikheh
16:08.03CIA-53BRL-CAD: 03Dloman 07http://brlcad.org * r2468 10/wiki/NetMsgTypes: Update MsgType chart with accurate info.
16:09.12CIA-53BRL-CAD: 03erikgreenwald * r43166 10/geomcore/trunk/ (89 files in 9 dirs): removal of some unnecessary QT-isms
16:09.17CIA-53BRL-CAD: 03Dloman 07http://brlcad.org * r2469 10/wiki/NetMsgTypes: Changed verbage and added 8byte generic msgtype
16:34.09CIA-53BRL-CAD: 03Dloman 07http://brlcad.org * r2470 10/wiki/NetMsgTypes: Typo fix
16:39.52CIA-53BRL-CAD: 03davidloman * r43167 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (NetMsgFactory.java msg/NetMsgTypes.java): Sync msgTypes with GeomCore module.
17:15.22*** join/#brlcad jay_ (~jay@212.96.10.253)
17:18.00jay_hello
17:19.35jay_you guys know of any linux architectural CAD app?
17:55.36starseekerjay_: depends on what you're after - commercially, there's this  http://www.cycas.de/
17:56.24starseekermaybe this is of interest?  http://sourceforge.net/projects/sweethome3d/
17:59.16CIA-53BRL-CAD: 03erikgreenwald * r43168 10/geomcore/trunk/src/utility/DataStreamUtils.cxx: fix ambiguous overload error
18:03.28brlcad``Erik: with floating point math, solving boolean evaluation for polygonal topology is not just n^2 even though the core algorithm is
18:03.31starseeker``Erik: that's got it on the mac
18:04.45brlcadit becomes a search problem, you have to make blind guess decisions at which point there's no longer a single "final solution" .. there's a set of solutions and you're looking for a valid solution, which is not easy
18:05.19starseekerstill one in Linux - GenericEightBytesMsg.c:31: prototype not matching
18:05.45starseekererror: prototype for 'GenericEightBytesMsg::GenericEightBytesMsg(uint32_t, quint64)' does not match any in class 'GenericEightBytesMsg'
18:06.33starseekerfew others...
18:07.55brlcadconsider the simple example of the subset sum problem, which is np-complete -- it states given a set of integers, do any non-empty subset of them add up to zero
18:08.49brlcadthat same characterization can be made of vertices during evaluation, given a set of points, do any non-empty subset of them coincide (i.e., are the same point)
18:09.55brlcadthat and other hard questions get repeatedly asked, a decision is made, and the underlying O(N^2) algorithm continues to the next edge/vertex/face/shell/object
18:12.58CIA-53BRL-CAD: 03davidloman * r43169 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/RemoteNodeNameSetMsg.java: Implement RemoteNodeNameSetMsg in java.
18:14.54jay_starseeker: thnx
18:21.01dlibrlcad, do you mean any repeated point?
18:21.22dlibrlcad, or give a list of subsets, any repeated?
18:21.30CIA-53BRL-CAD: 03erikgreenwald * r43170 10/geomcore/trunk/src/libNet/PortalManager.cxx: add missing parameter
18:25.05CIA-53BRL-CAD: 03erikgreenwald * r43171 10/geomcore/trunk/src/ (3 files in 2 dirs): snprintf type fixes
18:32.49brlcaddli: given a set of points, which are equal to other points within a given tolerance
18:34.45brlcadeven with exact non-floating point computation, if you add a "within tolerance" qualifier, you suddenly have np-hard decision searching
18:35.04brlcadfloating point just adds an implicit tolerance on top of a geometric tolerance
18:36.03dlibrlcad, partition the coordinates according the tolerance, so, from real x -> integer i_x = [ x/dr +0.5], now, you only have to search within i_x plus/minus 1, j_y plus/minus 1, etc. O(N)
18:40.16dlibrlcad, if we can waste on memory, partition points to a 3d array, search is still O(N)
18:42.19CIA-53BRL-CAD: 03erikgreenwald * r43172 10/geomcore/trunk/ (40 files in 9 dirs): switch from QT typedefs to standard typedefs
18:43.12dlibrlcad, suppose the wanted tolerance is tiny, partitioning to 1/dr is impractical, we can simply use an intermediate (dr0), now, only have to search within neighbours of (dr0), divide and conquer
18:57.11CIA-53BRL-CAD: 03starseeker * r43173 10/geomcore/trunk/cmake/ (10 files): Clean out some of the unneeded .cmake files - may be more scrubbing to do here.
18:57.28brlcaddli: the tolerance is generally very very tiny in relation to the value
18:57.53brlcadmoreover, depending on how you group points will affect the resulting decision
18:57.58dlibrlcad, then, use a reasonable intermediate dr0
18:58.29brlcadthere is no definition of reasonable that applies to arbitrary geometry
18:58.36dlibrlcad, only search within neighborhood of dr0
18:58.46CIA-53BRL-CAD: 03starseeker * r43174 10/geomcore/trunk/ (12 files in 9 dirs): Start working on getting the tests running again - leave them off for now, as there's a fair bit of work to do.
18:58.47brlcaddefine neighborhood
18:58.55dlibrlcad, no, but as far as it's fast for most cases
18:59.13brlcadso you get a wrong answer fast .. that's not very useful :)
18:59.31dlibrlcad, no, this algorithm doesn't get any wrong answer
18:59.41brlcadthis is a problem best explained with a white board
18:59.50dlibrlcad, anything outside of dr0 wont be within dr
19:00.17brlcadif you have a proof, then you'd have a ground-breaking research paper -- the geometry is nowhere near as rigorous or clean as it sounds like you're presuming
19:00.46brlcadthe tolerance has to be big enough so points will merge together, this is a good thing
19:01.01brlcadbut too big, and it'll join topology that should not be joined
19:01.34brlcadin practice that is a weighted local tolerance that might take curvature, topology, and other factors into account
19:01.48brlcadjust assuming a hard 0.000# tolerance just doesn't work
19:01.56brlcadno matter how small you make it
19:03.07brlcadand it STILL doesn't address the impact of deciding a coinciding point that are within tolerance
19:03.22brlcadconsider three points: A, B, C
19:03.24dlibrlcad, http://num-meth.srcc.msu.ru/english/zhurnal/tom_2010/v11r135.html
19:03.42brlcadA is within tolernace of B, B is within tolerance of C, but A is not within tolerance of C
19:04.37brlcadhow you join those will result in different topology, and there is no knowledge about which choice is right other than the final geometry being considered "valid" or not
19:04.49dlibrlcad, I'm still not clear whether voronoi cell is relevant here, voronoi is n log(n), more robust than neighbor searching algorithms
19:06.37brlcaddli: not sure what you're trying to show with that paper, but at a glance it looks like a simple spatial partitioning of your comparisons -- that's merely optimization (and not particularly relevant since you're generally not comparing that many neighboring points)
19:07.17dlibrlcad, neighbor searching is not robust, I know that, but voronoi is robust
19:07.19brlcadit's the same problem even if you try to carve up voronoi neighborhoods
19:07.47brlcadyou have to decide where to split and there is no definition of how/where to split
19:07.58brlcadtake that three-point example -- that's about as basic as it gets
19:08.34dlibrlcad, original voronoi problem doesn't require definition of neighbors, http://en.wikipedia.org/wiki/Voronoi_diagram
19:09.14brlcadhow is that helping?
19:09.24dlibrlcad, it will generate voronoi diagram on any 3 points on plane, I'm not clear how the algorithm with behavior with repeated points
19:09.42brlcadhow is that helping?
19:09.59dlibrlcad, let's suppose no repeated points, all points a different by tiny distance
19:10.24brlcadsure
19:10.31dlibrlcad, then, generate voronoi cells, find the small cells, test the points with its neighbors (as defined by voronoi)
19:11.02brlcadtest them for what?
19:11.31brlcadtake the simple ABC case, what's being tested?
19:11.32dlibrlcad, for each point, get the distance to its voronoi neighbors
19:11.46brlcadokay, that's distance AB, BC, and AC
19:11.54brlcadnow what?
19:12.10dlibrlcad, now, decide whether within tolerance
19:12.26brlcadokay, AB are within tol, BC are within tol, AC are not
19:12.26dlibrlcad, the good thing is that, after voronoi, it's O(N)
19:12.28brlcadnow what?
19:12.54dlibrlcad, oh, that's another question :(
19:13.12brlcadfollow this through, you're still not getting the problem -- I know what voronoi are and do, but finding neighbors isn't the problem
19:13.44dlibrlcad, I thought the problem is finding neighbor, now, it's the definition of neighbor
19:13.52brlcadbingo
19:15.28brlcadtopologically with A, B, and C, you might want to join A+B and keep C separate .. or join B+C and leave A separate .. or loosen the tolerance and join A+B+C
19:15.34dliso, what about just give it tighter tolerance? then, just randomly combine points, until no overlap exists
19:16.07brlcadtighten the tolerance, and you avoid joining A B and C altogether, and your topology is broken/invalid
19:16.52brlcadin practice, you'll want either [A+B, C] or [A, B+C] .. but you just don't know which one is right (or if either of them is right)
19:17.13brlcadgenerally one of them is right, the other is not but it becomes a decision tree
19:17.20dlibrlcad, no, I don't understand this. tighter tolerance shouldn't break anything
19:17.56brlcadunderstandable, hard to see with just three points
19:18.17brlcadtopologically, you're stitching together geometry -- polygon faces or spline surfaces
19:18.37brlcadyou're trying to decide whether polygon 1 attaches to polygon 2
19:18.53brlcadso you might compare the vertices of 1 with the vertices of 2
19:19.35brlcadfor solid geometry, all meshes must enclose space
19:19.44brlcadotherwise they are just infinitely thin dangling faces
19:20.37dlibrlcad, yes, I see the rough picture now
19:20.41brlcadif you tightened your tolerance to .. 0 .. then only vertices that are exact-exact matches join (which isn't practical with floating point), so it basically won't think those two faces are topologically connected when they should be
19:21.18brlcadloosen the tolerance too much and you end up joining faces that are "close" but shouldn't be joined _toplogically_
19:21.52brlcadit really is a pretty fucking hard problem (pardon my language) to make robust
19:22.29dlibrlcad, I suppose to write a function to generate intersection, so, I have to handle this problem
19:22.47brlcadin an ideal world, you'd keep track of your decision tree as you progress through the evaluations, use a floating/variable tolerance that adjusts to topology, and have a means to unroll back through decisions when you end up with invalid results
19:23.22brlcadstrictly speaking yes you will, but it's not nearly as bad for surface surface evaluations
19:23.53brlcadit's a problem for the code that will USE your surface-surface function :)
19:24.30dlibrlcad, let try and see how it works out
19:24.35CIA-53BRL-CAD: 03starseeker * r43175 10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: Make a stab at GeometryServiceTest
19:25.48brlcaddli: mind you, in practice, you can generally find a "sweet spot" tolerance or set of tolerances that will make it all work and evaluate correctly for a given input -- my ranting is merely addressing the np-hardness of the underlying decision problem
19:26.06brlcadyou can make AB/BC/AC decisions for 99% of geometry just fine
19:26.48brlcadthe issue is usually error accumulation, that's where NMG (our polygon library) has problems
19:27.10dlibrlcad, if so, can we use integer instead?
19:27.14brlcadlike I said earlier with the [A+B, C] or [A, B+C] decision case, you'll probably pick one of those two results
19:27.32brlcadbut whether you join A+B or B+C .. what value do you actually use?
19:27.48dlibrlcad, 64bit integer would be good enough
19:27.52brlcadA+B -> A's value?  B's value?  the midpoint of A+B?
19:28.09brlcadall three options results in point drift
19:28.54dlibrlcad, still error accumulating
19:31.52CIA-53BRL-CAD: 03erikgreenwald * r43176 10/geomcore/trunk/tests/ (libEvent/BasicEventTest.cxx utility/configTest.cxx): de-QT some more
19:34.05brlcaddli: yep, the all _potentially_ accumulate error
19:34.55brlcadif "A" is right, then C won't be merged ... if you pick B's value or midpoint of A+B, then you might actually even now be within tolerance of C .. which effectively collapses to A+B+C
19:36.13brlcadwhether you use floating point or integer comparisons won't really make much of a difference is my gut feeling.  it might give you locally stable behavior but not algorithmic stability
19:36.56brlcadthe best results I've seen use interval arithmetic, which can be done with floating just fine
19:37.12brlcadit's basically a way to track the error
19:38.30brlcadyou can get the same result by recording a ULP and the local per-vertex error
19:44.17dlibrlcad, instead of seeing error accumulating, I feel it can be self-healing, to adjust points according to the direction/side of solid
19:45.03dlibrlcad, whatever the adjustment, it never gives broken topology
19:46.30CIA-53BRL-CAD: 03erikgreenwald * r43177 10/geomcore/trunk/tests/utility/CMakeLists.txt: copy test config file to bin dir
19:51.01CIA-53BRL-CAD: 03starseeker * r43178 10/geomcore/trunk/ (6 files in 4 dirs): Gets the tests almost building, although not sure how correct the changes are.
19:51.19brlcaddli: that's not a bad idea, and probably possible, but definitely not easy
19:51.41brlcadour NMG library does something like that now, trying to make sure it's never broken as evaluation progresses
19:52.34dlibrlcad, nice, good enough for me to try
19:52.40brlcadthe problem is that it's still a decision tree and there are invalid decision nodes that might lead to valid (desireable) final states, or numerous competing valid states ( like [A+B, C] or [A, B+C] )
19:53.55CIA-53BRL-CAD: 03starseeker * r43179 10/geomcore/trunk/tests/libEvent/BasicEventTest.cxx: There we go - get BasicEventTest compiling too.
19:56.49CIA-53BRL-CAD: 03davidloman * r43180 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (AbstractNetMsg.java RemoteNodeNameSetMsg.java): Updated AbstractNetMsg's deserial cstr to take the msg type. Type will be deserialized in order to determine how to construct an AbstractNetMsg object anyways, so it needs to be set by a subclass.
19:59.43CIA-53BRL-CAD: 03brlcad * r43181 10/brlcad/trunk/src/libfb/if_ogl.c: linux is using __USE_BSD and __USE_XOPEN_EXTENDED in order to get to the getpagesize() declaration.
20:00.35CIA-53BRL-CAD: 03davidloman * r43182 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java: Add a static for libpkg's header size.
20:00.55starseekerGenericEightBytesMsg.cxx:44: error: no match for 'operator>>' in '* ds >> ((GenericEightBytesMsg*)this)->GenericEightBytesMsg::data'
20:01.55CIA-53BRL-CAD: 03brlcad * r43183 10/brlcad/branches/STABLE/src/libfb/if_ogl.c: merge r43181 from trunk
20:02.26CIA-53BRL-CAD: 03erikgreenwald * r43184 10/geomcore/trunk/src/utility/Config.cxx: simplify and correct line parsing logic
20:03.26brlcadbah
20:20.56CIA-53BRL-CAD: 03brlcad * r43185 10/brlcad/trunk/src/libfb/if_ogl.c: it actually needs __USE_XOPEN and __USE_BSD to get to the decl, so add them both with ifndef protection. this suckage belongs in libbu.
20:21.54CIA-53BRL-CAD: 03brlcad * r43186 10/brlcad/branches/STABLE/src/libfb/if_ogl.c: merge r43183 from trunk for the getpagesize() fix when compiling with ogl enabled on linux
20:22.23epilegI want to improve the brlcad mime type on Linux. It appears that all geometry db files begin with "76 01 00 00 00 00 01 35 76". Is this correct?
20:24.02CIA-53BRL-CAD: 03davidloman * r43187 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NewSessionReqMsg.java: Implement NewSessionReqMsg in java.
20:26.29``Eriknot necessarily... 0x76 is the magic for our version 5 db, but the second byte is flag information
20:26.38``Erikum, include/db5.h shows the on disk header
20:26.56brlcadthe first 8 bytes should be right
20:27.22CIA-53BRL-CAD: 03davidloman * r43188 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/SessionInfoMsg.java: Implement SessionInfoMsg in java.
20:27.28brlcadbut yeah, that only applies v5 too -- v4 looks rather different
20:28.43epilegbut the db version is so variant?
20:29.28epilegand what's the header bytes on v4?
20:30.00brlcaddon't worry about v4, they're older files
20:30.58epilegjust for people who has some db v4 files
20:32.45brlcadif you really want to be flexible, you can only count on the first byte being 76 and the eigth byte being 35 for v5
20:35.12``ErikI don't think there is head magic for v4
20:35.31epileghmmmm, I'll try just for v5.
20:37.46brlcadv4 files start with an 'ident' record
20:38.12brlcadso it'll be something like 'I?v4'  49 01 76 34
20:38.44brlcadversion key again being 76 and 34
20:39.22``Erikshould probably have a bit more magic for v6 O.o
20:39.22epilegaha
20:40.35brlcadyeah, [0]==76 [7]==36 :)
20:41.02epilegfor v4?
20:41.09brlcadthat'd be "v6" :)
20:41.14brlcadwhich doesn't exist yet
20:41.33epilegops, ok
20:43.52CIA-53BRL-CAD: 03davidloman * r43189 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java:
20:43.52CIA-53BRL-CAD: Implement first pass at a GSConnection object. GSConnection contains a static
20:43.53CIA-53BRL-CAD: factory method that will create a GSConnection, handshake and authenticate with
20:43.53CIA-53BRL-CAD: a GS Server. Socketing is blocking as the responsibility for polling/selecting
20:43.53CIA-53BRL-CAD: is tossed to the user of this interface.
20:47.16brlcadinitial release build seems to work
20:47.57brlcadfunkyness in archer (rt crashes, display doesn't update on start) but rtwizard and mged seem to be doing alright
20:57.08CIA-53BRL-CAD: 03starseeker * r43190 10/brlcad/branches/cmake/include/config_win_cmake.h: This should be coming from src/other now...
21:37.19CIA-53BRL-CAD: 03brlcad * r43191 10/brlcad/tags/rel-7-18-2/: tagging release 7.18.2
21:53.26CIA-53BRL-CAD: 03brlcad * r43192 10/brlcad/trunk/include/conf/PATCH: release is tagged, bump to 7.18.3
21:53.57CIA-53BRL-CAD: 03brlcad * r43193 10/brlcad/trunk/ (NEWS README): prepare for next expected 7.18.4 release
21:58.55brlcadwould someone else mind sanity testing the 7.18.2 tag?
21:59.11brlcadBRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.2 is posted (20110209)
22:06.56brlcadhave at it ``Erik
22:07.09starseekerbrlcad: I'm compiling now
22:09.43brlcadthx
22:15.38``Erikhm, solids.sh regress 3 off by many
22:15.55``Erikon 32b fbsd, but not on 64b linux
22:16.00``Erikinteresting
22:17.42brlcadyeah, I've seen that one before too
22:18.33brlcadI put a note in the BUGS file for it, been failing with an (one) off-by-many error on an optimized mac build
22:18.57brlcadiirc it was grazing the edge of an arb8
22:22.18CIA-53BRL-CAD: 03starseeker * r43194 10/brlcad/branches/cmake/src/other/ (tcl/CMakeLists.txt tk/CMakeLists.txt): Looks like these flags may be causing trouble - comment out for now...
22:27.38starseekerurm.  Getting Itcl_Init ERROR
22:28.30starseekerlooks like libitcl3.4.la is there, but not the .so
22:31.13starseekerinstalled version does OK though
22:31.17starseekerjust build dir
22:31.43``Erikdoes a fresh checkout to see how bad he broke it
22:32.13*** join/#brlcad CIA-62 (~CIA@208.69.182.149)
22:43.19CIA-62BRL-CAD: 03starseeker * r43196 10/brlcad/branches/cmake/src/other/ (tcl/CMakeLists.txt tk/CMakeLists.txt): Let's try this again without nuking all the TK_FLAGS in the process...
IRC log for #brlcad on 20110210

IRC log for #brlcad on 20110210

00:12.08starseekernotes this might be a useful tidbit down the road with ogre: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=60677
00:28.33CIA-62BRL-CAD: 03starseeker * r43197 10/geomcore/trunk/include/ (DataStreamUtils.h Event.h JobManager.h Logger.h NetMsg.h): Should probably add some HAVE_* logic for this, but need some stdint and stdio inclusions
01:07.18starseekerhumph - the beta 8.6 tcl/tk link on the main website dates to Dec 2008
01:09.32starseekereyes the new sf.net/projects/brlcad look after the update...
01:56.22*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:57.40*** part/#brlcad epileg (~epileg@unaffiliated/epileg)
04:03.07CIA-62BRL-CAD: 03starseeker * r43198 10/brlcad/branches/cmake/ (3 files in 3 dirs): Instead of one target per file, try to get one per list working for data copying. More reasonable target count, but some of them aren't terminating even though files appear to be copies successfully.
04:19.38CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2471 10/wiki/Community_Publication_Portal: 7.18.2 posted
04:46.56brlcadnice refactoring on the de-qt'ing ``Erik
05:08.41*** join/#brlcad PrezKennedy (MK@whitecalf.net)
06:25.53*** join/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl)
07:11.36CIA-62BRL-CAD: 03jordisayol * r43199 10/brlcad/trunk/ (21 files in 4 dirs): add magic mime-type association to geometry db file in GNU/Linux
07:11.53*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
07:27.31*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
07:46.10*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
12:52.45*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:11.51*** join/#brlcad kanzure (~kanzure@131.252.130.248)
13:19.29*** join/#brlcad kanzure (~kanzure@131.252.130.248)
15:50.56starseekerHuh, interesting:  http://neugierig.org/software/chromium/notes/2011/02/ninja.html
16:06.28brlcadwhich part, someone reinventing the wheel or that a reduction of a few seconds off a short build is significant? :)
16:57.09*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
17:36.46starseekerbrlcad: more the minimalist nature and the possibility of something like CMake generating it to make long builds faster
17:43.45CIA-62BRL-CAD: 03erikgreenwald * r43200 10/geomcore/trunk/src/ (CMakeLists.txt coreInterface/): remove coreInterface
17:48.54brlcadcoreInterface for all intensive purposes is the Geometry Engine
17:51.33``Erikeh? it's not in the current build path, I thought it was Dan's thing?
17:51.53brlcadall true
17:52.14brlcadbut it's still basically almost the exact embodiment of what the GE is supposed to be
17:52.34brlcadan OO wrapper over librt, similar to the ACIS engine
17:52.56brlcadno service/user/network concepts, that's all GS territory
17:53.38``Erikvs src/GS/libGeometry ?
17:53.49brlcadnot saying it needs to be in geomcore, but it definitely is the direction we should be moving towards
17:53.59brlcadright
17:54.31``Erik*shrug* it's in the history as well as rt^3, figure it out when we get there, I guess
17:54.53starseekerwhat's the relationship with src/GE ?
17:55.52brlcaddave really didn't look at coreInterface afaik, as he doesn't yet have it doing any geometry processing .. the little bit that is in there he rolled on his own
17:56.15brlcadcoreInterface, however is MUCH farther along and in the right direction
17:56.21brlcadit really should just be named "GE"
17:56.49brlcadmerging it in should be on our short-term todo
17:56.51starseekernods - so coreInterface -> GE, merge in whatever bits in current GE might be needed
17:58.29brlcadit really is a brilliantly clean design, daniel did some nice work there leveraging libbu, libbn, librt, and libwdb
17:58.55brlcadhas proper bu exception handling, uses rt_db_internal data types as private member data, good object relationships
18:00.11starseekercool
18:01.11brlcadif you look in the current GE/libGeometry work, it's basically all stubbed empty and unused or it's old classes that I wrote years ago when starting the GE
18:02.38brlcadthat was way back when the goal was focusing on a ray trace service (hence the raytrace daemon, rt^3d, and the database daemon, rt^3dbd)
18:09.50starseekerbrlcad: ok, I'll take a look at at moving coreInterface to GE
18:12.03brlcadsome of what's in libGeometry could be merged, other parts can be removed .. would take some basic code review to see what's of value
18:15.30CIA-62BRL-CAD: 03bob1961 * r43201 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Reset output handler when going to/from a separate command window configuration.
18:32.27CIA-62BRL-CAD: 03erikgreenwald * r43202 10/geomcore/trunk/ (57 files in 12 dirs): Eliminate QT map/list/string/stringlist in favor of std::
18:36.14brlcadwoot
18:37.27brlcadthinks it's hilarious that most of the std:: conversions for qt are search-n-replaceable .. there's really no reason to replicate the standard library these days
18:41.33``Erikmostly :%s, but some algorithmic changes had to happen, too... and some still need reworked
18:47.54CIA-62BRL-CAD: 03starseeker * r43203 10/brlcad/branches/cmake/ (3 files in 3 dirs): (log message trimmed)
18:47.54CIA-62BRL-CAD: Use a sentinel file instead of listing all of the output directories - approach
18:47.54CIA-62BRL-CAD: suggested by David Cole on the CMake list, seems to work and build doesn't keep
18:47.54CIA-62BRL-CAD: recopying files. Also tweak the tclscript routines to depend on the file used
18:47.54CIA-62BRL-CAD: by the copy target. Disable the option to turn targets on/off - now needed for
18:47.55CIA-62BRL-CAD: tclscripts build, no longer spewing one target for file, and anyway the build
18:47.56CIA-62BRL-CAD: should ensure changes made to data files in the src dir are reflected in the
21:11.49CIA-62BRL-CAD: 03starseeker * r43204 10/geomcore/trunk/ (data/ m4/ media/ misc/ sandbox/): Remove some more stuff that's either unused or not related to geomcore
21:14.17CIA-62BRL-CAD: 03starseeker * r43205 10/geomcore/trunk/src/GE/coreInterface/ (22 files): Put coreInteface back as a subdirectory of GE - eventually this should become the core of GE
22:32.30CIA-62BRL-CAD: 03erikgreenwald * r43206 10/geomcore/trunk/src/utility/Config.cxx: eliminate QFile/QFileInfo in favor of standard ansi C
23:13.04*** join/#brlcad dli (~dli@dyn-216-076.wireless.concordia.ca)
IRC log for #brlcad on 20110211

IRC log for #brlcad on 20110211

00:01.15CIA-62BRL-CAD: 03starseeker * r43207 10/geomcore/trunk/cmake/ (FindBRLCAD.cmake FindCPPUNIT.cmake): Start playing with FindBRLCAD.cmake - still quite a lot to do here, this is an intermediate state.
00:22.06CIA-62BRL-CAD: 03jordisayol * r43208 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): correct an error on deb and rpm scripts
00:29.42starseekerHmm, interesting:  http://www.geometrictools.com/
00:31.15starseekerlot of writeups:  http://www.geometrictools.com/Documentation/Documentation.html
00:31.52starseekersweet, boost license
00:53.30*** part/#brlcad cosurgi (~cosurgi@atak.bl.pg.gda.pl)
00:59.30brlcadstarseeker: nice link
00:59.58starseekerwas poking around looking for stuff to help Richard
01:00.26brlcadhe's stuck?
01:00.39brlcadhe's certainly stopped committing
01:01.07starseekerhe's looking for a really robust line-line intersection routine (or more correctly, closest distance between two 3D lines)
01:01.18dlibrlcad, I'm reading the files in src/pro-db, need more time for understanding, but I can see the complexity of work done is still quite light, like 2,000 lines to me
01:01.33brlcadstarseeker: and libbn's is insufficient?
01:01.39starseekerapparently
01:02.07starseekerhe wasn't set up to take me through all the details tonight
01:02.12dlibrlcad, also, the idea of "self-healing" I mentioned was already there, "linear perturbation" in the poster link you posted
01:02.58brlcadstarseeker: if ours isn't sufficient, then he should be able to characterize how/why and fix it .. not duplicate the code with another function
01:03.23brlcadvalidating ours against an algorithm would be cool, but definitely shouldn't just be snarfing in another function
01:03.46brlcadrewriting ours would even be fair game -- that's the point of the testing framework
01:03.49starseekernods - he can't do that with that link anyway, that's C++ code
01:04.38dlibrlcad, I need to understand how it works now, then, I will try to see what is a good approach from here
01:04.41starseekerI think he's identified come failing test cases but isn't sure what to do to fix them
01:04.48brlcadhttp://www.geometrictools.com/Documentation/DistanceLine3Line3.pdf isn't c++
01:05.10starseekertrue - I sent him that link to see if it would help
01:05.26brlcaddli: sounds good
01:05.58brlcaddli: I'd hope it's not too heavy .. then people's brains shut off and they tend to start from scratch
01:06.17brlcadwasted effort
01:07.22starseekerI just ment he couldn't snarf the geometrictools code directly - he'll still need to figure out how to do it in our code
01:07.47dlibrlcad, should be fine, I expected like 10,000 lines, it's not that bad, 2,000 lines, if comments not counted, and rewrite in C++ style (now, it's like C style C++), my guess is like 500 lines, fair for me to start
01:09.58brlcaddli: note that's just one function you're working on -- there's several other routines that will be needed later :)
01:11.51dlibrlcad, okay, I will concentrate on that part
01:12.33brlcadsurface,surface->curve is really surface,surface->surface|curve|point .. which is really also a parent case of surface,point->point + surface,curve->curve|point + surface,surface->surface|curve
01:12.57brlcadat least when you consider the grazing cases
01:14.59dlibrlcad, I added this to my note, talk to you later
01:30.19starseekerhuh http://code.google.com/p/poly2tri/ - I don't recall stumbling on that before
01:35.50starseekerthis one too http://www.netlib.org/voronoi/hull.html
03:50.40brlcadthe first is interesting, but doesn't look too much different than our current triangulation
05:06.54CIA-62BRL-CAD: 03brlcad * r43209 10/brlcad/trunk/doc/deprecation.txt: SMALL was deprecated a long time ago, but is a minimally impacting change
05:08.38CIA-62BRL-CAD: 03brlcad * r43210 10/brlcad/trunk/include/vmath.h:
05:08.38CIA-62BRL-CAD: provide a ZERO() macro that corresponds with the EQUAL() macro. tolerance is
05:08.38CIA-62BRL-CAD: defined at compile-time so it's not the best to use, but still more reliable
05:08.38CIA-62BRL-CAD: than exact floating point comparisons. it'll also permit cleaning up numerous
05:08.38CIA-62BRL-CAD: NEAR_ZERO() callers that arbitrarily use SMALL, SMALL_FASTF, and
05:08.39CIA-62BRL-CAD: SQRT_SMALL_FASTF when the intent is just a nearness to zero.
05:25.50CIA-62BRL-CAD: 03brlcad * r43211 10/brlcad/trunk/src/libbu/units.c: convert from NEAR_ZERO() to ZERO()
05:26.54CIA-62BRL-CAD: 03brlcad * r43212 10/brlcad/trunk/src/libbn/ (9 files): lots of conversions from NEAR_ZERO() to the new ZERO() macro where the tolerance test is merely against SMALL_FASTF or used to test for zero-division.
05:28.06CIA-62BRL-CAD: 03brlcad * r43213 10/brlcad/trunk/src/anim/ (anim_fly.c anim_hardtrack.c): start of larger covnersion over to new ZERO() macro.
05:34.27CIA-62BRL-CAD: 03brlcad * r43214 10/brlcad/trunk/src/librt/ (49 files in 24 dirs): convert from NEAR_ZERO() to ZERO() where SMALL, SMALL_FASTF, and sometimes even where SQRT_SMALL_FASTF is used. simplify. reduction also made where intent seems to be a zero-test for a subsequent division.
07:53.54*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
10:49.23*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
11:48.39*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:06.40dlomanMernin all.
12:58.04*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:17.29CIA-62BRL-CAD: 03davidloman * r43215 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/ (. Main.java MinimalGSClient.java): Beginnings of a minimal test client. Gui looks ok but doesn't do anything.... yet
14:32.48CIA-62BRL-CAD: 03brlcad * r43216 10/brlcad/trunk/src/libged/ (21 files): another conversion from NEAR_ZERO() to ZERO() where SMALL, SMALL_FASTF, and sometimes where SQRT_SMALL_FASTF is used. simplify. reduction also made where intent seems to be a zero-test for a subsequent division.
14:35.15CIA-62BRL-CAD: 03davidloman * r43217 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (3 files in 2 dirs): Break out gui components into dedicated, individual subclasses of JPanel. This gives better control and expansion flexibility.
14:36.17CIA-62BRL-CAD: 03starseeker * r43218 10/brlcad/branches/cmake/src/other/openNURBS/ (opennurbs_array_defs.h opennurbs_math.h): Keep tripping on this - just move it, can always put it back if there's a need to keep it in opennurbs_math.h
15:10.42``Erikjabs brlcad with a pointy stick some
15:17.45CIA-62BRL-CAD: 03starseeker * r43219 10/brlcad/branches/cmake/src/ (41 files in 35 dirs):
15:17.45CIA-62BRL-CAD: Tweaks to get BRL-CAD compiling with the latest clang/clang++ - a few things
15:17.45CIA-62BRL-CAD: that look legit, lot of adding of UNUSED and removal of self assignments - if
15:17.45CIA-62BRL-CAD: there was a reason to avoid UNUSED in these cases will have to revert and try
15:17.45CIA-62BRL-CAD: something else. Somewhat mysteriously, bu_byte_offset didn't cause a compiler
15:17.45CIA-62BRL-CAD: failure - that's probably incorrect and we still need to do some sort of #if
15:17.48CIA-62BRL-CAD: defined(__clang__) specific logic there.
15:22.27*** join/#brlcad kanzure_ (~kanzure@bioinformatics.org)
15:22.27*** join/#brlcad roberthl (~robert@v001.rhl.me.uk)
15:22.27*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
15:22.27*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:22.27*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
15:22.27*** join/#brlcad PrezKennedy (MK@whitecalf.net)
15:22.28*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
15:22.28*** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no)
15:22.28*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
15:22.28*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
15:22.28*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
15:22.28*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
15:22.28*** join/#brlcad piksi (piksi@pi-xi.net)
15:25.37*** join/#brlcad d_rossbe1g (~rossberg@BZ.BZFLAG.BZ)
15:26.18*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
15:26.19*** join/#brlcad CIA-6 (~CIA@208.69.182.149)
15:27.00*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
15:29.31CIA-62BRL-CAD: 03starseeker * r43220 10/brlcad/branches/cmake/src/other/tnt/ (tnt_array1d.h tnt_fortran_array1d.h tnt_matrix.h): Whoops, missed a couple tnt tweaks
15:29.40CIA-6BRL-CAD: 03davidloman * r43221 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/CmdConsolePanel.java: Make default prompt work correctly.
15:31.05CIA-6BRL-CAD: 03davidloman * r43222 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClient.java: Remove antiquated JText* code
15:31.22CIA-6BRL-CAD: 03davidloman * r43223 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/RepositoryViewerPanel.java: Swap the JTextArea for a real JTree
15:34.14starseekersaddles up and heads in
16:25.24*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20110212

IRC log for #brlcad on 20110212

19:53.46*** join/#brlcad ibot (~ibot@rikers.org)
19:53.46*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
20:31.18brlcadepileg: is there a way to specify the dependencies instead of having them auto-specified via dh_shlibdeps ?
20:32.48brlcadfor .deb files we put on the website, it makes perfect sense for them to be --enable-all ... for integration with apt, it makes more sense to --disable-all and specify all dependencies
21:13.30epilegI'll change this, and for the next release, I'll try to compile then in a earlier release of ubuntu.
21:14.53epilegyes, manually
21:15.06epileg...about dependencies
21:17.34epilegbut the solid way is to create the deb in a earlier ubuntu/debian release, and auto detect dependencies
21:17.50epilegis just my opinion
21:31.48brlcadyou're managing it, so you get to decide .. they're both fine approaches for the project :)
21:32.03epilegthanks
22:10.49CIA-6BRL-CAD: 03brlcad * r43265 10/brlcad/trunk/include/vmath.h: big cleanup adding in missing 2D 'V2' and 4D 'H' macros that correspond with the 3D 'V' macros. incomplete, but adds a dozen or so that were missing.
22:11.21*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
22:14.24*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
23:20.18*** part/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
23:31.07*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
IRC log for #brlcad on 20110213

IRC log for #brlcad on 20110213

00:00.42*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
03:00.07starseekerO.o openNURBS 5.0 is out
03:00.28starseekerFeb 2nd apparently
04:07.10*** join/#brlcad ultra- (~no@cpe-65-25-205-157.new.res.rr.com)
04:07.13ultra-hi
04:07.20ultra-can someone answer a simple catia question?
07:59.24Ralithstarseeker: was that unexpected?
12:13.22CIA-6BRL-CAD: 03tbrowder2 * r43266 10/brlcad/trunk/src/nirt/nirt.c: quash C90 too-long-stringg warnings
12:33.11CIA-6BRL-CAD: 03tbrowder2 * r43267 10/brlcad/trunk/include/tie.h: correct macro for externing an int (tie_check_degenerate is not a function)
12:41.32louipcstarseeker: wasn't it opennurbs 5.0 before that as well?
13:02.50brlcadultra-: sorry, no
13:06.01brlcadunless you want to pay me their license fee, then it depends on the question.. ;)
13:33.21*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
13:43.15*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:44.23starseekerRalith: er, yeah - it's an update to 5.0
14:55.00starseekeroh, great... Nokia and Microsoft announce a "broad strategic partnership"
14:55.28starseekerconfound it, that's all we need a danger to Qt
14:56.07louipcyou think people won't fork Qt?
15:23.13*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
16:51.05ultra-brlcad sorry i just don't know where else to go with catia questions
16:51.09ultra-for a live chat, at least
17:02.08louipcultra-: shouldn't you get some kind of live support for the price you pay for that software? hehe
17:03.13ultra-<PROTECTED>
17:03.14ultra-i'm a student
17:04.10louipcah I guess you're supposed to ask the instructors then
17:09.16ultra-yeah
17:09.20ultra-class is only once a week
17:09.23ultra-i will figure it out :)
17:14.59*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
17:47.42*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
18:13.50starseekerlouipc: they probably will, but having all those full time professional developers was one of the major reasons for the polish of Qt across multiple platforms
18:15.04starseekerwould really prefer for Trolltech to be spun off from Nokia back to its own company
18:15.50starseekera fork would mean that the professionally developed changes to Qt would have to be merged into a diverging fork, much like the libreoffice/openoffice situation
18:16.26starseekerand unlike the openoffice setup, Qt has been developed quite effectively up until now
18:25.45CIA-6BRL-CAD: 03brlcad * r43268 10/brlcad/trunk/src/conv/Makefile.am: make iges and intaval dirs set through a variable so that they can be overridden (and skipped) during make
18:30.00CIA-6BRL-CAD: 03brlcad * r43269 10/brlcad/trunk/src/conv/Makefile.am: alpha order
18:32.38CIA-6BRL-CAD: 03brlcad * r43270 10/brlcad/trunk/src/irprep/firpass.c: index->idx
18:34.52starseekerat the very least, I hope an alliance of open source players can announce they'll take over if Nokia drops the ball
20:09.41starseeker``Erik: what was that you said about a McCLIM based gui? :-P
23:11.57CIA-6BRL-CAD: 03tbrowder2 * r43271 10/brlcad/trunk/src/librt/primitives/metaball/metaball_tri.c: cleanup format spacing per HACKING
23:34.12*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
23:35.09CIA-6BRL-CAD: 03tbrowder2 * r43272 10/brlcad/trunk/src/rt/main.c: cleanup format spacing per HACKING
IRC log for #brlcad on 20110214

IRC log for #brlcad on 20110214

01:20.36*** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1177593317.dsl.bell.ca)
05:44.06*** join/#brlcad Stattrav_ (~Stattrav@122.172.6.241)
06:41.48CIA-6BRL-CAD: 03brlcad * r43273 10/brlcad/trunk/ (12 files in 4 dirs):
06:41.48CIA-6BRL-CAD: implement an initial shp-g shapefile importer for BRL-CAD. this was developed
06:41.48CIA-6BRL-CAD: in less than a day during Civic Hack Day in order to visualize Baltimore City
06:41.48CIA-6BRL-CAD: data made available to the public. the converter takes the shapefile input
06:41.49CIA-6BRL-CAD: (using shapelib) and imports the data as sketch/extrude geomettry. sketches
06:41.49CIA-6BRL-CAD: working great, extrudes need some debugging love.
09:26.42*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:08.00*** join/#brlcad ibot (ibot@rikers.org)
10:08.00*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
10:52.40*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:59.39dlomanyawns.
12:11.53*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:14.39*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:23.50CIA-6BRL-CAD: 03davidloman * r43274 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/ (5 files in 2 dirs): Add stylized text printing.
12:25.35CIA-6BRL-CAD: 03davidloman * r43275 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClient.java: Comment out this local var for now. Will likely remove ActionListener implements in the near future.
13:26.33CIA-6BRL-CAD: 03tbrowder2 * r43276 10/brlcad/trunk/src/rt/heatgraph.c: eliminate unused variable
13:31.29CIA-6BRL-CAD: 03tbrowder2 * r43277 10/brlcad/trunk/src/rt/reshoot.c: eliminate unused variable\nclean up space format per HACKING
13:47.33CIA-6BRL-CAD: 03jordisayol * r43278 10/brlcad/trunk/misc/debian/ (6 files): add magic mime-type for geometry db files v4 on deb/rpm packages
13:58.51CIA-6BRL-CAD: 03jordisayol * r43279 10/brlcad/trunk/ (misc/debian/rules sh/make_deb.sh sh/make_rpm.sh): switch to build-in for all libraries in deb/rpm packages
14:16.18CIA-6BRL-CAD: 03d_rossberg * r43280 10/rt^3/tags/rel-7-18-2/: tag the C++ core interface with the corresponding BRL-CAD version (i.e. 7.18.2)
15:20.58CIA-6BRL-CAD: 03brlcad * r43281 10/brlcad/trunk/src/ (75 files in 27 dirs): convert the remaining NEAR_ZERO(val, SMALL_FASTF) callers to ZERO(val) since the tolerance bound is minimally-defined. lower maintenance, easier to read.
15:31.47CIA-6BRL-CAD: 03erikgreenwald * r43282 10/brlcad/trunk/src/rt/main.c: fix various cast issues and a missing paren.
15:34.13CIA-6BRL-CAD: 03erikgreenwald * r43283 10/brlcad/trunk/src/nirt/nirt.c: There is no USAGE or USAGE2 defined, assuming it's broken to the set of bu_log calls.
16:04.08CIA-6BRL-CAD: 03starseeker * r43284 10/brlcad/branches/cmake/ (114 files in 36 dirs): MFC r43283 - still need to add conv/shp to CMake logic
16:09.30``Eriksweet, pine segfault
16:09.35CIA-6BRL-CAD: 03tbrowder2 * r43285 10/brlcad/trunk/src/sig/dpeak.c: clean up space format per HACKING
16:09.58CIA-6BRL-CAD: 03tbrowder2 * r43286 10/brlcad/trunk/src/sig/dpeak.c: clean up space format per HACKING
16:10.58CIA-6BRL-CAD: 03tbrowder2 * r43287 10/brlcad/trunk/src/sig/dpeak.c: clean up space format per HACKING
16:11.09CIA-6BRL-CAD: 03tbrowder2 * r43288 10/brlcad/trunk/src/sig/dpeak.c: clean up space format per HACKING
16:18.56CIA-6BRL-CAD: 03tbrowder2 * r43289 10/brlcad/trunk/src/sig/dpeak.c: clean up space format per HACKING
16:36.40CIA-6BRL-CAD: 03tbrowder2 * r43290 10/brlcad/trunk/src/rt/heatgraph.c: correct check for non-negative floating point value
16:38.44CIA-6BRL-CAD: 03tbrowder2 * r43291 10/brlcad/trunk/src/rt/heatgraph.c: C90 prohibits mixed declarations and code
16:40.10CIA-6BRL-CAD: 03tbrowder2 * r43292 10/brlcad/trunk/src/rt/heatgraph.c: C90 prohibits mixed declarations and code
16:41.33CIA-6BRL-CAD: 03tbrowder2 * r43293 10/brlcad/trunk/src/rt/heatgraph.c: correct check for minimum floating point value
16:48.43CIA-6BRL-CAD: 03tbrowder2 * r43294 10/brlcad/trunk/src/sig/dmod.c: need definition of NEAR_ZERO macro
16:58.25CIA-6BRL-CAD: 03tbrowder2 * r43295 10/brlcad/trunk/src/sig/dmod.c: need comparisin of NEAR_ZERO with FLT_MIN
18:17.32CIA-6BRL-CAD: 03tbrowder2 * r43296 10/brlcad/trunk/src/irprep/firpass.c: use float equality comparison macros (with some space formatting along the way)
18:22.25CIA-6BRL-CAD: 03tbrowder2 * r43297 10/brlcad/trunk/src/irprep/firpass.c: more space formatting per HACKING
18:32.34CIA-6BRL-CAD: 03jordisayol * r43298 10/brlcad/trunk/sh/make_rpm.sh: add magic mime-type for geometry db files v4 on rpm packages
18:43.41*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
18:50.40CIA-6BRL-CAD: 03starseeker * r43299 10/brlcad/branches/cmake/src/conv/CMakeLists.txt: Add shp-g to cmake logic
18:51.40willdyeThanks for mentioning http://neugierig.org/software/chromium/notes/2011/02/ninja.html in this channel.  I didn't know about it, and now I'm very glad that I do.
18:54.26starseekerwilldye: how does it work?
18:54.27CIA-6BRL-CAD: 03starseeker * r43300 10/brlcad/branches/cmake/src/other/step/ (CMakeLists.txt include/scl_cf_cmake.h.in): Whoops - alter the file in the build dir, not the src dir
18:54.31starseekerhas yet to try it
18:57.27willdyestarseeker: Too soon to say if we'll use it here, but it looks very promising.  I don't handle the build system here at work, so the final decision won't be up to me, but anything that speeds up builds will be very welcome here.
18:58.02willdyeI forwarded it to the powers that be.  Time will tell if they decide to give it a try.
19:26.00starseekerwilldye: there's interest from a couple folks at getting CMake go generate ninja output, which is my main interest - in principle that would mean faster building with no extra work
20:11.20CIA-6BRL-CAD: 03starseeker * r43301 10/brlcad/trunk/src/other/step/ (CMakeLists.txt include/conf/ include/scl_cf_cmake.h.in): Fix step files in trunk
20:35.18CIA-6BRL-CAD: 03jordisayol * r43302 10/brlcad/trunk/sh/make_rpm.sh: corrects wrong mged icon file name
20:36.06CIA-6BRL-CAD: 03davidloman * r43303 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java: Put in a user overrideable PrintStream set to log to. Devauls to StdOut and StdErr
20:38.34CIA-6BRL-CAD: 03davidloman * r43304 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClient.java: Start wiring in the GSClient's ability to establish comms with a GS
20:45.30CIA-6BRL-CAD: 03davidloman * r43305 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (3 files in 2 dirs): Make all System.out and System.err calls go thru the assigned PrintStreams in GSStatics. Added in trapped Exception reason printing to aid in debugging.
20:59.54CIA-6BRL-CAD: 03Sean 07http://brlcad.org * r2473 10/wiki/NURBS_TODO: add a few references, space them out
20:59.57CIA-6BRL-CAD: 03davidloman * r43306 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/ (4 files in 2 dirs): Make command console style strings into statics and make all calls to printToConsole and printLnToConsole use these statics. This should minimize bugs later.
21:06.49CIA-6BRL-CAD: 03Sean 07http://brlcad.org * r2474 10/wiki/NURBS_TODO: turn them into sections so we have a table of contents
21:08.39CIA-6BRL-CAD: 03Sean 07http://brlcad.org * r2475 10/wiki/NURBS_TODO: remove superfluous bullets
21:08.58CIA-6BRL-CAD: 03Sean 07http://brlcad.org * r2476 10/wiki/NURBS_TODO:
22:23.39CIA-6BRL-CAD: 03starseeker * r43307 10/brlcad/branches/cmake/src/other/tcl/CMakeLists.txt: Don't override LIB_DIR if already set - need windows specific logic for this eventually.
23:01.13CIA-6BRL-CAD: 03128.63.32.5 07http://brlcad.org * r2477 10/wiki/NURBS_TODO: add link to Martin paper
IRC log for #brlcad on 20110215

IRC log for #brlcad on 20110215

01:26.52louipchmm step files are text eh
01:31.54*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
01:43.24*** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no)
02:58.15*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
03:05.09*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
05:07.39CIA-6BRL-CAD: 03Sean 07http://brlcad.org * r2478 10/wiki/NURBS_TODO: stub in the rest
05:35.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:50.38CIA-6BRL-CAD: 03Sean 07http://brlcad.org * r2479 10/wiki/NURBS_TODO: expand time estimates, references, and benefits on most tasks
07:18.40CIA-6BRL-CAD: 03brlcad * r43308 10/brlcad/trunk/src/irprep/firpass.c:
07:18.40CIA-6BRL-CAD: replace all of the NEAR_*() calls with an arbitrary FLT_MIN (which is basically
07:18.40CIA-6BRL-CAD: one ulp step up from 0) to their corresponding ZERO() and EQUAL() calls.
07:18.40CIA-6BRL-CAD: FLT_MIN shouldn't be used anyways unless 1ulp is the goal (in which case there's
07:18.40CIA-6BRL-CAD: a libbn function for it), SMALL_FASTF is our base computation tolerance.
07:19.44CIA-6BRL-CAD: 03brlcad * r43309 10/brlcad/trunk/src/sig/dmod.c: prefer ZERO() over NEAR_ZERO() when the tol is merely FLT_MIN or (better) SMALL_FASTF.
07:23.03CIA-6BRL-CAD: 03brlcad * r43310 10/brlcad/trunk/src/rt/heatgraph.c: <= and >= are still comparing floating point values for equality, which is not reliable. call EQUAL() and ZERO() accordingly.
07:25.52CIA-6BRL-CAD: 03brlcad * r43311 10/brlcad/trunk/src/rt/heatgraph.c: technically more simple to just test for less than zero .. though unsafe. (some comparisons need to compare against +-SMALL_FASTF instead of 0)
11:48.40dlomanMernin!
11:52.37dlomanQuestion to anyone in the know:  Has anyone taken a deep look into how/if current GPU processing techniques could benefit our raytracer?
12:26.34*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:31.56*** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2)
12:33.06*** join/#brlcad kanzure_ (~kanzure@bioinformatics.org)
12:38.30CIA-6BRL-CAD: 03davidloman * r43312 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClient.java: Add null check for the GSClient's GSConnection to ensure a 1:1 GSConnection per GSClient ratio.
12:46.08CIA-6BRL-CAD: 03davidloman * r43313 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClientGUI.java: Breakout GUI elements into their own class. Keeps things clean and easier to manage.
12:47.56CIA-6BRL-CAD: 03davidloman * r43314 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/ (Main.java MinimalGSClient.java): Implement new MinimalGSClient class (without gui components) and roll down the changes to the main() method.
12:56.59CIA-6BRL-CAD: 03d_rossberg * r43315 10/brlcad/trunk/src/libged/CMakeLists.txt:
12:56.59CIA-6BRL-CAD: there are references to libregex here
12:56.59CIA-6BRL-CAD: added libregex headers search path
12:59.50CIA-6BRL-CAD: 03d_rossberg * r43316 10/brlcad/trunk/src/librt/CMakeLists.txt: synced with Makefile.am: "bottie modifications moved to trunk"
13:24.13CIA-6BRL-CAD: 03davidloman * r43317 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/Main.java: Removed stray debugging statement.
13:26.08CIA-6BRL-CAD: 03davidloman * r43318 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/cmd/AbstractCmd.java: Put in usage and help printing methods. Keeps formatting consistent and removes potential future formatting bug points.
13:26.46CIA-6BRL-CAD: 03davidloman * r43319 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/MinimalGSClient.java: Quick Comment...
13:27.14CIA-6BRL-CAD: 03davidloman * r43320 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java: Add tabs and newlines for this lib. More efforts to promote consistency.
13:27.45CIA-6BRL-CAD: 03davidloman * r43321 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/cmd/ (CmdManager.java HelpCmd.java LoginCmd.java): Clean up console printing formats. Use helper methods and statics.
13:32.30CIA-6BRL-CAD: 03davidloman * r43322 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java: Import cleanup.
14:17.36CIA-6BRL-CAD: 03davidloman * r43323 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Create GSJavaInterface, the class that implements the interface 'GeometryService' as defined in jBRLCAD. This will be the public API for this GS interface
14:31.49CIA-6BRL-CAD: 03davidloman * r43324 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/ (7 files in 2 dirs): Propagate use of GSJavaInterface throughout. Allow for AbstractCmd subclasses to gain access to the associated GSJavaInterface, so as to be able to act upon it.
15:09.12CIA-6BRL-CAD: 03erikgreenwald * r43325 10/geomcore/trunk/ (include/Logger.h src/utility/Logger.cxx): simplify, atomicize, remove mutex stuff
15:10.28CIA-6BRL-CAD: 03erikgreenwald * r43326 10/geomcore/trunk/ (25 files in 13 dirs): remove some mutex stuff. remove redundant sleep wrapping. adjust to cope with new include paths sent from FindBRLCAD.cmake
15:54.59CIA-6BRL-CAD: 03davidloman * r43327 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java: Implement minimal client's ability to login to a gs
16:09.24dlomanstarseeker: you around?
16:10.04dlomanin geomcore/src/other/uuid, there are two headers being generated: uuid_config and uuid.h
16:10.19dlomanshould those be svn:ignored?
16:12.17CIA-6BRL-CAD: 03davidloman * r43328 10/geomcore/trunk/src/interfaces/ (. c/ java/): Modified SVN:IGNORE to exclude configure and build byproducts.
16:13.44CIA-6BRL-CAD: 03davidloman * r43329 10/geomcore/trunk/src/other/uuid/: Modified SVN:IGNORE to exclude configure and build byproducts.
16:47.38dlomanstarseeker: Since you are endeavoring for an out of build setup, would it be desireable for me to go and remove all the cmake related entries in svn:ignore
16:49.09starseekerdloman: yeah, that'd be good
16:49.15starseekerI can do it if you like
16:50.45dlomannah, I need a few mins break from what I am doin anyways :)
16:51.56dlomanlooking at the svn:ignore list, is there anything besides cmake_install.cmake, CMakeCache.txt and CMakeFiles that you think sould be removed?
16:52.17starseekerdloman: I'
16:52.26starseekerI've been clearing it entirely
17:00.35dlomanprepares nuklar bomb for svn:ignore....
17:01.50CIA-6BRL-CAD: 03davidloman * r43330 10/geomcore/trunk/ (36 files in 36 dirs): Drop a nuklar bomb on svn:ignore. Pushing for out of source builds.
17:02.02dlomanboom
17:02.08starseekerheh
17:03.20dlomanstarseeker: cmake's INSTALL cmd should be used for copying a file to the install bin dir?
17:03.32dlomanaka, I have two .configure files i need copied over with the build
17:03.58starseekerno, INSTALL is for the final make install
17:04.22starseekerif you want something copied over with the build, used either configure_file, FILE(COPY or
17:04.40starseeker(if you want it to be copied by make and not the cmake configure) make a custom command and custom target
17:05.01starseekerthe latter is a bit more complex because you're essentially telling CMake how to tell Make/Visual Studio/etc. to do it
17:05.38dlomanokay, so making cmake tell make == hard, using cmake to do it  == easymode ?
17:06.57starseekerit's worth it if the file is one you want to edit and copy over to the build tree a lot
17:07.19starseekerit's not that hard, just a few more lines
17:07.29dlomanits a default .configure file, thats all.
17:13.01dlomanusing FILE(COPY src dest)
17:13.04dlomanawesome thanks :)
17:16.36starseekernp :-)
17:19.07dlomancrud, i ran into a brlcad install problem, but i cant remember how to fix it.
17:21.21dlomannm, stale build
17:39.29dlomaninstalls!
18:10.28*** join/#brlcad indianla1ry (~indianlar@63.246.136.16)
18:10.28*** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no)
18:10.28*** join/#brlcad kanzure_ (~kanzure@bioinformatics.org)
18:10.28*** join/#brlcad piksi (piksi@pi-xi.net)
18:10.28*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
18:10.28*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
18:10.28*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
18:10.28*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
18:10.28*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
18:10.28*** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ)
18:10.28*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
18:10.28*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
18:10.28*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
18:10.28*** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2)
18:10.28*** join/#brlcad juan_man (~quassel@186.136.168.73)
18:10.28*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
18:10.28*** join/#brlcad kanzure (~kanzure@131.252.130.248)
18:10.28*** join/#brlcad willdye (~willdye@fern.dsndata.com)
18:10.28*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
18:10.31*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
18:10.31*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
18:10.31*** join/#brlcad 45PABR1J4 (~CIA@208.69.182.149)
18:10.31*** join/#brlcad ChanServ (ChanServ@services.)
18:10.31*** mode/#brlcad [+o ChanServ] by anthony.freenode.net
18:24.06*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
18:24.07*** join/#brlcad ChanServ (ChanServ@services.)
18:24.07*** mode/#brlcad [+o ChanServ] by anthony.freenode.net
18:34.53CIA-77BRL-CAD: 03davidloman * r43331 10/geomcore/trunk/src/GS/CMakeLists.txt: CMake needs to copy over the template config files during its run.
18:37.56CIA-77BRL-CAD: 03starseeker * r43332 10/geomcore/trunk/ (11 files in 10 dirs): More changes to geomcore CMake logic. Need to handle BRLCAD_FOUND properly, conditionally look for things like terminal library based on WIN32 and check for libbrlcad again but getting closer.
18:54.05brlcaddloman: System.getProperty("line.separator"); unless it's a JTextArea... then it's just \n .. or %n if it's in a String.format()
18:55.03*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
18:57.03CIA-77BRL-CAD: 03davidloman * r43333 10/geomcore/trunk/include/GeometryService.h: Default listening addy should be 127.0.0.1 not 0.0.0.0
19:01.21CIA-77BRL-CAD: 03erikgreenwald * r43334 10/geomcore/trunk/ (src/GS/CMakeLists.txt tests/utility/CMakeLists.txt): add TCL_INCLUDE_PATHS
19:02.23CIA-77BRL-CAD: 03davidloman * r43335 10/geomcore/trunk/include/PortalManager.h: Default listening addy should be 127.0.0.1 not 0.0.0.0 (again)
19:02.32CIA-77BRL-CAD: 03erikgreenwald * r43336 10/geomcore/trunk/ (3 files in 2 dirs): add GSUuid wrapper
19:11.03CIA-77BRL-CAD: 03davidloman * r43337 10/geomcore/trunk/ (include/GeometryService.h src/GS/GeometryService.cxx): Remove GeometryService class fields for listenPort and listenAddy. Pass both to GeometryService's PortalManager.
19:13.42CIA-77BRL-CAD: 03erikgreenwald * r43338 10/geomcore/trunk/ (26 files in 7 dirs): eliminate QUuid in favor of local GSUuid wrapper
19:16.52CIA-77BRL-CAD: 03erikgreenwald * r43339 10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: last QUuid is gone
19:19.23dloman``Erik:     /GSUuid.h:32:19: error: uuid.h: No such file or directory
19:22.05CIA-77BRL-CAD: 03brlcad * r43340 10/geomcore/trunk/src/utility/Logger.cxx: if it's a stack trace you want, a stack trace ye shall have. uhm, why?
19:23.45``Erikon which OS?
19:24.10dlomanLinux
19:24.28``Erikhm, the one OS I can't test on due to horribly out of date QT stuff, heh
19:24.52dlomanit was compling fine over here till that last ci of yours.
19:24.57dloman...if that helps :)
19:25.50CIA-77BRL-CAD: 03erikgreenwald * r43341 10/geomcore/trunk/include/GSUuid.h: disable the #include for now
19:27.31dlomanIm doing an out of source build.  that .h was a file I noticed earlier today that was being generated by CMake
19:28.18``Erikthere is one made from src/other/uuid/, but I'm trying to use the system ones
19:28.31dlomanokie!
19:37.12CIA-77BRL-CAD: 03starseeker * r43342 10/geomcore/trunk/ (3 files in 3 dirs): Include uuid directory for all the source paths, now that it's being (potentially) used.
19:37.21starseekerdloman: does that work?
19:41.19dlomannetMsgSerialText.cxx->NetMsg.h->GSUuid.h->uuid.h still fails.
19:45.00``ErikO.o um, does 0 != 0  on linux?
19:45.12``Erikah, starseeker is mucking things up
19:47.26CIA-77BRL-CAD: 03starseeker * r43343 10/geomcore/trunk/tests/CMakeLists.txt: Give tests the include dirs too.
19:48.09dlomanwerkin!
19:59.25CIA-77BRL-CAD: 03erikgreenwald * r43344 10/geomcore/trunk/src/GS/geoserv.cxx: remove the random failure...
20:00.19dlomanack, you suck ``Erik
20:00.26dlomani was just about to commit those fixes
20:04.09``Erikhrm?
20:04.33starseekerhehe
20:04.34``Erikponders grinding indent on thos
20:05.02starseekerdloman: he beat you to the draw huh?
20:05.06dlomanyeah :(
20:09.51CIA-77BRL-CAD: 03davidloman * r43345 10/geomcore/trunk/src/GS/geoserv.cxx: Make port value pulled from config file validate correctly.
20:11.27``Eriksok, I put ! instead of ~, so he'll dump my changes and put his own in *shrug* then I'll "simplify" his later
20:12.05dlomanThat was a neat trick though :)
20:12.18dlomanproves that I don't think bitwise :)
20:14.52CIA-77BRL-CAD: 03davidloman * r43346 10/geomcore/trunk/src/utility/Config.cxx: Fix config parser bug so that parser detects EOF correctly and exits.
20:22.59*** join/#brlcad roberthl_ (~robert@v001.rhl.me.uk)
20:34.55CIA-77BRL-CAD: 03bob1961 * r43347 10/brlcad/trunk/src/ (3 files in 3 dirs): Tweaks to get the windows batch files working better. That is, they can handle filenames with spaces and the windows prompt gets removed from the screen.
21:17.27*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
21:20.34*** join/#brlcad kanzure__ (~kanzure@bioinformatics.org)
21:57.51CIA-77BRL-CAD: 03starseeker * r43348 10/geomcore/trunk/ (9 files in 7 dirs): Optionally enable the subversion build and subversion test, move svntest into the geomcore tests dir.
22:03.52*** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net)
22:04.01_psilvahey brlcad
22:04.22_psilvau there?
22:31.37CIA-77BRL-CAD: 03erikgreenwald * r43349 10/geomcore/trunk/tests/utility/ (CMakeLists.txt threadTest.cxx): add simple threading test for GSThread
22:33.20CIA-77BRL-CAD: 03erikgreenwald * r43350 10/geomcore/trunk/ (include/GSThread.h src/utility/GSThread.cxx): basic threading class implementation
22:34.05CIA-77BRL-CAD: 03erikgreenwald * r43351 10/geomcore/trunk/ (11 files in 4 dirs): QThread -> GSThread
22:53.22*** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1177593317.dsl.bell.ca)
22:55.18CIA-77BRL-CAD: 03erikgreenwald * r43352 10/geomcore/trunk/ (23 files in 7 dirs): stub in GSMutex and GSMutexLocker, still need impl
22:59.40CIA-77BRL-CAD: 03erikgreenwald * r43353 10/geomcore/trunk/ (12 files in 10 dirs): remove references to QT libs
23:03.40CIA-77BRL-CAD: 03erikgreenwald * r43354 10/geomcore/trunk/TODO: notes
23:14.42CIA-77BRL-CAD: 03erikgreenwald * r43355 10/geomcore/trunk/ (include/GSThread.h src/utility/GSThread.cxx): implement GSMutex and GSMutexLocker on pthreads
IRC log for #brlcad on 20110216

IRC log for #brlcad on 20110216

00:06.18CIA-77BRL-CAD: 03starseeker * r43356 10/geomcore/trunk/ (3 files in 2 dirs): Proof of concept code to chop the toplevel objects out of a .g file, write them to individual .g files in the svn repository, and commit them.
01:08.04brlcad_psilva: nope
01:22.17*** join/#brlcad WhiteCalf (MK@whitecalf.net)
01:36.04CIA-77BRL-CAD: 03brlcad * r43357 10/brlcad/trunk/TODO: list the slew of requested and useful converters including step export, dae, x3d, g-code, u3d, 3D pdf, sat, ply, json, and xml formats
02:23.25*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:34.22brlcadstarseeker: nice proof of concept chop-blocking
02:34.58brlcadwould be good exercise to convert to db_walk_tree or one of the other walkers since the next step is probably to stop at the region level
03:05.56starseekerbrlcad: ah, from what dloman was saying it sounded like we would break out every object in the first round
03:07.09starseekeralso, if we stop at the region level, does that mean we do a full keep of each tree below the region level, even if it means duplicating geometry?
03:09.27``Erikjson? really?
03:09.46brlcadabout as useful as xml ;)
03:11.02brlcadstarseeker: either way but I think it's pretty much inevitable, also makes us parallel other cad packages (a region is a part)
03:12.10brlcadintermediate dev would be fine, but we probably shouldn't deploy down to the prim level since we haven't yet sorted out database upgrades
03:12.24brlcadand our next step given the new timeline is pretty much deployment ;)
03:16.04brlcadas for the duplication issue, i've had a plan in place to address that for about 7 years now -- effectively instantiating a more robust concept of a part (one with and without the region bit set)
03:18.55starseekerbrlcad: so... first step is full keep and eat the duplication, then follow on later with the proper solution?
03:19.10brlcadand even without that concept, the duplication issue can become a non-issue by inverting the region-parent relationships (instead of C1->R1,R2,R3->subC1, you have C1->subC1,subC2,subC3->R1)
03:19.55brlcadbasically, but it fortunately doesn't really require changes under the hood, just changes how geometry is managed on import
03:20.35starseekerkinda - but we'll have to migrate broken-out-at-region setups to the final solution
03:20.51starseekeris fine with it, just wants to be sure he's hacking the right thing
03:21.00brlcadnot necessarily, it'll just be duplicate data
03:21.16brlcadwe could automate remerging duplication later as a backend job
03:21.22starseekernods
03:21.46starseekerall rightie, tree walking it is
03:22.43brlcadthere would be one benefit of going all the way down to the primitive level, if you actually calculate the call overhead on a full vehicle with a checkin->breakout->commit->checkout->recombine scenario, see what the numbers look like, then redo stopping at region level
03:23.19brlcadsee if it's actually a significant issue in practice on given arch, like macosx, that has bad i/o performance
03:23.54brlcadif it's not, then we could reasonably punt with confidence that it doesn't matter and let all objects get tracked uniformly
03:24.04starseekernods
03:24.20starseekerit would simplify re-constructing a .g file - just dbconcat all the pieces
03:24.39starseekerbuilding a bunch of regions with full trees back into the original .g is a bit of a chore
03:24.52brlcadwithout the metrics, though, I would definitely just stop at regions since there is pretty significant data overhead at the primitive level: 104 bytes per object
03:25.20starseekernods - at least until we can get our own custom svn backend, anyway
03:25.34brlcadmost objects in implicit form aren't even 104 bytes ;)
03:26.18brlcadthe metrics are critical, though .. because the performance could be an outright show-stopper for a full vehicle
03:26.22starseekeroverheads probably higher than that in the proof of concept code - I'm making everything its own .g file
03:26.32brlcad.g overhead is 104 bytes
03:26.36starseekeroh, gotcha
03:26.47brlcadand most of that is _GLOBAL, so there are other ways to optimize too
03:27.12starseekerthe other approach is to do a more custom write - I took the quick and simple way to write out object data, but I could customize a routine to write JUST the object info
03:27.29brlcadthough file ops likely dominate on files that small
03:28.23starseeker('course if I do custom IO I might as well start looking at an FS-G backend now, and that's not the priority)
03:28.38starseekerwill see if he can get the tree walker going and do the metrics
03:28.59brlcadthe other benefit of constructing this region/non-region organization is that we can enforce proper DAG structures more easily -- CSG recipes would only be valid at/below region level, for example
03:29.09brlcadabove, they're just assemblies, groups
03:29.25brlcadunions
03:30.16brlcadwould effectively make it not possible to subtract assemblies from assemblies without pushing the operations down to the region level
03:31.16starseekerhow would we combine region files of that type back into one .g file?  scan for duplicate primitives and selectively import the ones not already present?
03:31.35starseekerwhat about changes to a multiply referenced primitive?  how do we make sure we hit all the copies?
03:35.35brlcadthe region file stored would already be the pushed result
03:35.50brlcadso the file being combined back on read is just cat-able
03:36.03starseekeryou mean we wouldn't support unpushed geometry?
03:36.12starseekerouch
03:36.16brlcadnot following
03:36.22brlcadno no
03:37.02brlcadthe ONE high-level operation (subtract assemb1 (with r1, r2) from assemb2 (with r3, r4))
03:37.16brlcadwould result in r3 and r4 getting modified
03:38.02starseekerright... I'm thinking a little lower level.  let's say r3 and r4 both include sph1, and I change sph1
03:38.05brlcada "dumb" implementation would simply import r1/r2 into r3 and r4 and subtract them
03:38.31starseekerif r3 and r4 are both full tree copies in the repository, there are two independent copies of sph1
03:38.37starseekerboth of which need to be updated
03:40.11brlcadfor example, you mean two 'sph1' instances in r3 ?
03:40.52starseekerno - I'm thinking I "break" model.g with two regions r1 and r2 into the repository:
03:41.07starseekermodel.g (toplevel object) and two region files r1.g and r2.g
03:41.28starseekerboth r1 and r2 union in the same primitive, sph1
03:41.45starseekerif I'm doing a deep keep to create r1.g and r2.g, BOTH files have identical copies of sph1
03:42.06starseekerif I then edit sph1 in my modeler, the implication is I'm changing both r1.g and r2.g
03:42.13brlcadthat's not possible in the stop-at-region-level setup, the sph1 would be duplicated across the two regions
03:42.30brlcadif it needs to be reusable, then the definition of the region changes
03:43.08starseekerso you're saying that by definition a region does not contain any geometry objects that are used in any other regions?
03:43.11brlcadand you have model.g (toplevel), c1.g (was r1.g), c2.g (was r2.g) and a new r.g (containing the one sph1 instance)
03:43.42brlcadyes, all regions become fully self-contained namespaces
03:44.06starseekershakes his head - I highly doubt that's how things work out in practice
03:44.11brlcadyou can convert any existing model to that structure with the flip inversion I mentioned without loss of generality
03:44.27starseekerI'm not quite parsing the flip inversion
03:45.03brlcadI'll draw
03:47.29starseekeroh, wait - you're turning regions that are not self contained into assemblies, and creating regions below them of the shared subset?
03:47.44brlcadyes
03:47.57starseekerwon't that really mess with region_id information>?
03:48.23starseekerif a geometry was set up with r1 and r2 having different region ids and shared geometry...
03:48.47brlcadnot necessarily
03:50.30brlcadimportant note, though, that the progression is towards the minimization of region ids -- S2 will need updating to accommodate, but M3 uses different tracking mechanisms
03:51.23starseekerthat definition of a region strikes me as a bit limiting - let's say I have a model of a screw, and I want to make 10 different regions using the same geometry but different material properties (aluminum screw, steel screw, etc...) - intentionally the same size and geometry but different regions, and the desire to have any change to screw dimensions propogate to all regions
03:51.37brlcadregion id's in this new system become mostly irrelevant -- it's just attribute data
03:51.47starseekerbrlcad: OK, we're assuming S2 changes as well - that's different
03:52.23brlcadthe concept of a "part" is more that there's a point where they're no longer assemblies and become self-contained part data
03:52.59brlcadI really probably just need to write all this up in a document since it's a discussion that's come up before
03:53.23starseekerwhat happens to the different-materials same-geometry sceario?
03:55.30brlcadthat's either multiple parts (which is what most cad packages do and matches our current "region" concept), or we have to implement support for multiple-segment regions
03:55.57brlcadthe latter would be great for things like the vol primitive
03:57.50brlcadat this point, most of the issues on regions/materials/ids/etc can be punted so long as the routine that breaks up a .g has a means to stop at some level in the hierarchy -- whether at prim, region, one below region, one above, etc
03:58.36brlcadone solution to the multiply reference region was to invert downwards instead of upwards
04:00.20brlcadso every region becomes a region comb containing just one member, the former region hierarchy  --  basically injects a comb node and pushes the region bit up and the "part" becomes a non-region
04:00.41starseekernods
04:01.20brlcadso then S2 keeps doing what they're doing -- regions are unaffected
04:01.27brlcadregion count is unchanged
04:02.18brlcadlil harder to ensure database integrity, so every region has one and only one member, a part
04:03.27starseekerhmm.  Well, regardless it sounds like the first stage is to get a tree walker going and be able to control the break points
04:05.26starseekerlikes the sound of multiple-segment regions, even if he doesn't know exactly what that would entail
04:06.20starseekermust sleep - early morning gym appointment (ugh)
04:07.58brlcadyeah, definitely
04:39.55CIA-77BRL-CAD: 03brlcad * r43358 10/brlcad/trunk/TODO: consolidate the other conversion tasks
06:33.18*** join/#brlcad Stattrav (~Stattrav@117.192.132.151)
06:33.18*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:07.49*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
09:31.11*** join/#brlcad Stattrav (~Stattrav@117.192.132.151)
09:31.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:44.05dlomanstarseeker: brlcad:  I'm not quite grasping at what problem we are solving by stopping the disassembly of the .g file at the region level....
09:44.26dlomanit seems to me it would cause much more problems than is worth the gain in simplicity...
09:45.10dlomanModelers frequently use a single prim from a region (r1) to subtract from another region (r2) for overlaps.
09:46.27dlomanso, but keeping all the prims in the region level file, the GS would have to load two region .g's (entirely with all their geometry) just to get at the solid in r1 for r2... seems a bit clunky and complex
09:46.57dlomanwhat was the 'gain' for keeping the geometry in the region level .g file?
11:50.37``Erikhm, there's been argument that subtracting a region itself is incorrect, the proper way for that hack would be to make a subregion group, have the region contain the group, and subtract the group from other geometry O.o
11:52.47``Erikdlo: I'm not making it in today, I'll be at upper chesapeake most of the day, I think the last fugly wart I left is the UUID shtuff if it's a show stopper and you want to regain functionality... my intent is to try to use the system uuid (e2fs or ossp, depending on os) with some cmake checks and #if e2fs #if ossp fu, if you need something rolling today
11:53.43dlomannot likely, I'll probably be leaving early today...
11:54.12dlomanthe senario I am talking about is:  r1 = s1 u s2 u s3 u s4
11:54.26dlomanr2 = s5 u s6 - s1
11:55.13dlomanI don't see why we would want to keep all the prims in the r1.g and r2.g file, such that we have a duplicate of s1
11:55.51``Erikhasn't read backlog and is getting ready to head to the hospital, will catch it all later O.o
11:56.00dlomanack, everything okay?
11:56.20``Erikit's not for me
13:19.56starseekerdloman: if I understand correctly, the notion is that each region would be a fully independent piece of geometry
13:20.31starseekerby definition, there would be no shared geometry between regions, so subtractions to avoid overlaps would become a somewhat problematic way to handle things
13:22.02starseekerThe main practical concern with breaking up the entire .g file into all its objects is IO performance (lots and lots of small files)
13:23.03starseekerbrlcad also seems to have some ideas about enforcing region policy and .g structure
13:23.31starseekerisn't sure if that logic should live at the svn level or above it
13:24.40starseekeras far as the policy stuff, what I understand of it sounds OK but I'm not sure current modeling practices like you describe are really compatible with it
13:27.02starseekere.g. subtracting parts of one interfering region from another region will result in a copy of the subcomponents needed for the subtraction appearing in the region being subtracted from, and those components will lose their relationship to the region being subtracted
13:28.02starseekerso if you have r1 and r2, and need to subtract c2 that is part of r2 from r1 to avoid an overlap, r1 would get a copy of c2
13:29.01starseekerand changes to the original c2 in r2 would not be automatically propogated back to r1, unless we implement something to do that (which kinda violates the notion of each region being its own independent entity)
13:42.21*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
13:44.04*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
14:15.23_psilvahiyo
14:31.07CIA-77BRL-CAD: 03brlcad * r43359 10/brlcad/trunk/src/irprep/ir-sgi.c: HAS_SGIGL .. isn't going to be around much longer. but test for it being set instead of being true until it's gone.
14:32.23CIA-77BRL-CAD: 03brlcad * r43360 10/brlcad/trunk/src/irprep/ (firpass.c ir-X.c secpass.c shapefact.c): quell verbose warnings. mark unused params, size_t signage promotions, index shadows, and exact floating point comparisons.
14:36.56CIA-77BRL-CAD: 03brlcad * r43361 10/brlcad/trunk/src/lgt/ (do_options.c execshell.c): need to include unistd.h
14:47.22dlomanHrm, well, putting a combination between a region and its prims doesn't solve the problem.
14:48.14dlomanI can 99.99% gurantee that dupicating geometry (in the example, s1) will be *adding* a substantial maintenance burden on the modelers
14:48.24dlomanespecially if s1 is a somewhat sizable bot.
14:50.19dlomanadditionally, although diskspace is 'cheap' and we should only solve problems when they become a problem
14:51.07dlomanwouldn't duplicating s1 in two spots actually end up as a net negative performance on IO, since we would technically have to read that prim twice?
14:51.32dlomanWe can't ignore overlaps, as the are GOING to happen.  Of this, I am 110% certain.
14:52.15starseekerdloman: I may be missing some of the implications of what brlcad is describing, so he should weigh in
14:52.27dlomanadd in the increasing data sizes due to bots and the impending complex nurbs, and I don't see 'each region as its own, idependent, entity' as being a good idea.
14:52.35dlomansure thing.
14:53.12dlomanI am just trying to understand how brlcad and i got our wires crossed.... cause this is not the impression i got, walking away from our last discussion on the subject :/
14:53.27dlomanor more specificly, what brlcad's notion is.
14:53.59dlomanis remote today, so Im not in office.
14:54.07starseekerdloman: did you read the scrollback from last night?
14:54.33dlomanyuppers.
14:54.37starseekeryou might be able to follow it better than me
14:54.58CIA-77BRL-CAD: 03brlcad * r43362 10/brlcad/trunk/src/nirt/ (command.c interact.c nirt.c nirt.h parse_fmt.c read_mat.c): eliminate the rtip global. propagate api changes throughout.
14:55.09dlomanand keeping the prims in the region .g's is, in my opinion, going to cause a ****-ton of issues.
14:56.12dlomankeeping all the solids in their own file, just like the c's and r's, but in a directory named after the associated r, is what i understood our approach was.
14:57.05dlomanyes, it creates many more files, but i honestly think its more flexible and will be lower IO in the long run.
14:58.35CIA-77BRL-CAD: 03brlcad * r43363 10/brlcad/trunk/src/nirt/showshot.c: convert %F to %lf. not optimal, but gefn
14:58.38*** join/#brlcad Stattrav (~Stattrav@117.192.132.151)
14:58.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:20.43dlomanstarseeker: do you know if its bad to change an #include <string> to #include <string.h> ?
15:21.08starseekeruh.  isn't the first one C++ and the second one C?
15:21.29dlomanthats what i thought too.  just checking.
15:21.55dlomanhard to google things with a 13 month old in one arm :)
15:23.14starseekerheh
15:23.21starseekerwinces
15:23.54starseekerhavoc checkout takes 35 megs doing the write-out-every-object scheme
15:24.31CIA-77BRL-CAD: 03brlcad * r43364 10/brlcad/trunk/src/proc-db/ (brickwall.c masonry.c): quell warnings, exact floating point comparisons
15:24.37starseekerguess the every-object-is-a-g-database thing isn't so hot
15:24.53starseekercommits anyway...
15:25.10starseekeroh, took several minutes to commit and checkout, too
15:25.18dlomanwhy is that bad?   whats the original filesize?
15:25.37CIA-77BRL-CAD: 03brlcad * r43365 10/brlcad/trunk/src/proc-db/kurt.c: !EQUAL instead of != for floating point comparison
15:25.37starseeker580K
15:26.25dlomanlooks like the per file overhead is a bit  more than 104 bytes eh?
15:26.36dlomanor are there a bajillion files?
15:26.55starseekeryeah, there's a lot of files
15:26.55CIA-77BRL-CAD: 03brlcad * r43366 10/brlcad/trunk/src/proc-db/ (16 files): quell verbose compilation warnings mostly related to unused params and vars, shadowings, and checking usage.
15:27.16starseekerplus the .svn checkout keeps a baseline copy of each file and a properties file for each file
15:27.28starseeker.svn is 23 Megs, rest is checkout
15:28.43dlomanidealisticly, we could boil the whole repo down to one or two baseline versions of each prim, and just use a ton of matricies :)
15:28.45CIA-77BRL-CAD: 03starseeker * r43367 10/geomcore/trunk/tests/svntest/main.c: Try writing out every object, and directory organization. Use havoc for more of a stress test - performance doesn't look promising
15:29.10starseekersomewhat amusingly, the actual repository (as opposed to the checkouts) is 1.7 megs
15:31.06dlomanthought:  if we are using dbobject names to link to other files, why can't a region contain all its own prims, but still be able to link to other region .g's for prims too ?  whats wrong with that?
15:31.34starseekeruh...
15:31.50starseekerthat gets back to the whole "redefine what a region means" problem
15:34.52dlomanWell, what ever the solution is, having two copies of the same solid, one to construct r1, one to be a overlap subtraction for r2, is going to make a bunch of people really upset.
15:35.09starseekerhmm... so if the count is right, there were just shy of 3000 objects, which means counting the base files and props files just shy of 9000 files for havoc, not counting any other svn files in the checkout
15:36.34dlomanas in 9000 in the repo and 3000 end user visible?
15:36.41starseekeryep
15:37.16dlomanwell, thats better than I thought :)  brlcad and I were thinking an average of 10k per model.
15:37.25dlomangranted, its just havoc
15:37.31starseekernods
15:37.37starseekersimple model
15:37.47dlomanbut converted geometry is like to have less objects, but larger size per
15:38.18dlomani think the last conversion i worked with had about 1500 db objects, but the .g file size was 280 mges
15:38.24starseekerI suppose committing and checking out an entire model in one gulp could also be regarded as worst case
15:38.24dlomanmegs
15:38.41dlomanyeah, untill the multi-system projects start hooking in :)
15:39.15starseeker"checking out" in this case is also creating the repository on disk
15:39.29brlcadthat overhead is pretty much what I expected
15:39.48brlcadso the checkout is 1.7, repo is 23 .. original was?
15:39.49starseekerit might be worth investigating if there are ways to talk to the repo without an explicit checkout to disk
15:40.11starseekerno, checkout is 35, repo is 1.7, original was 580K
15:40.21starseeker35 Meg, 1.7 Meg
15:40.39brlcadcheckout includes .svn dir data
15:40.42brlcadwhat's the export size?
15:40.45starseekerrunning the test as currently committed on the Mac takes 4.5 minutes
15:41.02starseekerabout 12 Megs, I think...
15:41.10brlcadfigure the mac should be worst case performance, so it's a good baseline
15:42.07brlcadthe reason for stopping at the region level was to fight some of that performance, I expect it to knock that at least in half if not more
15:42.47dlomanso with stopping at the r level, how does one handle using s1 from r1 as a subtraction in r2?
15:43.04brlcadputting the repo more on par with the .g size (maybe 25% expansion, minor), and checkout around an order larger
15:43.40brlcadin the short term or long term? :)
15:43.59brlcadand under the hood, or exposed-to-user?
15:44.05dlomanexposed to user
15:45.10brlcadgoing to take a sec to write
15:51.27dlomangets his grub on while he waits. Grilled Cheeze == nom nom nom
15:52.57brlcadso "s1" is some member of this 'part' object "r1", which I'm going to intentionally avoid calling a region for reasons that will hopefully become evident.  so this piece of solid part r1 is being used as a subtraction shape on solid part r2.  previously both in their same namespace, but no longer with this new 'part' concept -- each part is a unique namespace.  so the subtraction of r1/s1 from r2 becomes a cross-namespace reference for the overlapping portions (
15:53.41CIA-77BRL-CAD: 03r_weiss * r43368 10/brlcad/trunk/src/libbn/bntester.c: Added to 'bntester' support for testing function 'bn_isect_lseg3_lseg3'.
15:54.01brlcadcross-reference namespace then become a conscious decision of modelers to import data (breaking the need for a cross-namespace reference), or refactor into a new base part that both r1 and r2 reference
15:54.36brlcadbasically what they do now, just with an implicit single  namespace
15:55.02brlcadI'll have to revisit our notes from that half-day discussion we had -- because we had it pretty lock solid then
15:55.43brlcadI might have a minor detail off, but shouldn't be far off .. but then it was a couple months ago :)
15:56.14dlomanokay, will the end user have to maintain two 's1's or just one?
15:56.15brlcadthe whole problem revolved around solving mergability of .g files
15:56.31brlcadthey get to decide -- default would be just one s1
15:57.07brlcadan s1 from the r1 namespace, r1::s1
15:57.27brlcadif imported as r1::s1 and r2::s1, then they have to make a decision whether those are mergable or not
15:57.52dlomanso a modeler uses s1 from part1, or part1::s1, in part2 as a subtraction, or part2 = part2::s1 - part1::s1
15:57.53brlcadbut then we can provide tools to assist with that decision process -- auto-merge identical geometry, for instance
15:58.10brlcadright
15:58.16dlomanand the modeler doesn't want to make a new part.... how do we store that on our end?
15:58.41starseekerif I'm going to sort assemblies out from combinations, I'll probably have to get search set up to return a list of directory pointers - the ged results string won't cut it
15:58.42brlcadthen it's a configuration option as to what they might want to auto-do with that type of operation -- auto-import/copy, keep the reference, etc
15:59.13brlcadit literally just becomes a named reference, part1::s1 in part2
16:00.27brlcadpart2 was just "u s1" with s1 being an implicit part2::s1 -- with the subtraction and absent any automerging, it becomes: "u s1 - part1::s1" as string data in the .g file
16:00.53brlcadthe part that's escaping me at the moment (no pun intended) is how we solved the "where's my namespace" problem
16:01.02dlomanso we wont be storing two copies of part1::s1 ?
16:01.11brlcadnope
16:01.27dlomanokay then.
16:01.53dlomanso by this logic, the overall svn dir structure wont ever exceed two dirs deep? (but be very wide) ?
16:01.53brlcadonly if they request exactly that as an operation -- "cut my external refs" .. "import external refs", etc
16:02.09brlcadthat's the part that I'm not remembering without our notes
16:02.20brlcadwe'd solved that issue
16:02.35brlcadI think it was with top-level namespacing
16:02.53brlcadso not a part1 namespace, but some higher tank1 namespace and tank2 namespace
16:03.16dlomanright, per my understanding and notes and diagrams, we left our last talk thinking the repo will be three layers deep:  projects->combs/regs->prims
16:03.31dlomannow i'm hearing different, hence my confusion :)
16:03.57brlcads/projects/namespaces/ and I can see that :)
16:04.26brlcadyeah, I wasn't being entirely precise last night as the focus was more just that there needs to be "some" mechanism to halt traversal part-way down the DAG
16:04.45brlcadbecause of the horrid performance impact I was anticipating
16:04.50dlomannamespaces->regions/combs .... thats it, since all the prims will be stored in the files in the regions/combs level
16:05.54dloman..if I am understanding correctly.
16:05.55brlcadyeah, the details are starting to come back to me now :)
16:06.12starseekerI can probably get a rough idea of how expensive writing out regions will be, but it won't be meaningful until I can sort out the assemblies and that's not so straightforward
16:06.59*** join/#brlcad roberthl (~robert@v001.rhl.me.uk)
16:06.59*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
16:07.18starseekeralmost feels like the search logic needs to move from ged to somewhere else
16:07.23starseekerand have ged wrap it
16:07.27starseekerbut not sure where to move it
16:07.30brlcadyep, librt
16:07.38starseekerheh, that works
16:07.43brlcadmged -> libged -> librt is the progression of logic
16:07.52brlcadthere's a lot in libged that belongs in librt
16:08.14starseekerok, I'm gonna have to move that as a first step - I need the search filters to do an intelligent breakout
16:08.19brlcadlibged in a final state would actually end up with very little, just state container wrappers and string parsing really
16:09.37brlcaddaniel's comment was a good one, libged isn't really optimal underneath the GE -- it's at the same level, so most of the geometry manipulation it performs is logic that should be in librt (and is, in a way)
16:10.19brlcadit becomes more of a transaction management interface that bridges and simplifies all that's possible with librt
16:13.07brlcaddloman: will have to revisit the notepad next time I'm in the office (maybe friday) to make sure we're fresh on the solution we came up with, it was pretty tight and there are a few particulars I'm not remembering at the moment
16:13.18dlomanso GE *isn't* a C++ wrapper for libged?
16:13.29dlomanI likely won't be back in the office till next Wednesday
16:13.57brlcadit could be as an interim solution, but really shouldn't be
16:14.56brlcadlibged is really a transactional command parsing library .. that string parsing foo is major suck for any sort of performance geometry processing
16:15.02brlcadGE is more akin to ACIS
16:15.05dlomanso if the GE is side by side with ged, then any/all common functionality needs to be pushed down into librt (and possibly elsewhere too) otherwise we're duplicating code?  (Did i capture the concept correctly?)
16:15.19brlcadyou got it
16:15.55brlcadalternatively, pushed into GE and libged sits on top of GE .. but librt makes more sense at the moment
16:16.29dlomanisn't libged primarily c?
16:16.38brlcadbasically  "libged > GE > librt"  or  "libged,GE > librt" (current plan)
16:16.53brlcadright, that's why it makes more sense to stay that way
16:17.24brlcadit could easily be an encapsulated wrapper, where the GE c++ness would be mere implementation detail like opennurbs in librt
16:17.42dlomanin order to keep the code from getting wicked stupid, then GE would also need to be c, not C++ ...?
16:17.52brlcadnot at all
16:18.25brlcadbecause libged's api is presently a single data container and argc/argv string data
16:18.41brlcadwhat goes on under the hood stays under the hood
16:18.50brlcad(bom chika wah wah)
16:21.59CIA-77BRL-CAD: 03brlcad * r43369 10/brlcad/trunk/src/remrt/ihost.c: if DEFINED, not if NOT defined
16:22.04brlcadoof, that took a while to see...
16:30.11dlomanalright, Im going afk for a few days.  I expect the GS to be finished when I return.  Hop to it!  :P
16:31.26dloman-afk(I only say that cause its now very apparent to me that I have (and had) no idea what I'm doing, heh )
16:41.24brlcadwe need to get rolling on gsoc preparations if you all are interested in mentoring again -- the ideas page needs major updating
16:51.45CIA-77BRL-CAD: 03brlcad * r43370 10/brlcad/trunk/src/remrt/ihost.h: include the headers this header requires, self containment
16:52.26starseekersounds like fun
16:52.33CIA-77BRL-CAD: 03brlcad * r43371 10/brlcad/trunk/src/remrt/ (remrt.c rtsrv.c): mark unused params, check argc params, terminal sentinel with NULL instead of 0, and other quellage
17:21.15_psilvahey brlcad
17:21.20_psilvagot some news for you
17:24.42brlcadsup?
17:25.16brlcadyou spawned a child process? :)
18:25.45_psilvathen it's two thing
18:25.48_psilvahah
18:25.54_psilvadue march 16 ish
18:26.08_psilvabut even bigger and more relevant
18:26.20_psilvawe got bought by autocad
18:26.23_psilvaer
18:26.25_psilvaautodesk
18:26.55_psilvahttp://usa.autodesk.com/adsk/servlet/index?id=16284057&siteID=123112
18:27.11_psilvais now autodesk employee
19:31.35starseeker_psilva: do we offer condolances?
20:05.30brlcad_psilva: heh, well congrats on the 16th and condolences on the 30th (april)
20:09.46_psilvaheh
20:10.23_psilvaat least we're not being relocated
20:10.30_psilva:)
20:15.10_psilvawe'll see
20:15.19_psilvagonna stick around until something more interesting pops up
20:31.35CIA-77BRL-CAD: 03jordisayol * r43372 10/brlcad/trunk/ (misc/debian/control sh/make_deb.sh): modify dependencies to build deb packages
21:01.58CIA-77BRL-CAD: 03starseeker * r43373 10/brlcad/trunk/ (7 files in 3 dirs): Make a stab at moving search logic to librt
21:22.17CIA-77BRL-CAD: 03starseeker * r43374 10/brlcad/branches/cmake/ (56 files in 18 dirs): MFC r43373
21:33.37CIA-77BRL-CAD: 03starseeker * r43375 10/brlcad/trunk/src/librt/search.c: Fix order of inputs, UNUSED some inputs
21:37.27CIA-77BRL-CAD: 03starseeker * r43376 10/brlcad/branches/cmake/src/librt/search.c: MFC r43375
21:38.15CIA-77BRL-CAD: 03brlcad * r43377 10/brlcad/trunk/src/librt/bool.c:
21:38.15CIA-77BRL-CAD: call NEAR_EQUAL() with a 0.001 tolerance instead of rt_fdiff() since that
21:38.15CIA-77BRL-CAD: function is deprecated. this potentially affects fastgen platemode overlap
21:38.15CIA-77BRL-CAD: reporting since it's no longer performing a relative tolerance comparison, but
21:38.16CIA-77BRL-CAD: the impact shouldn't be too significant since the absolute tolerance is rather
21:38.16CIA-77BRL-CAD: loose at 0.001
21:40.26CIA-77BRL-CAD: 03starseeker * r43378 10/brlcad/branches/cmake/src/ (libged/CMakeLists.txt librt/CMakeLists.txt): Fix CMake logic for search file changes
21:41.25CIA-77BRL-CAD: 03brlcad * r43379 10/brlcad/trunk/src/librt/db_flip.c:
21:41.25CIA-77BRL-CAD: use a bridge pattern to separate the deprecated function logic into new private
21:41.25CIA-77BRL-CAD: functions. this lets us continue to be able to flip v4 files, even after the
21:41.25CIA-77BRL-CAD: deprecated rt_* functions become obsolete, yet allows for the API to continue
21:41.25CIA-77BRL-CAD: working for now.
21:41.35CIA-77BRL-CAD: 03brlcad * r43380 10/brlcad/trunk/src/librt/librt_private.h: declare the new flip functions
21:42.24CIA-77BRL-CAD: 03brlcad * r43381 10/brlcad/trunk/src/librt/binunif/db5_bin.c: call ntohl() and htonl() instead of the deprecated libbu functions.
21:42.53CIA-77BRL-CAD: 03brlcad * r43382 10/brlcad/trunk/src/librt/comb/db_comb.c: call the new private flip funcs instead of the deprecated api.
22:33.32brlcadstarseeker: librt api should not have argc/argv parameters
22:34.29starseekerbrlcad: all right, I'll have to revert then - reworking the code to not use them could be a significant effort
22:34.39brlcadyeah, moving search to librt is not going to be a simple move
22:34.45brlcadit needs to work on data
22:35.22starseekerwell, that's a days work down the drain
22:35.29brlcaddata in, data out -- no printing to console (except diagnostic)
22:36.03starseekeruh... it's not printing to console
22:36.10brlcadso you'd get back, for example, an array of rt_db_internal pointer's from a given query -- the search front-end would iterate over a result and print their names
22:37.09starseekerthat's edging dangerously close to a complete rework
22:37.28brlcadI was surprised that you were heading down that road :)
22:37.42starseekerwell, is there another way to spot assemblies?
22:37.45brlcadit's doable, not necessarily a rewrite
22:38.10brlcadthe hardest part of search is building up that query filtering logic, stopping criteria -- that all stays the same
22:38.31starseekerif I'm going to do the one .g per region, I have to be able to identify the assembly combinations - they will need to be written out as their own objects, since the region .g files won't handle them
22:40.05brlcadsearch still sounds like a good approach for that
22:40.27brlcadyou just have to split things up some
22:40.47CIA-77BRL-CAD: 03starseeker * r43383 10/brlcad/trunk/src/librt/search.c:
22:40.47CIA-77BRL-CAD: Add logic to append directory pointer entries to a list - will allow for
22:40.47CIA-77BRL-CAD: manipulation of objects found in C code without having to re-parse string. For
22:40.47CIA-77BRL-CAD: now, only return pointer to leaf node of path - could conceivably be expanded if
22:40.47CIA-77BRL-CAD: there is a need.
22:40.50brlcadsomewhere in search, I'm sure it's taking the input argc/argv and turning that into an in-memory expression of some sort
22:41.08starseekerbrlcad: it is.  I'm quite sure it can be done, but it's... tangled
22:41.27brlcadthat logic stays in libged's search front-end, librt takes that in-memory expression as a parameter to rt_search()
22:41.45brlcadlayers, like an onion ;)
22:41.56starseekerbrlcad: what should I do - full revert, put everything back in libged?
22:42.23starseekerI'm pretty sure I won't have time until next month to do that kind of sorting out of the search logic
22:46.26brlcadmight as well
22:46.39starseekerk
22:46.59CIA-77BRL-CAD: 03starseeker * r43384 10/brlcad/branches/cmake/src/librt/ (6 files in 3 dirs): MFC r43383
22:48.17brlcadat a glance, looks like it's pretty close already -- find_formplan() would become something like rt_search_plan(), find_execute() would probably become something like rt_search().  that'd be your two new api hooks
22:48.59brlcadged_search() looks rather peculiar to me..  how does it know how many expression arguments there are??
22:50.00starseekerwhat, the altered one or the original?
22:50.47starseekerOK, everything should be back in place
22:51.03brlcadI don't know -- I'm just looking at my current checkout with is r42551
22:51.22starseekeroh, yeah that's the original
22:51.42brlcadOh.. is the entire expression in argv[1]??
22:51.45brlcadheh
22:51.47starseekeryeah
22:51.49brlcadwow
22:51.55starseekerit's up to the search functions to make sense of it
22:52.21brlcadso yeah.. a few changes
22:53.59brlcadged_search() should take variable argc/argv, one per actual argument .. that would get parsed into an "rt_search_plan" struct of some sort (basically a custom "PLAN *"), that'd get passed to rt_search()
22:54.29CIA-77BRL-CAD: 03starseeker * r43385 10/geomcore/trunk/tests/svntest/main.c:
22:54.30CIA-77BRL-CAD: Add some commented out code based on the test code used in ged_search to test
22:54.30CIA-77BRL-CAD: directory pointer list printing. Will need to construct argc/argv input for
22:54.30CIA-77BRL-CAD: rt_search, but this should in principle allow the identification in C code of
22:54.30CIA-77BRL-CAD: assemblies.
22:54.55brlcadlibrt could provide rt_search_plan() as a helper function to turn the string data into an rt_search_plan, but you'd be able to bypass that and do it all string-less with rt_search() then if you wanted
22:54.57starseekerbrlcad: we need to be careful there - the find command has its own option handling logic, I don't know how similar it is to our normal stuff
22:56.16brlcadnot too careful -- at worse, ged_search() and/or rt_search_plan() would just join all of the argv parameters together into one bit string and pass to find's plan making code
22:56.45starseekeruh... if we're doing that, why bother splitting them up in the first place?
22:57.02brlcadahh, I see -- it's not one big string
22:57.12brlcadit's iterating afterall
22:57.20brlcadbut requires a NULL-terminated argv
22:57.46brlcadyou're not splitting them up, they start out split up
22:58.18starseekersort of - formplan gets argv[2]
22:59.10brlcadbut as a char **, it then iterates over the argv elements individually
22:59.18starseekerright
22:59.35brlcadso it's not all in argv[1]/argv[2]
22:59.43brlcadit's already a proper argv list
22:59.57starseekerbrlcad: as long as we're at this... is there a function somewhere to do for bu_lists or some other bu data structure what uniq does on the unix command line?
23:00.53starseekeryou hand mentioned wanting to fix some search behavior that was unexpected, and iirc it required always doing a full path iteration, so to simulate searching through ls results we would need to do some kind of uniq filtering
23:00.57CIA-77BRL-CAD: 03starseeker * r43386 10/brlcad/trunk/ (7 files in 3 dirs): Sigh. Put search back in libged for now - need to split out the argument parsing logic into libged and the backend logic into librt first.
23:01.03brlcadbu_ptbl's have unique awareness for pointer tracking
23:01.30brlcadbu_ptbl_ins_unique()
23:01.34starseekerhmm... can I stash directory pointers in a bu_ptbl?
23:01.45brlcadptbl == pointer table
23:01.48brlcadarbitrary pointer container
23:02.19starseekerok, that might do then
23:02.23brlcadredblack trees have similar uniqueness insertion routines
23:02.39brlcaddepends what sort of O behavior you need
23:03.21brlcadso search is already pretty close to what you'd need for librt from what I'm seeing here
23:03.58brlcadthe biggest change is just fixing the routine names, creating corresponding rt_ prefix names for the api
23:04.26starseekerand making sure everything functions in libged/librt respectively
23:04.29brlcadthe code already has that separation I referred to
23:05.07starseekerah, good :-)
23:05.19brlcadthink of it as only migrating find_formplan() and find_execute() to librt, but not with those names
23:05.48brlcadged_search() stays in libged exactly as it is, just pointing to the new names instead of find_formplan() and find_execute()
23:06.02starseekerwell, I've got tomorrow so I'll do what I can
23:06.14brlcadinstead of find_formplan() returning a PLAN*, it should be some rt_plan_t or somesuch
23:06.57starseekerhmm - db_plan_t maybe?
23:07.01brlcadfind_formplan() would get renamed to something like rt_search_plan(); find_execute() would get renamed to something like rt_search()
23:07.13starseekerdoesn't really have much to do with raytracing - db_ prefix may make more sense
23:07.17brlcadit could be db_ api instead of rt_ api
23:07.18brlcadsure
23:07.31brlcadunless it's going to return rt_db_internal objects
23:07.34brlcadthen it's rt_ api
23:07.47brlcadI think
23:07.51brlcadhave to check on that one
23:08.11brlcadah, yes, find_execute() would have to be refactored to not have a gedp parameter
23:08.23brlcadsame with findplan
23:08.49starseekerwill probably return a list of db_full_path structs and a bu_ptbl of directory pointers
23:09.07starseekeryeah, ged structs are everywhere in there
23:09.20starseekerI got those out once, so I'm not too worried about that - just takes time
23:10.30starseekeror if directory pointers make it rt_ specific, could just return db_full_path list and let the calling function sort it out
23:11.18starseekerthat's probably cleaner
IRC log for #brlcad on 20110217

IRC log for #brlcad on 20110217

01:33.34*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
04:34.49*** join/#brlcad dtidrow (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
04:41.39brlcadyeah, db_full_path list sounds perfect
05:03.20*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
05:47.18CIA-77BRL-CAD: 03brlcad * r43387 10/brlcad/trunk/src/rttherm/spectrum.c: more ZERO() conversion for exact floating point comparisons
05:48.34CIA-77BRL-CAD: 03brlcad * r43388 10/brlcad/trunk/src/irprep/irdisp.c: init before use
05:49.31CIA-77BRL-CAD: 03brlcad * r43389 10/brlcad/trunk/src/proc-db/ (brepintersect.cpp lens.c surfaceintersect.cpp): init before use
05:49.54CIA-77BRL-CAD: 03brlcad * r43390 10/brlcad/trunk/src/lgt/ir.c: VINIT_ZERO love
05:50.13CIA-77BRL-CAD: 03brlcad * r43391 10/brlcad/trunk/src/nirt/showshot.c: more VINIT_ZERO love
06:17.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:54.42*** join/#brlcad PrezWhiteCalf (MK@whitecalf.net)
07:08.36*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:41.58*** join/#brlcad Elrohir (~kvirc@p5B14BA30.dip.t-dialin.net)
13:50.30*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
14:27.20CIA-77BRL-CAD: 03d_rossberg * r43392 10/brlcad/trunk/misc/win32-msvc/Dll/brlcad.def: there was a request to export some additional functions
14:43.59CIA-77BRL-CAD: 03brlcad * r43393 10/brlcad/trunk/src/rt/ (Makefile.am hurt.c): hurt is hurting no more. remove the research project since it's inactive and a maintenance burden to bring up to strictness standards.
14:46.06``Erikstarseeker: http://news.slashdot.org/story/11/02/16/1740257/Compared-and-Contrasted-OpenOffice-V-LibreOffice
14:47.44*** join/#brlcad Stattrav (~Stattrav@117.192.142.157)
14:47.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:17.39CIA-77BRL-CAD: 03brlcad * r43394 10/brlcad/trunk/src/librt/db_flip.c: not return, just run the function
15:33.29CIA-77BRL-CAD: 03erikgreenwald * r43395 10/brlcad/trunk/src/librt/binunif/db5_bin.c: add arpa/inet.h for ntohl/htonl
18:14.59CIA-77BRL-CAD: 03brlcad * r43396 10/brlcad/trunk/src/ (29 files in 2 dirs):
18:15.00CIA-77BRL-CAD: major quellage cleanup including missing struct elements, unused parameters,
18:15.00CIA-77BRL-CAD: exact floating point comparisons, unused vars, and much more. big honkin commit
18:15.00CIA-77BRL-CAD: because of two changes that ripple through. ap global changed to APP so that
18:15.00CIA-77BRL-CAD: params passing an ap can use ap for the param name. also replaced convention of
18:15.00CIA-77BRL-CAD: using a version char* global with a version() function.
18:28.00CIA-77BRL-CAD: 03brlcad * r43397 10/brlcad/trunk/src/rttherm/viewtherm.c: missed one. quellage cleanup including version conversion.
18:47.08starseeker``Erik: yeah, saw that - rather premature.  Libreoffice hasn't had time to diverge much from OO.org
19:05.58CIA-77BRL-CAD: 03brlcad * r43398 10/brlcad/trunk/src/rttherm/viewtherm.c: usage is no longer static
19:13.54*** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net)
19:14.04_psilvatest
19:14.09_psilvahuh
19:14.54_psilvaanyone know these guys? http://www.cfdesign.com/
19:24.46CIA-77BRL-CAD: 03bob1961 * r43399 10/brlcad/trunk/src/libfb/if_wgl.c: This fixes a bug on windows where drawing strings breaks.
19:38.49CIA-77BRL-CAD: 03bob1961 * r43400 10/brlcad/trunk/src/tclscripts/lib/RtControl.tcl: Accommodate possible spaces in .
20:53.00CIA-77BRL-CAD: 03starseeker * r43401 10/brlcad/branches/cmake/ (54 files in 14 dirs): MFC r43400 and fixes to CMakeLists.txt files
21:03.32CIA-77BRL-CAD: 03starseeker * r43402 10/brlcad/branches/cmake/ (CMakeLists.txt src/conv/CMakeLists.txt): Get distcheck working for CMake
21:34.29CIA-77BRL-CAD: 03brlcad * r43403 10/brlcad/trunk/src/rttherm/ (pixtest.c spectrum.c ssampview.c): remove dead code, remove rt_ prefix on functions that aren't actually in librt (curiously relevent to librt/spectrum.c but not librt api nonetheless).
21:35.18brlcad_psilva: nope
21:47.53CIA-77BRL-CAD: 03brlcad * r43404 10/brlcad/trunk/src/shapes/ (coil.c fence.c): handle a slew of exact floating point comparisons for zero and equality
21:51.03CIA-77BRL-CAD: 03brlcad * r43405 10/brlcad/trunk/src/shapes/wire.c: make sure there aren't unexpected params
21:51.24CIA-77BRL-CAD: 03brlcad * r43406 10/brlcad/trunk/src/shapes/picket_fence.c: quellage, shadow on osx
22:06.06brlcadcan feel it getting close...
22:06.07CIA-77BRL-CAD: 03brlcad * r43407 10/brlcad/trunk/src/sig/ (24 files): squelch the quellch. simple floating point exactness conversions.
22:09.35CIA-77BRL-CAD: 03brlcad * r43408 10/brlcad/trunk/src/tab/script.l: squelch warning about not using yyunput() by not outputting that function
22:13.01CIA-77BRL-CAD: 03brlcad * r43409 10/brlcad/trunk/src/tab/txyz-pl.c: de-k&r, use argv and remove authorship
22:18.11CIA-77BRL-CAD: 03brlcad * r43410 10/brlcad/trunk/src/tab/ (Makefile.am txyz-pl.c):
22:18.12CIA-77BRL-CAD: remove the txyz-pl program outright as it is nearly identical to the util/xyz-pl
22:18.12CIA-77BRL-CAD: program. it merely parses and ignores an additional starting column. trivially
22:18.12CIA-77BRL-CAD: achieved with cut, awk, or other tools, so remove this deviant in favor of the
22:18.12CIA-77BRL-CAD: one in util where it more appropriately belongs anyways.
22:21.23CIA-77BRL-CAD: 03brlcad * r43411 10/brlcad/trunk/NEWS: minor, but unfortunately user visible. removed the txyz-pl tool because it is a redundant minor variation of our xyz-pl tool easily replaced with an awk, sed, or cut pipe.
23:19.37CIA-77BRL-CAD: 03r_weiss * r43412 10/brlcad/trunk/src/libbn/bntester.c: Updates to bntester.c for testing function bn_isect_lseg3_lseg3.
IRC log for #brlcad on 20110218

IRC log for #brlcad on 20110218

04:38.01CIA-77BRL-CAD: 03brlcad * r43413 10/brlcad/trunk/src/other/URToolkit/cnv/rletorla.c: check if defined before checking value
04:41.22brlcadis in disbelief, I think that's a complete clean strict build now
04:54.51CIA-77BRL-CAD: 03brlcad * r43414 10/brlcad/trunk/configure.ac:
04:54.52CIA-77BRL-CAD: want to enable strict building on all sources now that all dirs are passing, but
04:54.52CIA-77BRL-CAD: can't due to src/other needing -w .. and passing that cleanly to the
04:54.52CIA-77BRL-CAD: subconfigures is a bit of suckage. maybe something cmake can handle better
05:10.29*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
05:10.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:16.42*** join/#brlcad Stattrav (~Stattrav@122.172.6.241)
05:16.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:13.04*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
08:57.05*** join/#brlcad merzo (~merzo@193.254.217.44)
12:31.56*** join/#brlcad kanzure_ (~kanzure@bioinformatics.org)
12:55.53*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:39.03CIA-77BRL-CAD: 03starseeker * r43415 10/brlcad/branches/cmake/ (4 files in 4 dirs): (log message trimmed)
13:39.03CIA-77BRL-CAD: We don't want any of the CFLAGS being added to the BRL-CAD build to make it to
13:39.03CIA-77BRL-CAD: src/other - from what I'm seeing on the CMake list the correct way to do this
13:39.03CIA-77BRL-CAD: seems to be adding the src/other subdirectory before any CFLAGS are set at the
13:39.03CIA-77BRL-CAD: top level. This also means that the src/other CMakeLists.txt files have to
13:39.04CIA-77BRL-CAD: 'stand on their own' a bit more than before - i.e. they can't depend on the
13:39.05CIA-77BRL-CAD: toplevel settings to give them what they need. This is fine (indeed it's the
13:40.03*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
13:41.11CIA-77BRL-CAD: 03starseeker * r43416 10/brlcad/branches/cmake/CMakeLists.txt: Need arpa/inet.h test
13:45.17starseekerhmm... everything's getting rebuilt after a cmake run, may need to study why that src/other change had that impact
13:46.10starseekerwill have to make sure the parent C_FLAGS aren't getting in there on the second pass...
13:49.46starseekeroh, I see - CFLAGS and CXXFLAGS keep getting variables appended
14:16.24``ErikCFLAGS="$(sed s/ /^M/g ${CFLAGS} | sort | uniq | xargs)" ? too unix?
14:20.34starseeker``Erik: it's not that, it's just that I'm not resetting properly...
14:21.17CIA-77BRL-CAD: 03starseeker * r43417 10/brlcad/branches/cmake/CMakeLists.txt: initialize CFLAGS like we mean it
14:21.29starseekersome of the macros are appending too aggressively, but I'll have to sort that out later
14:21.38starseekerin the meantime, that should do
15:27.05*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:35.52*** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net)
16:09.55*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
16:44.11CIA-77BRL-CAD: 03bob1961 * r43418 10/brlcad/trunk/src/libtclcad/ged_obj.c: Minor tweak to go_refresh_view().
17:10.12CIA-77BRL-CAD: 03bob1961 * r43419 10/brlcad/trunk/src/tclscripts/ (6 files in 2 dirs): Moved cursor.tcl from archer to lib.
18:36.45brlcadstarseeker: include headers got updated -- that'll cause a rebuild
18:37.02brlcadahh, you sorted it out, flags
18:37.10brlcadcrawls back in a hole
18:42.01_psilva:(
19:01.17CIA-77BRL-CAD: 03erikgreenwald * r43420 10/brlcad/trunk/src/gtools/remapid.c: remove function defined as static but never used
19:12.10CIA-77BRL-CAD: 03erikgreenwald * r43421 10/brlcad/trunk/src/ (8 files in 7 dirs): warning quellage
19:19.06CIA-77BRL-CAD: 03erikgreenwald * r43422 10/geomcore/trunk/tests/CMakeLists.txt: park tests in a seperate directory
19:27.42*** join/#brlcad WhiteCalf (~MK@whitecalf.net)
19:53.51*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
21:06.47*** part/#brlcad willdye (~willdye@fern.dsndata.com)
21:15.35*** join/#brlcad willdye (~willdye@fern.dsndata.com)
IRC log for #brlcad on 20110219

IRC log for #brlcad on 20110219

00:02.33*** join/#brlcad ibot (~ibot@rikers.org)
00:02.33*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
05:07.58*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
05:33.07*** join/#brlcad Stattrav (~Stattrav@122.167.175.247)
05:33.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:01.17*** join/#brlcad Stattrav (~Stattrav@122.172.14.69)
06:01.17*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:17.58*** join/#brlcad ibot (~ibot@rikers.org)
06:17.59*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
09:23.01*** join/#brlcad PrezWhiteCalf (~MK@whitecalf.net)
13:07.09*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
13:08.43*** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201)
16:31.38*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
16:58.39*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
18:39.55*** join/#brlcad mafm (~mafm@222.Red-83-49-87.dynamicIP.rima-tde.net)
19:22.48*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
IRC log for #brlcad on 20110220

IRC log for #brlcad on 20110220

03:23.28*** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net)
09:27.11*** join/#brlcad Stattrav (~Stattrav@117.192.150.90)
09:27.12*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:16.55*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:39.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:43.48*** join/#brlcad Stattrav (~Stattrav@117.192.150.90)
14:43.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:41.47*** join/#brlcad PrezWhiteCalf (MK@whitecalf.net)
17:25.47*** join/#brlcad Stattrav (~Stattrav@117.192.150.90)
17:25.47*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:31.22*** join/#brlcad Stattrav_ (~Stattrav@117.192.129.182)
IRC log for #brlcad on 20110221

IRC log for #brlcad on 20110221

02:33.13*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
06:26.50*** join/#brlcad Stattrav (~Stattrav@122.172.167.195)
06:26.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:35.07*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
08:28.32*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
08:53.23*** join/#brlcad Stattrav (~Stattrav@122.172.167.195)
08:53.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:24.16``Erik1/cl
14:51.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:33.06*** join/#brlcad Ralith (~ralith@d142-058-083-162.wireless.sfu.ca)
22:35.42*** join/#brlcad Ralith_ (~ralith@d142-058-083-162.wireless.sfu.ca)
22:49.17*** join/#brlcad Ralith (~ralith@d142-058-095-035.wireless.sfu.ca)
23:28.00*** join/#brlcad merzo (~merzo@107-96-94-178.pool.ukrtel.net)
IRC log for #brlcad on 20110222

IRC log for #brlcad on 20110222

03:41.34*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
06:06.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:42.21*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
07:36.04*** join/#brlcad willdye (~willdye@fern.dsndata.com)
08:34.16*** join/#brlcad WhiteCalf (MK@whitecalf.net)
13:23.43*** join/#brlcad WhiteCalf (MK@174.36.224.242)
14:02.37*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
14:53.31CIA-77BRL-CAD: 03SearchenginopT 07http://brlcad.org * r2480 10/wiki/Search_Engine_Optimisation_-_Easiest_way: New page: '''[http://www.searchengineoptimisationaustralia.com.au/ Search engine optimisation]''' can be the easiest way to gain popularity but can also be the most dangerous one to have. Since it i...
15:09.18_psilva3h
15:09.22_psilvaeh
15:27.32*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
15:43.58*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
16:02.44CIA-77BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
16:02.44CIA-77BRL-CAD: deleted "[[Search Engine Optimisation - Easiest way]]": content was:
16:02.44CIA-77BRL-CAD: ''''[http://www.searchengineoptimisationaustralia.com.au/ Search engine
16:02.44CIA-77BRL-CAD: optimisation]''' can be the easiest way to gain popularity but can also be the
16:02.44CIA-77BRL-CAD: ...' (and the only contributor was
16:02.45CIA-77BRL-CAD: '[[Special:Contributions/SearchenginopT|SearchenginopT]]')
16:02.46CIA-77BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:SearchenginopT]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
16:08.39*** join/#brlcad Stattrav (~Stattrav@117.202.26.145)
16:08.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:34.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:57.50*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
17:11.19CIA-77BRL-CAD: 03brlcad * r43423 10/brlcad/trunk/src/librt/primitives/table.c: will rt_generic_xform() work here?
17:11.43CIA-77BRL-CAD: 03brlcad * r43424 10/brlcad/trunk/src/librt/db_corrupt.c: call new private flip_mat_dbmat() function instead of deprecated rt_mat_dbmat()
17:13.24CIA-77BRL-CAD: 03brlcad * r43425 10/brlcad/trunk/configure.ac: check for htonll() and ntohll() functions since they're not included in posix.1 with the other byteorder functions.
18:52.30*** join/#brlcad roberthl_ (~robert@93-97-176-250.zone5.bethere.co.uk)
20:26.37*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
21:07.14*** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net)
21:07.14*** join/#brlcad kanzure_ (~kanzure@bioinformatics.org)
21:07.14*** join/#brlcad ChanServ (ChanServ@services.)
21:07.14*** mode/#brlcad [+o ChanServ] by anthony.freenode.net
21:08.11*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
21:08.11*** join/#brlcad dloman-afk (~claymore@BZ.BZFLAG.BZ)
21:08.11*** join/#brlcad kanzure (~kanzure@131.252.130.248)
21:08.11*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
21:08.11*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
21:08.11*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
21:08.11*** join/#brlcad WhiteCalf (MK@174.36.224.242)
21:08.12*** join/#brlcad willdye (~willdye@fern.dsndata.com)
21:08.12*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
21:08.12*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
21:08.12*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
21:08.12*** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net)
21:08.12*** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ)
21:08.12*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
21:08.12*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
21:08.12*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
21:08.12*** join/#brlcad piksi (piksi@pi-xi.net)
21:09.01*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
21:09.01*** join/#brlcad CIA-77 (~CIA@208.69.182.149)
21:20.47*** join/#brlcad ibot (~ibot@rikers.org)
21:20.47*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
21:50.21*** join/#brlcad dloman-afk (~claymore@BZ.BZFLAG.BZ)
21:50.21*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
IRC log for #brlcad on 20110223

IRC log for #brlcad on 20110223

01:29.29*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
03:19.15*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
05:01.08CIA-77BRL-CAD: 03brlcad * r43426 10/brlcad/trunk/include/bu.h: not true, they expect pointers
05:54.33*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
06:23.09*** join/#brlcad Stattrav (~Stattrav@122.172.31.214)
06:23.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:31.44*** join/#brlcad _psilva_ (~psilva@h-67-103-183-185.mclnva23.static.covad.net)
07:44.33*** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net)
08:30.32*** join/#brlcad willdye (~willdye@fern.dsndata.com)
10:58.11*** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net)
12:24.26*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:25.04*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
14:26.28CIA-77BRL-CAD: 03brlcad * r43427 10/brlcad/trunk/src/librt/binunif/db5_bin.c: this might have worked, but it was a bad way. don't work with truncated values, cast the char array to the corresponding type being read/written
17:17.30CIA-77BRL-CAD: 03brlcad * r43428 10/brlcad/trunk/src/librt/binunif/db5_bin.c: typo, supposed to be a pointer. odd.
17:43.58*** join/#brlcad mafm (~mafm@100.Red-88-22-160.staticIP.rima-tde.net)
18:36.56*** join/#brlcad mafm_ (~mafm@100.Red-88-22-160.staticIP.rima-tde.net)
18:37.25*** join/#brlcad Ralith (~ralith@d142-058-093-103.wireless.sfu.ca)
19:26.27*** join/#brlcad roberthl (~robert@cpc1-flit1-0-0-cust67.9-1.cable.virginmedia.com)
19:26.27*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
19:47.33*** join/#brlcad roberthl (~robert@v001.rhl.me.uk)
19:47.33*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
20:14.16*** join/#brlcad Ralith (~ralith@d142-058-093-103.wireless.sfu.ca)
20:39.54CIA-77BRL-CAD: 03brlcad * r43429 10/brlcad/trunk/ (11 files in 9 dirs):
20:39.54CIA-77BRL-CAD: convert the bu_external byte buffer from being a genptr_t (i.e., void*) array to
20:39.54CIA-77BRL-CAD: being a uint8_t* array. this fixes some coercion problems attempting to pass
20:39.54CIA-77BRL-CAD: data through a void pointer and, more importantly, better reflects the intent of
20:39.54CIA-77BRL-CAD: the container.
21:26.20``Erik-:q
21:26.41CIA-77BRL-CAD: 03erikgreenwald * r43430 10/geomcore/trunk/ (12 files in 7 dirs): wire in OSSF uuid stuff into GSUuid, with minor api changes
21:52.15*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
21:52.16*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
21:52.16*** join/#brlcad ChanServ (ChanServ@services.)
21:52.16*** join/#brlcad kanzure_ (~kanzure@bioinformatics.org)
21:52.16*** join/#brlcad CIA-77 (~CIA@208.69.182.149)
21:52.16*** mode/#brlcad [+o ChanServ] by anthony.freenode.net
21:53.19*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
22:20.02*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
22:36.00*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
22:36.24*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
22:40.50*** join/#brlcad 50UAAACRT (~devlin@d118-75-252-178.try.wideopenwest.com)
22:40.50*** join/#brlcad dloman-afk (~claymore@BZ.BZFLAG.BZ)
22:40.50*** join/#brlcad Ralith (~ralith@d142-058-093-103.wireless.sfu.ca)
22:40.50*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
22:40.50*** join/#brlcad mafm_ (~mafm@100.Red-88-22-160.staticIP.rima-tde.net)
22:40.50*** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net)
22:40.50*** join/#brlcad willdye (~willdye@fern.dsndata.com)
22:40.50*** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net)
22:40.50*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
22:40.50*** join/#brlcad kanzure (~kanzure@131.252.130.248)
22:40.50*** join/#brlcad 5EXAB9F0G (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
22:40.50*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
22:40.50*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
22:40.50*** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ)
22:40.50*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
22:40.50*** join/#brlcad 5EXAB5O7U (Here@c-69-140-109-104.hsd1.md.comcast.net)
22:40.50*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
22:41.42*** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ)
22:41.43*** join/#brlcad dli_ (~dli@dsl-67-204-45-87.acanac.net)
22:41.44*** join/#brlcad kanzure__ (~kanzure@bioinformatics.org)
22:41.44*** join/#brlcad dloman-a1k (~claymore@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20110224

IRC log for #brlcad on 20110224

02:33.23CIA-77BRL-CAD: 03Sean 07http://brlcad.org * r2481 10/wiki/Building_from_SVN: add --enable-all and notes on the install dir
04:10.52*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
04:34.20CIA-77BRL-CAD: 03brlcad * r43431 10/brlcad/trunk/src/librt/vlist.c: progressive conversion of libbu xdr routines over to posix.1 byteorder functions. note an abuse of vls in here, being used as a byte buffer.
04:39.44CIA-77BRL-CAD: 03brlcad * r43432 10/brlcad/trunk/src/librt/db_scan.c: progressive conversion of libbu xdr routines over to posix.1 byteorder functions. simple conversion when getting (net -> host) values.
04:42.43*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
04:43.32CIA-77BRL-CAD: 03brlcad * r43433 10/brlcad/trunk/src/librt/primitives/ (13 files in 13 dirs): call flip_fastf_float() instead of rt_fastf_float() so we can deprecate the old rt api routine. include private header as needed.
04:50.46CIA-77BRL-CAD: 03brlcad * r43434 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: convert from bu xdr routines to ntohl()/htonl()
04:53.17CIA-77BRL-CAD: 03brlcad * r43435 10/brlcad/trunk/src/librt/primitives/arbn/arbn.c: convert from bu xdr routines to ntohl()/htonl()
04:56.09CIA-77BRL-CAD: 03brlcad * r43436 10/brlcad/trunk/src/librt/primitives/ (dsp/dsp.c pipe/pipe.c pnts/pnts.c): more conversion from xdr routines to ntohl()/htonl()
04:57.09CIA-77BRL-CAD: 03brlcad * r43437 10/brlcad/trunk/src/librt/primitives/ars/ars.c: more conversion from xdr routines to ntohl()/htonl()
04:59.27CIA-77BRL-CAD: 03brlcad * r43438 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: more conversion from xdr routines to ntohl()/htonl() being careful to increment the buffer as char pointers, not as uint32_t pointers.
05:02.45CIA-77BRL-CAD: 03brlcad * r43439 10/brlcad/trunk/src/librt/primitives/bot/bot.c:
05:02.45CIA-77BRL-CAD: big deprecation conversion from xdr routines to posix.1 byteorder functions.
05:02.45CIA-77BRL-CAD: taking the address of element zero isn't strictly necessary but does make the
05:02.45CIA-77BRL-CAD: code more self-consistent given the slew of face and normal arrays that do
05:02.45CIA-77BRL-CAD: require element indexing.
05:05.48*** join/#brlcad Stattrav (~Stattrav@117.192.140.118)
05:05.49*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:53.22CIA-77BRL-CAD: 03brlcad * r43440 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c:
05:53.22CIA-77BRL-CAD: by far the most complex to date, deprecation conversion away from using xdr
05:53.22CIA-77BRL-CAD: routines to using posix.1 ntohl/htonl and friends. take care to increment as
05:53.22CIA-77BRL-CAD: char pointers and not long pointers. nmg apparently requires a LOT of
05:53.22CIA-77BRL-CAD: conversions...
05:59.22*** join/#brlcad Stattrav (~Stattrav@122.172.31.214)
05:59.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:03.18CIA-77BRL-CAD: 03brlcad * r43441 10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: update the last of the xdr to posix.1 byteorder function conversions. increment using our SIZEOF constants instead of hard-coding sizes too.
06:19.39CIA-77BRL-CAD: 03brlcad * r43442 10/brlcad/trunk/src/librt/primitives/tgc/tgc.c:
06:19.39CIA-77BRL-CAD: need librt_private.h for private flip func, also change call from rt_reldiff()
06:19.39CIA-77BRL-CAD: to a NEAR_EQUAL() due to deprecation. benchmark validation required but the use
06:19.39CIA-77BRL-CAD: here seems to be a fairly safe since we're considerably tightening the test
06:19.39CIA-77BRL-CAD: whether the vectors reduces the ellipse equation down to quadratic form. might
06:19.40CIA-77BRL-CAD: affect worst case performance but should provide the same results.
06:20.39CIA-77BRL-CAD: 03brlcad * r43443 10/brlcad/trunk/src/librt/primitives/tor/tor.c: torus also needs the private header and makes a call to the deprecated rt_fdiff() function. this becomes a simple loose tolerance comparison for equality.
06:25.26CIA-77BRL-CAD: 03brlcad * r43444 10/brlcad/trunk/include/db.h: formally deprecate the flip functions as API: rt_fastf_float(), rt_mat_dbmat(), and rt_dbmat_mat().
06:27.10CIA-77BRL-CAD: 03brlcad * r43445 10/brlcad/trunk/include/rtfunc.h: a callback for requesting an objects 'class' was never implemented. formally mark deprecation in header with compiler hints so warnings are issued on used.
06:27.59*** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net)
06:37.15*** join/#brlcad Stattrav (~Stattrav@117.192.239.174)
06:37.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:47.41*** join/#brlcad Stattrav (~Stattrav@117.192.231.70)
07:47.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:16.26*** join/#brlcad merzo (~merzo@193.254.217.44)
11:35.44*** join/#brlcad mafm_ (~mafm@242.Red-81-32-97.dynamicIP.rima-tde.net)
12:36.38*** join/#brlcad Elrohir (~kvirc@p5B14B620.dip.t-dialin.net)
14:25.26*** join/#brlcad mafm (~mafm@242.Red-81-32-97.dynamicIP.rima-tde.net)
14:40.40CIA-77BRL-CAD: 03bob1961 * r43446 10/brlcad/trunk/src/tclscripts/lib/TkTable.tcl: Added cadwidgets::TkTable::handleEnter and -entercommand
14:44.20*** join/#brlcad Stattrav (~Stattrav@117.202.23.211)
14:44.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:56.45CIA-77BRL-CAD: 03erikgreenwald * r43447 10/brlcad/trunk/ (include/bio.h src/librt/primitives/pnts/pnts.c): include headers for hton[ls]/ntoh[ls] family
19:04.09CIA-77BRL-CAD: 03erikgreenwald * r43448 10/brlcad/trunk/include/bio.h: winsock.h gets included via the windows.h megaheader, don't need to explicitly #include
19:11.28CIA-77BRL-CAD: 03erikgreenwald * r43449 10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: add fb2pix.c, pix2fb.c and libfb.lib
19:18.49CIA-77BRL-CAD: 03erikgreenwald * r43450 10/brlcad/trunk/misc/win32-msvc8/ (brlcad/brlcad.sln libtie/): libtie no longer exists, it's now part of librt
19:24.08CIA-77BRL-CAD: 03erikgreenwald * r43451 10/brlcad/trunk/misc/win32-msvc8/Makefile.am: automake should probably know that libtie.vcproj isn't around, too...
19:28.17*** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net)
19:29.00CIA-77BRL-CAD: 03erikgreenwald * r43452 10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: Add winsock library for htonl/ntohl/etc. Add tie/btg files.
19:41.39*** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net)
20:20.31*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
20:34.14*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
22:55.21CIA-77BRL-CAD: 03erikgreenwald * r43453 10/isst/trunk/cmake-modules/FindBRLCAD.cmake: libtie is no longer part of BRL-CAD
23:37.43CIA-77BRL-CAD: 03r_weiss * r43454 10/brlcad/trunk/src/libbn/bntester.c: Updates to bntester.c for testing functions bn_isect_line3_line3 and bn_isect_lseg3_lseg3.
IRC log for #brlcad on 20110225

IRC log for #brlcad on 20110225

02:37.00tofu_hmmm
02:37.12tofu_jansson is a pretty nice C lib
02:38.21brlcadthat might actually work as a table data container for nirt/gqa/rtcheck sortable formattable tabular output
02:43.44brlcadmm, and there's an even simpler boost templatized c++ header version too .. hmm
05:15.04*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
06:44.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:27.36*** join/#brlcad merzo (~merzo@193.254.217.44)
07:53.52*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:36.16*** join/#brlcad Stattrav (~Stattrav@122.172.159.245)
08:36.16*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:05.19*** join/#brlcad mafm (~mafm@119.Red-88-15-70.dynamicIP.rima-tde.net)
10:24.10*** join/#brlcad mafm_ (~mafm@119.Red-88-15-70.dynamicIP.rima-tde.net)
10:42.32*** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net)
10:56.59*** join/#brlcad roodolph (4dec0ed6@gateway/web/freenode/ip.77.236.14.214)
10:57.57roodolphis anybady try to compile Brl-CAD under Windows?
10:58.23roodolphis it possible?
11:10.14dliroodolph, yes, what have you tried?
11:11.16roodolphi try to compile brl cad source on dev c++
11:11.34roodolphbut it doesnt work
11:13.16roodolphthere was working many hours and nothing, just working, few days , nothig
11:13.36roodolphi dont know whats wrong
11:13.49roodolphwhat i have to do first
11:14.16roodolphto compile brlcad from source
11:14.20dliroodolph, have you tried cygwin/mingw, as doc says
11:14.34roodolphno
11:16.23roodolphso i have to run under linux for example
11:16.30dliroodolph, http://sourceforge.net/projects/brlcad/forums/forum/362511/topic/1681738?message=4180493
11:18.06dliroodolph, cygwin/mingw are under windows
11:23.20roodolphthanks a lot
11:23.59roodolphi m instaling cygwin
11:25.09*** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ)
11:26.08dliroodolph, if you want it look more native, mingw might be the way.
11:28.34roodolphhello
11:30.33*** join/#brlcad roodolph (4dec0ed6@gateway/web/freenode/ip.77.236.14.214)
11:31.16dliroodolph, please stay in channel and don't PM
11:31.47roodolphok
11:32.36roodolphso cygwin is the best way to compile brl cad on windows
11:33.44roodolphI run this program but i dont know what next i have to do
11:34.42roodolphi write mingw but program says mingw : command not found
11:36.07dliroodolph, http://www.mingw.org
11:39.17roodolphfirst i have to instal mingw on cygwin?
11:39.40roodolphor it's already there?
11:41.05dliroodolph, if you haven't done, you need to install them
11:45.32roodolphbut the idea is to compile brlcad source to get executable file (with .exe extension) for windows
11:46.22roodolphis it posssible wohever?
11:47.47roodolphprobably Visual Basic is neccecery, but im not sure
11:52.44roodolphthanks  a lot for all
11:53.06roodolphi try done it under cygwin
11:53.21roodolphi will see what happend
11:58.27roodolphmain problem in this moment ; how can i move files from windows to emulated linux
12:01.00dliroodolph, find the installation folder
12:01.41dliroodolph, cgywin/mingw are within the File system windows
12:01.42roodolphthx i find it, C:\cygwin\home\Konrad
12:02.22dliroodolph, you can mv files around, in cygwin or in windows
15:21.41CIA-77BRL-CAD: 03erikgreenwald * r43455 10/geomcore/trunk/tests/libNet/netMsgSerialTest.cxx: verify msg02 is not null before calling a method on it
15:22.23CIA-77BRL-CAD: 03erikgreenwald * r43456 10/geomcore/trunk/ (4 files in 2 dirs): wrap bu_vlb instead of re-implementing
15:27.46CIA-77BRL-CAD: 03erikgreenwald * r43457 10/geomcore/trunk/ (5 files in 4 dirs): eliminate redundant method
16:00.53CIA-77BRL-CAD: 03erikgreenwald * r43458 10/geomcore/trunk/ (include/DataStreamUtils.h src/utility/DataStreamUtils.cxx): simplify (and comment out) printByteArray
16:01.27CIA-77BRL-CAD: 03erikgreenwald * r43459 10/geomcore/trunk/ (include/ByteArray.h src/utility/ByteArray.cxx): remove the at method
18:30.19CIA-77BRL-CAD: 03erikgreenwald * r43460 10/geomcore/trunk/tests/GS/CMakeLists.txt: need tcl includes for BRL-CAD includes
18:32.34CIA-77BRL-CAD: 03erikgreenwald * r43461 10/geomcore/trunk/ (10 files in 3 dirs): eliminate DataStreamUtils
18:36.03CIA-77BRL-CAD: 03erikgreenwald * r43462 10/geomcore/trunk/src/utility/StringUtils.h: remove unused header
20:15.29CIA-77BRL-CAD: 03erikgreenwald * r43463 10/geomcore/trunk/src/libNet/netMsg/NetMsg.cxx: copy datastream into bytearray
20:17.02CIA-77BRL-CAD: 03erikgreenwald * r43464 10/geomcore/trunk/ (include/ByteArray.h src/utility/ByteArray.cxx): add assign method
20:18.52CIA-77BRL-CAD: 03erikgreenwald * r43465 10/geomcore/trunk/ (include/DataStream.h src/utility/DataStream.cxx): add size, fix up
20:31.10CIA-77BRL-CAD: 03erikgreenwald * r43466 10/geomcore/trunk/src/libNet/netMsg/NetMsg.cxx: fix reversed logic O.o
20:47.53CIA-77BRL-CAD: 03erikgreenwald * r43467 10/geomcore/trunk/tests/ (7 files in 7 dirs): name consistency
20:57.21CIA-77BRL-CAD: 03erikgreenwald * r43468 10/geomcore/trunk/src/libNet/netMsg/NetMsg.cxx: set reUUID to NULL in deserialize. Use hasReUUID instead of testing reUUIDsvn diff NetMsg.cxx=NULL in toString.
21:14.55CIA-77BRL-CAD: 03erikgreenwald * r43469 10/geomcore/trunk/tests/libNet/netMsgSerialTest.cxx: weee, colors
21:16.28CIA-77BRL-CAD: 03erikgreenwald * r43470 10/geomcore/trunk/tests/libNet/netMsgSerialTest.cxx: conditionalize some verbosity shtuffz
21:18.28CIA-77BRL-CAD: 03erikgreenwald * r43471 10/geomcore/trunk/tests/libNet/netMsgSerialTest.cxx: argv setting of verbose flag
21:20.43CIA-77BRL-CAD: 03erikgreenwald * r43472 10/geomcore/trunk/src/libNet/netMsg/GeometryManifestMsg.cxx: shortcircuit the string comparisons; if the lists are different lengths, then they're not equal.
21:21.08CIA-77BRL-CAD: 03erikgreenwald * r43473 10/geomcore/trunk/src/libNet/netMsg/NetMsg.cxx: woops, a little more reversed logic
21:26.34CIA-77BRL-CAD: 03erikgreenwald * r43474 10/geomcore/trunk/src/libNet/netMsg/GenericTwoBytesMsg.cxx: fix deserialize bug
21:31.31CIA-77BRL-CAD: 03erikgreenwald * r43475 10/geomcore/trunk/src/libNet/netMsg/SessionInfoMsg.cxx: use equals method instead of (nonexistant) overloaded ==/svn diff SessionInfoMsg.cxx=
21:59.00CIA-77BRL-CAD: 03erikgreenwald * r43476 10/geomcore/trunk/src/libNet/netMsg/GenericMultiByteMsg.cxx: Use memcpy and big appends instead of iterating (and making method calls) for each byte. Rewrite the constructor so it deserializes, instead of serializes (???).
22:02.02CIA-77BRL-CAD: 03erikgreenwald * r43477 10/geomcore/trunk/src/libNet/netMsg/GeometryManifestMsg.cxx: cast the char* to uint32_t* for the ntohl. Huzzah, gNetMsgSerialTest is 100% again!
IRC log for #brlcad on 20110226

IRC log for #brlcad on 20110226

03:20.34*** join/#brlcad PrezKennedy (MK@whitecalf.net)
05:08.05*** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net)
05:40.52*** join/#brlcad Stattrav (~Stattrav@117.192.227.117)
05:40.52*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:08.20*** join/#brlcad Stattrav (~Stattrav@122.172.159.245)
06:08.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:03.08*** join/#brlcad PrezKennedy (MK@whitecalf.net)
10:15.14*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
10:15.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:41.36*** join/#brlcad mafm_ (~mafm@137.Red-81-32-104.dynamicIP.rima-tde.net)
11:13.13*** join/#brlcad Stattrav (~Stattrav@122.172.159.245)
11:13.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:04.29*** join/#brlcad mafm (~mafm@137.Red-81-32-104.dynamicIP.rima-tde.net)
18:11.33*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
21:17.48*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
23:57.36*** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net)
IRC log for #brlcad on 20110227

IRC log for #brlcad on 20110227

01:23.53*** join/#brlcad willdye (~willdye@fern.dsndata.com)
04:25.36*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
08:43.52*** join/#brlcad Pline (~Aashim@61.153.16.162)
08:43.52*** part/#brlcad Pline (~Aashim@61.153.16.162)
08:45.52*** join/#brlcad Pline (~Aashim@61.153.16.162)
08:45.52*** part/#brlcad Pline (~Aashim@61.153.16.162)
10:28.20*** join/#brlcad mafm (~mafm@193.153.52.96)
12:30.25*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:36.13*** join/#brlcad Stattrav (~Stattrav@117.192.153.39)
14:36.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:58.06*** join/#brlcad mafm (~mafm@193.153.52.96)
16:35.05*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
22:05.34*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
23:57.11*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
IRC log for #brlcad on 20110228

IRC log for #brlcad on 20110228

01:30.01*** join/#brlcad Elrohir (~kvirc@p5B14BB8B.dip.t-dialin.net)
01:47.35*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
02:50.55*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
04:51.06CIA-77BRL-CAD: 03brlcad * r43478 10/brlcad/trunk/src/libfb/if_remote.c: convert libfb's remote framebuffer from using libbu's xdr routines to using the posix.1 byteorder functions, using hton*/ntoh*
05:10.56CIA-77BRL-CAD: 03brlcad * r43479 10/brlcad/trunk/src/conv/ (asc/asc2g.c asc/g2asc.c poly-bot.c stl/g-stl.c stl/stl-g.c): convert converters using the libbu xdr routines to using the posix.1 byteorder functions, using hton*/ntoh*
05:20.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:21.00CIA-77BRL-CAD: 03brlcad * r43480 10/brlcad/trunk/src/rt/viewray.c: call NEAR_EQUAL() instead of rt_fdiff()
05:21.35*** join/#brlcad Stattrav_ (~Stattrav@122.172.159.245)
05:24.06CIA-77BRL-CAD: 03brlcad * r43481 10/brlcad/trunk/src/librtserver/rtserver.c: more xdr to posix.1 byteorder function conversions, bu_plong to htonl
05:32.04CIA-77BRL-CAD: 03brlcad * r43482 10/brlcad/trunk/src/ (gtools/g_transfer.c remrt/rtsrv.c): since ext_buf buffers are now uint8_t*'s we need to cast them to char*'s for libpkg (until libpkg is upgraded).
05:49.32CIA-77BRL-CAD: 03brlcad * r43483 10/brlcad/trunk/src/libged/bot_dump.c: convert from xdr bu_plong() to byteorder htonl()
05:51.29CIA-77BRL-CAD: 03brlcad * r43484 10/brlcad/trunk/include/raytrace.h:
05:51.29CIA-77BRL-CAD: now that all usages should be weeded out, formally deprecate rt_fdiff() and
05:51.29CIA-77BRL-CAD: rt_reldiff() in the header. not 100% equivalent, so use with caution, but
05:51.29CIA-77BRL-CAD: recommend most conversions change to NEAR_EQUAL(a,b,0.001) and EQUAL(a,b)
05:51.29CIA-77BRL-CAD: respectively.
05:55.23CIA-77BRL-CAD: 03brlcad * r43485 10/brlcad/trunk/ (include/bu.h src/librt/db5_io.c):
05:55.24CIA-77BRL-CAD: formally deprecate the old eXternal Data Representation (XDR) functions via API
05:55.24CIA-77BRL-CAD: markers. all of the bu_p(long|short|etc) and bu_g(long|short|etc) functions
05:55.24CIA-77BRL-CAD: have comparable byteorder functions provided standard via posix.1 as hton(l|s)
05:55.24CIA-77BRL-CAD: and ntoh(l|s). the one exception is support for converting 64-bit long long
05:55.24CIA-77BRL-CAD: types, so use the recently added configure.ac tests and define htonll() and
05:55.25CIA-77BRL-CAD: ntohll() respectively as macros supporting big and little endian platforms.
06:04.19CIA-77BRL-CAD: 03brlcad * r43486 10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: convert from xdr to standard byteorder functions casting accordingly.
06:05.26CIA-77BRL-CAD: 03brlcad * r43487 10/brlcad/trunk/doc/deprecation.txt: minimally impacting change, renaming V2APPROXEQUAL() to V2NEAR_EQUAL() in order to match the other *NEAR_EQUAL() macros.
06:10.49CIA-77BRL-CAD: 03brlcad * r43488 10/brlcad/trunk/ (include/vmath.h src/proc-db/surfaceintersect.cpp): minimally impacting API change, rename V2APPROXEQUAL to V2NEAR_EQUAL so the api is more self-consistent.
10:12.29starseekerbrlcad: you're referring to the C JSON library jansson?
10:16.18dloman-a1kMernin all
10:16.49starseekerdloman-a1k: morning!
10:20.16dlomanugh, lots to read, heh
10:20.33starseekerhehe
10:20.47dlomanso, in my interwebz wandering, i found a QT wrapper for the svn libs :)
10:20.56dlomanbookmarked it, didnt have time to look at it.
10:21.18dlomanjust thought it was funny since erik is mostly done with the ripout
10:22.55dlomanstarseeker: what version of cmake are you using?
10:23.04starseeker2.8.3
10:23.11dlomanjust got a 'new' used laptop and am re-installing *everything*
10:23.18starseekerI think 2.8.4 is out
10:23.43dlomankk, so 2.8.2 won't cause the world to end then.
10:24.03starseeker*probably* not, but there do tend to be legitimate bug fixes/improvements in each release
10:24.10starseekerparticularly with respect to VS2010
10:24.12dlomanright on
10:24.33starseekerIf 2.8.2 is the easy install, go for it
10:24.41dlomanexactly :)
10:24.48dlomanone click == my kinda install
10:24.54starseekerthe only thing I know that has issues with 2.8.2 is the Windows visual studio stuff
10:25.16starseekerthere may be others though - I'd have to check
10:25.54dlomanthat fine by me.  I dont have any plans on doing anything with VS2xxx
10:26.01dlomanin the immediate future that is..
10:26.09dlomaneventually, I'll have to deal with it
10:26.10starseekerIf possible, I tend to prefer fixing CMake as opposed to ugly workarounds in our logic, and we do do some fairly funky stuff in a few cases, so let me know if you see any issues
10:26.22dlomankk
10:26.33starseekerCMake is pretty easy to install if it comes to that
10:26.35dlomanverizon dsl sucks, so the checkout will take time :/
10:26.41starseekernods
10:27.17starseekerdloman: of course, if you're just doing geomcore and not all of BRL-CAD that should be simpler
10:27.42dlomanI am soooooo going with xfinity or fios when they hit my area...
10:27.53starseekermmmm, fiber
10:27.53dlomanI think I will get and try cmake on both of those.
10:28.18dlomanI have resigned myself to the fact that a bulk of today will be spent downloading/config-ing/t-shooting
10:28.24starseekerheh
10:28.35starseekerhas a week of email to read
10:28.49dlomanyou take last week off as well?
10:28.54starseekerhoneymoon
10:29.23starseekerthat's why I'm awake right now
10:29.33dlomanright on!
10:29.35dlomanhave fun?
10:29.36starseekertime zones are still messed up
10:29.47dlomanoh, you are currently ON your honeymoon?
10:29.56starseekerit was awesome, aside from me being an idiot and losing my ticket for one event
10:30.01starseekernope, got back last night
10:30.06dlomannice.
10:30.12dlomanmind if I ask where u went?
10:30.19starseekergot yelled at by the cats... oh boy
10:30.22starseekerSpain
10:30.32dlomansweet!
10:30.41dlomanfun then?
10:30.45starseekeryep
10:30.49starseekerdid a lot of tours
10:30.53dlomannice :)
10:31.25starseekergetting put back together - will have to hit the store on the way home tonight
10:32.26dlomanwatch the weather.  somehow a big nasty t-storm snuck up on me/PA/MD without me noticing it on the weather map :)
10:32.30starseekerdloman: was this the binding you found?
10:32.32starseekerhttp://kdesvn.alwins-world.de/
10:32.39starseekerow
10:33.12dlomanno, i don';t think that was it.
10:33.38dlomanlet me dig really quick
10:34.50dlomanlibsvnqt4
10:34.54dlomanme thinks it was
10:35.06dlomanlike i said.  I saw it, bookmarked it... and that's it.
10:35.08starseekerthat sounds like debian packaging of a subset of kdesvn
10:35.11dlomandidn't take a look.
10:36.38starseekerwe'll probably be talking directly to the C api of the various subversion sub-libraries
10:37.26starseekerI'm pondering whether the best approach would be to actually "port" both the svn fs-fs backend and the checkout logic itself to work inside of a .g instead of files
10:38.16starseekerthat's probably one *bleeping* lot of work, particularly the checkout (which I expect makes lots of assumptions about files on a filesystem being the intended checkout output)
10:38.50dlomanmight be the best, but def not the fastest.
10:39.07starseekerdoesn't matter too much right now, since most of the work needed for the break it down to regions and make files approach is still needed for other approaches
10:39.16dlomanright on.
10:39.26dlomanI plan on diving headlong into that very aspect asap
10:39.48starseekerdloman: I need to get search to behave as proper db functions first
10:40.07starseekerthat'll be the best/only(?) way to get a list of assemblies (combinations above regions)
10:40.08dlomanfirst... meaning before what?
10:40.37starseekeronce I have that list, and a list of regions, I can keep each into its own file
10:40.39dlomandef not the only.  a tree/dag walk would be one.
10:40.58starseekershakes head - we need to write out the assemblies as their own files
10:41.09dlomanya
10:41.20starseekerthey aren't below regions (in a proper .g anyway) and won't be kept by a "save the regions" approach
10:41.40starseekerwe need to identify the subset of combs that aren't below any regions and save those
10:41.42dlomanokay, i think I am missing something then.
10:41.48starseekerhmm?
10:42.18dlomanif we do a depth first search, everything in the path leading up to the region *must* be a combination..... yes?
10:42.27dlomans/search/walk/
10:42.51starseekeroh, you mean take the tops list and work with that as the starting point?
10:42.56dlomanya
10:43.14starseekerponders...
10:43.19dlomansince this is sometihng that will only be run once per file, speed shouldn't be a major concern
10:44.17starseekeryeah, that would probably work, but the search approach is still worthwhile because it can also be used to spot problems
10:44.31starseeker(regions under regions, non-union operations in assemblies)
10:44.43dlomansure.  Im thinking timeline wise though, since end of march is our target
10:45.15starseekerdloman: I actually got search working as a C function just before I left, but I didn't do it "right" from an API standpoint
10:45.45starseekerand since we're supposed to be "done" at end of march, I want search's ability to identify near-arbitrary subsets of things
10:45.56starseekerthat power may be necessary for robustness
10:46.20dlomanoh it will :)
10:46.37dlomanbut robustness isn't on the list of things needed for the deliverable :P
10:46.41dloman(that was a joke btw)
10:46.45starseekerhehe
10:47.14dlomango go gadget timesheet :/
10:48.24starseekerdloman: one thing that would help quite a lot is if you and brlcad could summarize the "finalize" approach you two cooked up
10:48.44dlomanheh, well, we have to sit down and powwow again.
10:48.45starseekerthe functionality needed for that is essentially the TODO lsit
10:48.50starseekers/lsit/list/
10:49.16dlomanwhat I have the notes for and what was 'understood' by both parties is not in sync.
10:49.31starseekernods
10:49.33dlomani think maybe brlcad ``Erik you and i should all sit in
10:49.51dlomanperhaps later this week if our schedules align
10:51.05starseekersure - I'd mainly be listening, because it sounds like most of the major problems were conceptually resolved - what we need now is a "do this to librt to support namespaces, hook this up to svn, do this to combine invidual .g region files into an assembly .g object to satisfy a geomclient request, etc
10:52.20starseekerwe also need to decide what has to be in GE (if anything) to achieve basic functionality
10:52.23dlomanexactly. task breakdown!
10:52.55dlomanheh, I don't know why I ever said yes to the gs project... it was waaaay over my head for a newbie :/
10:53.05starseekerhehe
10:53.10starseekertrial by fire
10:53.40starseekerprobably would have been less tramatizing to do it the way I did - spend a month making tires :-P
10:53.54dlomannice
10:54.08dlomani still want to make the proc-db for making houses.
10:54.14dlomanthat'd be fuuuun
10:54.53dlomancurses at the vpn
10:55.23starseekerputs stuff together and heads out... the rumble you will hear soon will be me being buried under email
11:16.56*** join/#brlcad Stattrav (~Stattrav@122.167.254.137)
11:16.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:34.16dlomanso... offsite is posponed?
11:55.13*** join/#brlcad Stattrav (~Stattrav@122.167.254.137)
11:55.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:12.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:12.46CIA-77BRL-CAD: 03davidloman * r43489 10/jbrlcad/trunk/: Modify svn:ignore to ignore .settings directory (generated by eclipse)
12:14.59CIA-77BRL-CAD: 03davidloman * r43490 10/geomcore/trunk/src/interfaces/java/: Modify svn:ignore to ignore .classpath and .project files (generated by eclipse)
12:24.15*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:25.09dlomanXi is the x lib's input lib, right?
12:29.05*** join/#brlcad Stattrav (~Stattrav@122.167.254.137)
12:29.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:42.36*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
12:54.06dlomanNoob question:  brlcad's config can't seem to find libXi, but i know its installed and where its at.  How do i tell brlcad's config where it is?
13:12.35starseeker--with-x and the X11 location may work
13:13.01starseekeralso, if you just installed libXi-dev you may need to clear cache and reconfigure
13:15.50dlomanawesome, tanks!
13:19.47starseekerDoes anyone remember if gecode (http://www.gecode.org/) was discussed back when the parametric constraint Google Summer of Code project was being worked?
13:21.11starseekeralso, http://www.g12.cs.mu.oz.au/minizinc/
13:23.42dlomanis there a standard lex that we should use for brlcad?
13:24.11starseekeruh... not really, but I'd be very surprised if you've got anything except flex
13:25.43dlomanthanks, you answered my quetion indirectly =D
13:39.40starseekerconfesses he is not up on the constraint stuff, but geocode and friends sound at first glance like they are quite relevant and interesting
13:50.06CIA-77BRL-CAD: 03starseeker * r43491 10/brlcad/branches/cmake/ (114 files in 60 dirs): MFC r43490
13:54.32dlomanstarseeker: the TERMLIB cmake flag.... is it looking for libterm?
13:55.26starseekerdloman: not just libterm - it's supposed to look for a whole bunch of possible suppliers for the subset of termlib we need, and if it's not found enable our local copy
13:55.31starseekerwhat's the error?
13:56.00dlomanconfig is saying 'Could NOT find TERMLIB'
13:56.10starseekerautotools?
13:56.12dlomanjust trying to figure out what i should install.
13:56.14dlomancmake
13:56.28starseekerthat's surprising
13:56.38starseekerif it's not found it should just fall back on src/other
13:57.02dlomanits not erroring out, im just trying to fill out as many libs as possible.
13:57.05starseekerjust install the ncurses dev package if you want something on the system
13:57.08dlomanthis is a brandy new install of ubuntu
14:05.49CIA-77BRL-CAD: 03starseeker * r43492 10/brlcad/branches/cmake/src/tab/CMakeLists.txt: Clear out txyz-pl from src/tab CMakeLists.txt file
14:30.22CIA-77BRL-CAD: 03starseeker * r43493 10/brlcad/branches/cmake/misc/enigma/CMakeLists.txt: enigma is not, properly speaking, a BRL-CAD program - don't use BRLCAD_ADDEXEC macro (we don't want to hit it with the strict flags, same as src/other
14:33.38*** join/#brlcad Stattrav (~Stattrav@122.167.254.137)
14:33.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:37.40CIA-77BRL-CAD: 03starseeker * r43494 10/brlcad/branches/cmake/src/tclscripts/ (archer/CMakeLists.txt lib/CMakeLists.txt): cursor.tcl moved
14:48.45starseekerhmm... http://www.cs.washington.edu/research/constraints/cassowary/
14:49.51starseekerneeds this http://www.fim.uni-passau.de/fileadmin/files/lehrstuhl/brandenburg/projekte/gtl/GTL-1.2.4-lgpl.tar.gz
14:51.27starseekergeocode sounds more modern and supported, if the domains overlap properly
15:53.04CIA-77BRL-CAD: 03starseeker * r43495 10/brlcad/branches/cmake/src/tab/CMakeLists.txt: Problem - the lex generated output is triggering warnings. Gonna have to go with -Wno-error until we get a flex/byacc solution in place we can rely on/tweak to generate error free code.
15:56.24brlcadstarseeker: what were the warnings?  during my cleanup a couple weeks ago, several of the lex-generated output warnings were controlled by settings in the lex/yacc files
15:56.32brlcadi.e., they were easily quellable
15:56.40brlcadwelcome back too :)
15:58.44starseekerbrlcad: thanks :-)
15:58.46starseekerscript.c:34:5: warning: "__STDC_VERSION__" is not defined
15:59.01starseekerscript.c:1020: warning: label ‘find_rule’ defined but not used
15:59.14starseekerscript.c:1439: warning: comparison between signed and unsigned
15:59.23starseekerscript.c:2138: warning: ‘yy_flex_strlen’ defined but not used
16:01.21CIA-77BRL-CAD: 03starseeker * r43496 10/brlcad/trunk/src/ (canon/canonize.c librtserver/rtserver.c rt/view.c sig/fhor.c): Various quellage
16:04.13CIA-77BRL-CAD: 03d_rossberg * r43497 10/brlcad/trunk/src/ (conv/CMakeLists.txt conv/stl/stl-g.c librt/CMakeLists.txt): ntohl(): missing includes and libraries for the MSVC CMake build (needs WinSock 2)
16:04.21CIA-77BRL-CAD: 03starseeker * r43498 10/brlcad/branches/cmake/ (32 files in 31 dirs): There we go - strict compile flags are now the default throughout the BRL-CAD src directories, with the exception of src/other
16:09.07brlcadthanks, interesting diff set of warnings
16:10.47starseekerbrlcad: do you recall if gecode was ever mentioned in the parametric constraint lib discussions?
16:11.43dlomanstarseeker: the cmake command to find x was: cmake --with-x <pathToSrc> ??
16:11.44brlcadnah, I don't really recall
16:11.49brlcadstarseeker: what's the gain?
16:12.36starseekeri'm thinking it might actually have a working constraint solver on top of which we would define our constraints
16:12.49brlcadisn't keen on bio.h having networking, that expands the scope a bit..
16:12.53starseeker(i.e. it sounds kind of like what the gsoc project was trying to develop)
16:13.04dlomantryin to fix a linker error:  cannot find -lXss (-lXft and -lXrender)
16:13.42starseekerum.  Ubuntu might break those out into separate packages...
16:14.03dlomandid a find and I have them... so how do I supply paths to cmake?
16:14.08brlcadstarseeker: it's definitely related -- there are dozens of constraint solver libraries out there
16:14.21brlcadeach with their merits and deficiencies..
16:15.15starseekerbrlcad: that's what I was wondering - presumably there must have been a review of those before we went for writing our own...
16:16.04brlcadpossibly, but that would have been pre-submission
16:16.05starseekerdloman: it's rather disturbing they aren't being found
16:16.16starseekernuts
16:16.51starseekerdloman: can you post the results of make VERBOSE=1 that are related to the failure?
16:16.57dlomanstarseeker: if it helps, all the libs are in /usr/lib and /usr/lib32
16:17.00dlomankk, will do
16:17.39brlcadstarseeker: it's kinda the same situation as writing a solver for nurbs surface evaluation -- "surely there was a review of existing root solvers before we went for writing our own"
16:17.50brlcadthe answer is "yes and no"
16:18.14brlcadthe solver is fairly tied to the data structures, same with constraints
16:19.48starseekerah
16:20.02brlcadfwiw, much of libpc isn't the actual constraint solving but the data structures for representing a constraint, the bridge for librt to use
16:20.14brlcadso you could conceivably hook in any constraint solver under the hood
16:20.25starseekernods - that might be interesting to look at
16:20.47brlcadas would determining where the current implementation is actually at
16:21.05starseekerwas doing some reading of SICP, and their description of what a constraint system does/is good for kind of set off a light bulb
16:21.06brlcadfor all we know, it could be done and working perfectly for our needs
16:21.48starseekernot that I have time to fool with it now of course, but it sounds quite interesting
16:22.15brlcadwhen I reviewed his work back during gsoc, it actually seemed to be working very well
16:22.48brlcadthe problems he was working on were problems we were not yet faced with, solving multiple constraints simultaneously
16:23.06brlcadthere are sample test driver programs in the tree that show it working
16:23.45starseekernods. I'm just wondering how hard it would be to shake out bugs and demonstrate robustness there vs. using something like gecode under the hood for the actual solving part...
16:23.57starseekerbut the only way to know that is to dig into it
16:24.34brlcadyou won't know whether gecode is better or worse without writing a test driver that evaluates the current state of affairs regardless
16:24.42starseekerright
16:25.20brlcadgiven there are already some simple test drivers, it would be an intersting comparison
16:25.30brlcaduseful too, it's a current year task
16:25.50starseekernods - maybe I can dive in after the geometry service gets beaten into submission
16:25.50brlcadsomeone will have to investigate and evaluate before the year's up
16:26.03brlcadhas the same deadline as the GS iirc :)
16:26.12starseekerO.o
16:26.12brlcadmuch smaller task, though
16:26.34starseekercrawls under his desk and hides...
16:26.46starseekerand then realizes that's a bad place to code from
16:26.51brlcadfrack.. end of month
16:26.54brlcadtime to release!
16:27.01brlcaddamn short month
16:27.12starseekerwinces
16:28.02brlcadgsoc org submissions opens up today too
16:28.23brlcadif we're going to participate, someone is going to have to get started on writing up a new task list on the wiki
16:28.24starseekerdo you want me to do the librt search port in CMake to avoid messing with trunk?
16:28.35brlcadheck no :)
16:28.59brlcadsearch port?
16:29.07brlcadsounds rather un-cmakeing
16:29.20starseekersure, but it's a nasty thing to do during a release cycle
16:29.29starseekerwhoops, bbl
16:29.55brlcadjust have to be more careful to not break build or functionality during commits, just talking a day or two to test and tag
16:37.13CIA-77BRL-CAD: 03brlcad * r43499 10/brlcad/trunk/TODO:
16:37.13CIA-77BRL-CAD: release tasks were not completed by the end of the month, so push to the next
16:37.13CIA-77BRL-CAD: iteration. only remaining task that comes to mind is removing the network dep
16:37.13CIA-77BRL-CAD: from bio.h (need a separate header since it's just for standard i/o)
17:04.38CIA-77BRL-CAD: 03brlcad * r43500 10/brlcad/trunk/src/libged/CMakeLists.txt: add fb2pix.c and pix2fb.c
17:18.41CIA-77BRL-CAD: 03jordisayol * r43501 10/brlcad/trunk/misc/debian/changelog: update debian changelog
18:11.41CIA-77BRL-CAD: 03brlcad * r43502 10/brlcad/trunk/include/ (Makefile.am bin.h):
18:11.41CIA-77BRL-CAD: add an initial corrollary header file similar to bio.h but for internet
18:11.41CIA-77BRL-CAD: networking instead of input/output. it's similarly a 'private' self-contained
18:11.41CIA-77BRL-CAD: header (so no HAVE_* defines), but should help consolidate the header
18:11.41CIA-77BRL-CAD: preprocessor logic into one place. this header is effectively treated as a
18:11.42CIA-77BRL-CAD: system header coming before inclusions of brl-cad public/private headers.
18:14.23CIA-77BRL-CAD: 03brlcad * r43503 10/brlcad/trunk/src/librt/Makefile.am: missing the tieprivate.h header
18:16.50CIA-77BRL-CAD: 03brlcad * r43504 10/brlcad/trunk/src/librtserver/rtserver.c: include headers for htonl
18:20.17CIA-77BRL-CAD: 03brlcad * r43505 10/brlcad/trunk/src/librt/primitives/pnts/pnts.c: include bin.h instead of bio.h for htonl and friends
18:22.32CIA-77BRL-CAD: 03brlcad * r43506 10/brlcad/trunk/include/bio.h:
18:22.32CIA-77BRL-CAD: remove inclusion of arpa/inet.h from bio.h since it's not desirable to bundle
18:22.32CIA-77BRL-CAD: networking routines in with the input/output routines. this is in part due to
18:22.32CIA-77BRL-CAD: the implied dependency on the windows socket library on the windows platform,
18:22.32CIA-77BRL-CAD: which isn't necessarily true for inclusions only needing standard i/o. the new
18:22.33CIA-77BRL-CAD: bin.h internet networking header now covers networking.
18:28.16CIA-77BRL-CAD: 03brlcad * r43507 10/brlcad/trunk/src/librt/db5_io.c: need bin.h instead of bio.h
18:29.24CIA-77BRL-CAD: 03brlcad * r43508 10/brlcad/trunk/src/librt/db_scan.c: ditto, bio.h -> bin.h for networking
18:34.20CIA-77BRL-CAD: 03brlcad * r43509 10/brlcad/trunk/src/libged/bot_dump.c: need networking and i/o functions here, so also include bin.h
18:34.30CIA-77BRL-CAD: 03brlcad * r43510 10/brlcad/trunk/src/librt/ (11 files in 11 dirs): promulgation continues, switch from bio.h to bin.h where byteorder functions are being used.
18:34.34``Erikthe arpa inet header in bio.h was for htonl/ntohl
18:35.00``Erik*readreadread*
18:36.11``Erikhm, *update;compile* O.o
18:36.42CIA-77BRL-CAD: 03brlcad * r43511 10/brlcad/trunk/src/conv/ (asc/asc2g.c asc/g2asc.c poly-bot.c stl/g-stl.c): and maybe the last batch of bin.h inclusions needed.
18:36.51brlcadI know - but that made the header pull in more than just i/o
18:37.06brlcadthe wrapper header was needed, just made a new file
18:37.19brlcadone for just networking
18:37.41brlcadso anything that includes that file is implicitly requiring ws2_32.lib
18:38.56brlcadsucks that byteorder is in winsock on windows .. the bu xdr funcs provided a nice encapsulation from that perspective, but still probably better unwrapped
18:40.18CIA-77BRL-CAD: 03starseeker * r43512 10/brlcad/branches/cmake/CMakeLists.txt: Try InstallRequiredSystemLibraries on Windows MSVC
18:41.14CIA-77BRL-CAD: 03brlcad * r43513 10/brlcad/trunk/src/conv/stl/stl-g.c: nope, missed one
18:46.58*** join/#brlcad Ralith (~ralith@d142-058-095-076.wireless.sfu.ca)
19:00.17CIA-77BRL-CAD: 03starseeker * r43514 10/brlcad/branches/cmake/ (36 files in 24 dirs): MFC r43513, update CMakeLists.txt files to include winsock in more places (untested)
19:04.13starseekerah, homovulgaris mentioned gecode back in 2008
19:16.03CIA-77BRL-CAD: 03erikgreenwald * r43515 10/brlcad/trunk/include/bin.h: need sys/types.h for netinet/tcp.h
19:21.41``Erikprobably should be wrapping some #ifdef HAVE_SOME_H in there *shrug*
19:24.30CIA-77BRL-CAD: 03erikgreenwald * r43516 10/brlcad/trunk/include/bin.h: #define <winsock2.h> doesn't quite work
19:25.21brlcadheh
19:26.14brlcad``Erik: bio.h and bin.h intentionally do not have HAVE_* defines since they're not supposed to be tied to configure -- more like system header replacements
19:27.10brlcadthey could be converted / coupled with configure feature testing, but it would change a few things
19:41.18CIA-77BRL-CAD: 03davidloman * r43517 10/brlcad/branches/cmake/: Modify svn:ignore to ignore .classpath and .project files (generated by eclipse)
19:59.10*** join/#brlcad ibot (~ibot@rikers.org)
19:59.10*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
20:29.05*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
20:53.07CIA-77BRL-CAD: 03brlcad * r43518 10/brlcad/trunk/src/mged/attach.c: include bin.h instead of including winsock2.h directly
20:55.25CIA-77BRL-CAD: 03brlcad * r43519 10/brlcad/trunk/configure.ac:
20:55.25CIA-77BRL-CAD: there's no reason to leave out the gnu extensions other than to try and avoid
20:55.25CIA-77BRL-CAD: non-standard functions. in practice, however, c99 compliance means we also
20:55.25CIA-77BRL-CAD: don't get the posix functions, which is somewhat problematic. change the
20:55.25CIA-77BRL-CAD: compliance from std99 to gnu99.
21:13.11CIA-77BRL-CAD: 03brlcad * r43520 10/brlcad/trunk/src/util/dunncomm.c: wrong comment
21:21.30CIA-77BRL-CAD: 03brlcad * r43521 10/brlcad/trunk/src/libfb/if_ogl.c: no longer need the __BSD_VISIBLE/__USE_XOPEN/__USE_BSD hacking to get the extension decls with configure using gnu99.
21:35.36CIA-77BRL-CAD: 03brlcad * r43522 10/brlcad/trunk/src/tab/script.l: overcome flex stupidities, define undefined to false in order to appease preprocessor logic.
21:48.56CIA-77BRL-CAD: 03brlcad * r43523 10/brlcad/trunk/src/ (16 files in 16 dirs):
21:48.56CIA-77BRL-CAD: enable the remainder of strict flags now that the build is verified across mac
21:48.56CIA-77BRL-CAD: and linux. now all of brl-cad's source code builds strict-clean for improved
21:48.56CIA-77BRL-CAD: security, maintainability, conformance compliance, stability, reliability, and
21:48.56CIA-77BRL-CAD: more.
21:54.40CIA-77BRL-CAD: 03brlcad * r43524 10/brlcad/trunk/src/remrt/ihost.c: replace the net headers with bin.h
22:31.23*** join/#brlcad guest_tttt (~rm@123.136.11.66)
22:31.45guest_tttt.....
22:33.48*** part/#brlcad guest_tttt (~rm@123.136.11.66)
22:37.11*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
23:02.16*** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
23:02.17CIA-77BRL-CAD: 03brlcad * r43525 10/brlcad/trunk/src/conv/Makefile.am: missing the shapefil.h header
23:09.15*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
23:13.59CIA-77BRL-CAD: 03starseeker * r43526 10/brlcad/trunk/include/raytrace.h: search will need regex.h once it is moved to librt
23:16.52CIA-77BRL-CAD: 03starseeker * r43527 10/brlcad/trunk/src/librt/ (Makefile.am search.c search.h): Add work done so far on search move to librt - not being added to the compile until after the release.
23:28.54CIA-77BRL-CAD: 03starseeker * r43528 10/geomcore/trunk/tests/svntest/CMakeLists.txt: fix install target for svnTest
23:38.27CIA-77BRL-CAD: 03starseeker * r43529 10/brlcad/branches/cmake/ (CMakeLists.txt src/other/CMakeLists.txt): Move the TERMLIB option to src/other - we need this set in advance of the third party logic.
IRC log for #brlcad on 20110301

IRC log for #brlcad on 20110301

00:13.24CIA-77BRL-CAD: 03starseeker * r43530 10/brlcad/branches/cmake/CMakeLists.txt: Remove the complex and only partially successful noprod logic - with targets in toplevel bin dirs anyway the utility is minimal, and not worth the complexity.
00:36.45CIA-77BRL-CAD: 03starseeker * r43531 10/brlcad/branches/cmake/ (3 files in 3 dirs): Ignore other in src
00:39.42CIA-77BRL-CAD: 03starseeker * r43532 10/brlcad/branches/cmake/src/librt/CMakeLists.txt: Ignore search.h
00:50.20*** join/#brlcad Klebel (~mk@w73.RIC.Berkeley.EDU)
00:50.49KlebelI can't find 'Set H' in the Edit menu
00:57.36Klebelpress "Set H"  - says unknown operation.
00:57.45Klebelon the command line
00:58.31starseekerKlebel: we need more context
00:59.29Klebelpage 60 in the Introduction to MGED manual.
00:59.29Klebelpdf
01:00.22KlebelI created a right circular cylinder, then it tells me to do, "Edit and then Set H"
01:00.33Klebeland click the middle mouse button several times
01:01.02starseekerto edit a primitive, you need to use sed
01:01.08starseekerthat puts you in edit mode
01:02.05starseekerif you aren't seeing Set H you probably aren't in edit mode
01:02.08Klebelah, so sed base1.s
01:02.08Klebelthanks, Set H is now in the menu, and works
01:02.29starseekerthat tutorial was created with an older version of BRL-CAD, so there are occasional differences
01:02.43Klebelyea I've noticed that :/
01:07.15Klebelis there a command to get out of edit mode?
01:07.26starseekeraccept or reject
01:07.40Klebelok thanks
01:09.02CIA-77BRL-CAD: 03starseeker * r43533 10/brlcad/branches/cmake/ (27 files in 22 dirs): MFC r43532
01:10.42CIA-77BRL-CAD: 03starseeker * r43534 10/brlcad/branches/cmake/src/other/CMakeLists.txt: Uncomment -w again for src/other
01:17.39CIA-77BRL-CAD: 03starseeker * r43535 10/brlcad/branches/cmake/misc/CMake/CompilerFlags.cmake: We're going for gnu99 now
02:01.02CIA-77BRL-CAD: 03brlcad * r43536 10/brlcad/trunk/src/bwish/cadAppInit.c: include bin.h instead of winsock2.h
03:28.05*** join/#brlcad guest_tttt (~rm@123.136.11.66)
03:34.43*** part/#brlcad guest_tttt (~rm@123.136.11.66)
04:32.23*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
04:33.44CIA-77BRL-CAD: 03brlcad * r43537 10/brlcad/trunk/src/rttherm/pixtest.c: check fwrite return value
04:36.11CIA-77BRL-CAD: 03brlcad * r43538 10/brlcad/trunk/src/sig/ (24 files): check fwrite return values for failure
04:39.55CIA-77BRL-CAD: 03brlcad * r43539 10/brlcad/trunk/src/proc-db/brepintersect.cpp: compiler is complaining about the first param to SegmentPolylineIntersect possibly being NULL. as this is dev code, just comment out for now in leu of removing the code.
04:44.14CIA-77BRL-CAD: 03brlcad * r43540 10/brlcad/trunk/src/mged/points/points_parse.y: bison is being stupid with some output code generating size_t comparisons against >= 0. quell that warning along with a couple other preprocessor symbols that are not defined but being used in expressions.
04:45.52CIA-77BRL-CAD: 03brlcad * r43541 10/brlcad/trunk/src/ (mged/points/points_scan.l tab/script.l): quell flex lameness where fwrite() is being called without checking the return value. this quiets the compiler.
04:51.08CIA-77BRL-CAD: 03brlcad * r43542 10/brlcad/trunk/src/ (23 files in 7 dirs):
04:51.09CIA-77BRL-CAD: categorically check return values for some of the stdio and stdlib routines
04:51.09CIA-77BRL-CAD: (e.g. fwrite, scanf, system, dup, pipe, ...). not willing to put forth
04:51.09CIA-77BRL-CAD: time/effort to do anything more than print the error since would have to
04:51.09CIA-77BRL-CAD: evaluate each call on a case by case basis (and that's not fun).
05:10.50*** join/#brlcad dli (~dli@dsl-67-204-45-87.acanac.net)
05:35.23*** join/#brlcad Stattrav (~Stattrav@122.167.254.137)
05:35.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:08.23CIA-77BRL-CAD: 03brlcad * r43543 10/brlcad/trunk/src/libfb/if_X24.c: fix keybindings on Mac OS X so that cmd-click will produce button 3 events (so we can close framebuffers) without needing the user to set X11.app to emulate a three button mouse.
06:09.28CIA-77BRL-CAD: 03brlcad * r43544 10/brlcad/trunk/src/libfb/if_ogl.c: do the same mouse-3 binding for ogl
06:51.11Klebel1 thing I keep noticing in the Introduction manual, is that when I copy primatives through the command line then run sed on the newly copied primative it says: Error sph2.s not being displayed
06:51.37Klebelthe only way I am able to copy is through the Primitive Editor
07:01.04CIA-77BRL-CAD: 03brlcad * r43545 10/brlcad/trunk/src/tclscripts/mged/bindings.tcl:
07:01.04CIA-77BRL-CAD: fix mged zoom bindings on mac os x with default X11 (where 3-button mouse
07:01.04CIA-77BRL-CAD: emulation is disabled) so that you can actually zoom out. make cmd-click behave
07:01.04CIA-77BRL-CAD: the same as button-3. unfortunately, the same binding does not seem possible
07:01.04CIA-77BRL-CAD: with option-click for mouse 2 (in fact, option seems to act like mod2 aka the
07:01.04CIA-77BRL-CAD: command-key. none of the other mod types seem to help.
07:07.37CIA-77BRL-CAD: 03brlcad * r43546 10/brlcad/trunk/NEWS:
07:07.38CIA-77BRL-CAD: fixed a problem being able to zoom in with the default x11.app configuration
07:07.38CIA-77BRL-CAD: where you could zoom out, but not back in without enabling 3-button emulation.
07:07.38CIA-77BRL-CAD: this binds command+button1 the same as button3. couldn't get option+button1 to
07:07.38CIA-77BRL-CAD: behave as button2 though.
07:10.21CIA-77BRL-CAD: 03brlcad * r43547 10/brlcad/trunk/src/librt/primitives/table.c: tested and rt_generic_xform() is NOT sufficient. wrong plot and trace with loads of error.
07:10.47brlcadKlebel: when you copy something, it's not automatically drawn
07:10.57brlcadcp old new ; e new
07:11.07brlcadthen sed and friends will work
07:11.12brlcad(on new)
07:11.25brlcade == draw
07:13.30brlcadstarseeker: mged regression is failing with "Tcl_Import ERROR: unknown namespace in import pattern "::itcl::*"
07:14.09brlcadwondering if you're seeing that on your end
07:14.50brlcadonly namespace or itcl change that comes to mind is the mged/bwish setup routine
07:15.47brlcadyeah, namespace import fails because itcl_init is failing, can't find/load the itcl .so file (testing on linux atm)
07:52.39Klebelthanks brlcad
10:18.24*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:38.35*** join/#brlcad Elrohir (~kvirc@p5B149820.dip.t-dialin.net)
11:07.56*** join/#brlcad Elrohir (~kvirc@p5B149820.dip.t-dialin.net)
11:13.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:30.56dlomanMernin all.
11:46.40CIA-77BRL-CAD: 03d_rossberg * r43548 10/brlcad/trunk/include/bin.h:
11:46.40CIA-77BRL-CAD: undef some windows defines which are used in an other context here
11:46.40CIA-77BRL-CAD: (same as in bio.h)
11:49.56CIA-77BRL-CAD: 03d_rossberg * r43549 10/brlcad/trunk/ (3 files in 3 dirs): raytrace.h got a regex.h include -- added the corresponding search path
12:14.00starseekerbrlcad: I'll have to check - I'm doing most of my development work with CMake these days, so I haven't tried the autotools regression in a while
12:14.12starseekerI thought it worked, but maybe it was a fluke...
12:27.29dlomanHuh.  Neato: http://sewelldirect.com/Sewell-Minideck-USB-to-DVI-Display-Adapter.asp
12:45.21CIA-77BRL-CAD: 03starseeker * r43550 10/brlcad/trunk/src/fbserv/fbserv.c: Shadowing a global - fixed
12:47.24CIA-77BRL-CAD: 03starseeker * r43551 10/brlcad/trunk/src/lgt/ (hmenu.c lgt.c): Remove defined-but-unused functions causing lgt failures.
12:49.29starseekerbrlcad: still getting a script.c failure:
12:49.40starseekerscript.c: In function ‘yy_get_next_buffer’:
12:49.40starseekerscript.c:1414: error: comparison between signed and unsigned integer expressions
13:07.12starseekerbrlcad: OK, I see a failure
13:07.22starseekerlooks like a different one though
13:07.38starseekerbrlcad: are you doing an in-dir or out of dir build?
13:09.15CIA-77BRL-CAD: 03starseeker * r43552 10/brlcad/trunk/src/mged/chgview.c: Don't shadow basename
13:11.16starseekergod I wish we could switch to CMake
13:12.26starseekerout of dir autotools build can't find the tclscripts to initialize the gui, from the looks of it
13:13.49starseekerbizarrely enough, if I start up with nu, package require Itcl DOES succeed
13:15.27starseekerconfound it, autopath STILL has /usr/lib at the head of the auto_path search path
13:21.18dlomanso, brlcad (autotools) doesn't like out of src builds atm?
13:22.00starseekeroh, I builds OK but it doesn't seem to run
13:23.27starseekerauto_path is getting all the paths set to the build dir versions of tclscript paths, which doesn't work because they're still in the src dir
13:25.57starseekerwe can either copy the tclscripts over into the build dir (which is a variation on what CMake does currently) or tweak the path logic to point back to the src dir
13:26.32starseekerbut that won't fix the issue of /usr/lib being up front in the search path, which is an excellent way to pull in system installed things and mix the tcl/tk environment up royally
13:30.10CIA-77BRL-CAD: 03starseeker * r43553 10/brlcad/branches/cmake/ (66 files in 21 dirs): MFC r43552
13:33.10starseekernice little subtle issues, particularly when we have to use a local tweaked version of something and there's a vanilla system version getting pulled in instead
13:40.23starseekersaddles up
13:56.42``Erik<PROTECTED>
14:14.45dlomanI love it.
14:15.05dlomanthe IT guys are trying to tell me that its not possible to drive 4 monitors from two video cards.
14:17.24dlomanstares at brlcad's 5 monitor setup and laughs at IT.
14:17.55dlidloman, two video cards for 5 monitor?
14:18.09dlomanbrlcad actually has 3 cards
14:18.39dlomanbut the point remains the same.  the IT guys I'm emailing obviously dunt know what they are talking about.
14:18.41dlidloman, so X-server can handle as many as you can provide?
14:19.07dlomanshould
14:22.00dlidloman, nice to know
14:22.51dlomanstumbled upon a USB to DVI converter (see link above) that allows up to 6 external monitors :)
14:22.57dloman....i really want to try that out.
14:24.07dlidloman, I got a thinkpad with faulty video card, maybe, I can drive up a monitor by USB, but I'm not sure
14:24.40dlomanMight be worth a look.
14:24.51dlomanis the video card integrated or dedicated?
14:25.38CIA-77BRL-CAD: 03erikgreenwald * r43554 10/brlcad/trunk/src/libfb/if_ogl.c: event is a struct, not a pointer
14:29.08dlomanahahaha, just found a MB that has 7 x16 PCIe slots.  Get 7 Eyefinity6's and thats... 42 monitors plus 6 on USB.  48 screens.  Awesome.
14:30.05dlomanHeh, i wonder if that would actually work :)
14:31.28starseekerconsideres the power demand and winces slightly
14:31.57dlomanIf you can afford all those cards and displays, the Powersupply becomes trivial :)
14:32.09``Erikmr fusion
14:32.18dlidloman, it's deciated video, but still integrated on the mobo
14:32.40``Erik1.21 jiggawatts (whatever a jigga is)
14:32.54dlomandli: suckage.  You opened the case to ensure the gfx card isn't removable?
14:33.58dloman``Erik: you're borderline racist, so be careful :)
14:34.11``ErikO.o
14:34.12dlidloman, yes, I opened it several times :) right now, the thinkpad works as a file server, and a wireless router for my VoIP
14:34.20dlomanahaha, nice.
14:35.12dlidloman, the VoIP box supports only wired net, so the thinkpad hooks VoIP to wifi.
14:35.20dlomanwell that usb2dvi thingy costs about 100 bucks, and you might be able to get an entire replacement laptop (depending on how old it is) for that.
14:35.42dlomanhates wifi. too slow.
14:36.36CIA-77BRL-CAD: 03starseeker * r43555 10/brlcad/branches/cmake/src/libfb/if_ogl.c: MFC r43554
14:37.27dlidloman, then, forget it, it's a 4-year-old core2duo level.
14:37.53dlomanheh, i just replaced my old core2
14:38.09dlidloman, wifi is orders faster than VoIP requires
14:38.37dlomanunderstood
14:39.19dlomanand wifi is normally 'good enough' but the wife and I work with large photoshop files and getting them on/off the fileserver via wifi is.... annoying at best.
14:40.28dlidloman, does wifi-N help?
14:40.37dlomansome.
14:40.51dlomanwe're in the process of wiring the house for gig-e
14:41.01dlomanso we can plug in when we need speed.
14:41.34dlidloman, that's wonderful :( when I get the budget to redo my home, I will see how to make giga-e possible at home
14:42.29dlomanwe're doing it slowly.
14:42.31dlidloman, do you work with NURB objects?
14:42.36dlomannegative.
14:42.49dlomanI know next to nothing about nurbs.
14:42.57dlomanits on the long 'tolearn' list.
14:44.32dlidloman, brlcad suggests me to start with NURB intersection problem. I'm too slow here to start :(
14:47.56CIA-77BRL-CAD: 03erikgreenwald * r43556 10/brlcad/trunk/src/irprep/ir-X.c: size_t casting fixes
14:51.46CIA-77BRL-CAD: 03erikgreenwald * r43557 10/brlcad/trunk/src/mged/clone.c: size_t casting
14:52.13CIA-77BRL-CAD: 03erikgreenwald * r43558 10/brlcad/trunk/src/mged/dm-ogl.c: fill out entire struct in table
15:12.03brlcadstarseeker: cool, what platform gave you the defined but unused failures?
15:14.00brlcaddloman: you'd saturate the bus before you could drive that many, but it would be fun to see
15:15.05brlcad4 smaller displays are possible on one dual-dual, or two big'uns
15:15.28brlcaddli: making any progress?
15:15.48starseekerbrlcad: was on gentoo
15:15.56starseekerI'm not sure if it was pulling in system itcl or not
15:16.09starseekerthose friggin auto_path settings make it problematic
15:16.28brlcaddli: atually the suggestion was based purely on your interest and background -- otherwise, I would have suggested something much smaller to start with :)
15:16.38brlcadstarseeker: did it work once installed?
15:16.39starseekerbut the gui issue at least was clear - paths were set to build dir, files were in src dir - boom
15:17.02starseekerdidn't try an install - was working on regress - but I would expect that it did
15:17.25brlcadk
15:17.29brlcadI'll run a test here too
15:17.47brlcadif install works, then I can at least still tag release
15:18.17starseekerI'm trying to wait for the switch to cmake to really mess with the auto_path settings - they should really simplify down now that we're duplicating the install layout everywhere
15:18.42brlcadtrue, but it also needs to be relocatable
15:18.54starseekersure
15:19.05brlcadso an "uninstalled" build tree should also work -- that's the main concern
15:19.06starseekerthe CMake build, in my testing, is already relocatable
15:19.42brlcadhm
15:20.05starseekerI just meant we'd have one set of dir paths that list all the tclscripts subdirs, and then use either build root or install root to id them for auto_path
15:21.13starseekerplus, I've got to figure out how to strip those /usr/lib based paths out of the front of the auto_path list
15:22.18brlcadit's not build or install root, it'd be the runtime root for it to be relocatable
15:22.25starseekerer, right
15:22.40starseekerthe bu_brlcad_data/bu_brlcad_root logic
15:22.43brlcadk
15:23.28brlcadshouldn't need to strip paths off auto_path -- someone is adding it, that's the point of attack
15:23.58starseekerright - I'm just concerned it might be tcl itself initializing auto_path to those values
15:24.04starseekerat this point I don't know
15:24.11brlcadsounds to me like a system pkgIndex.tcl getting loaded
15:24.52starseekeruh... it can't do that until it has paths to load pkgIndex.tcl files from - that's why it needs that C init process
15:25.23brlcadsure, but there are the built-ini *_Init() routines in the libraries that are loaded
15:25.37starseekernods
15:25.39brlcadif it pulls a system .so, then it conceivably can modify the auto_path
15:26.36starseekerit would help if there was a debug setting to let us see where package require was finding its .so files
15:26.46starseeker(for a given package require operation)
15:29.02brlcadthere are ways to introspect tcl from the interpreter
15:29.15brlcad"info loaded", "into library"
15:29.31brlcadman n info
15:30.15starseekerah, excellent
15:30.22brlcad"package names"
15:32.05starseekerI have a hunch my gentoo box has a system itcl/itk that happened to work, and it found that (since it didn't have the auto_path information needed to bridge the divide between build and src dirs, based on the gui behavior)
15:32.39starseekerwould almost be better if we could somehow reject libraries not in the "BRL-CAD expected" location for Tcl packages
15:32.58starseekerwould avoid the accidentally, silently working issue
15:54.58CIA-77BRL-CAD: 03erikgreenwald * r43559 10/brlcad/trunk/src/mged/ (edsol.c mged.h): de-const due to possible deletion
16:00.21CIA-77BRL-CAD: 03erikgreenwald * r43560 10/brlcad/trunk/src/mged/fbserv.c: Move the forward declaration into the #if section that uses it, to avoid the "declared 'static' but never defined" error.
16:08.04CIA-77BRL-CAD: 03erikgreenwald * r43561 10/brlcad/trunk/src/proc-db/vegetation.c: size_t cast fix
16:17.37dloman``Erik: I think i found it.  in GSThread::start(), the pthread was being created in a detached state.  In ~GSThread, pthread_join() was called.  According to the man page, calling _join on a detached thread is a no no.
16:19.09CIA-77BRL-CAD: 03davidloman * r43562 10/geomcore/trunk/src/utility/GSThread.cxx: Commented out the pthread_join() call in GSThread::~GSThread. Man page says that a pthread created in a detached state cannot be used as a sync point via pthread_join()
16:19.24dlomansee if that messes anything up on bsd and/or mac
16:29.39*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:39.39CIA-77BRL-CAD: 03davidloman * r43563 10/geomcore/trunk/src/utility/GSUuid.cxx: Fix a bug where the buffer used to export the uuid was being free'd prior to that buffer being used to generate a std::string.
17:18.06dlibrlcad, yes, I'm still interested on the NURB intersection part. I will have more time now to work on it. Had to go to hospital often in past weeks
17:19.38dlibrlcad, at this stage, I'm still reading through the ON wiki: http://wiki.mcneel.com/developer/opennurbs/home
17:20.11dlibrlcad, still, I will report my success as well as my failure to you when it's time
17:21.18brlcadnaturally, I'd hope we can choose the best development path so we achieve success instead of failur ;)
17:22.02brlcadthat might mean not biting on one of the hardest problems first, there are lots of places where some progress could be made that would help get you familiarized with the source code
17:23.16dlibrlcad, sure, through evolution is good, but the code base overall is huge, it might easier for me to start by writing something new
17:24.04brlcadnew vs old isn't as important as starting with something very small
17:24.25brlcadnurbs intersection is not small ...
17:24.38dlibrlcad, if you can point to some place, I would be glad to see whether I can fix some small things in parallel with my intersection problem
17:24.48brlcadso that was probably over-ambitious without having touched any other code
17:26.33CIA-77BRL-CAD: 03brlcad * r43564 10/brlcad/trunk/doc/README.Linux: include instructions to force 32-bit on platforms that default to 64-bit as well.
17:26.47brlcadhm, something came up just this week that is a nice small task
17:27.23brlcadand it's in a similar section of library code as the brep/nurbs primitive
17:27.28brlcadthe revolve primitive
17:28.57dlibrlcad, sounds good. is there a bug tracking thread for this task?
17:29.06brlcadbasically, it's a very new primitive so it doesn't yet have support for matrix transformations (scaling, translation, rotation)
17:29.46brlcadsupport for matrix transforms is in one function, which revolve doesn't presently implement
17:30.12brlcadhttps://sourceforge.net/projects/brlcad/forums/forum/362510/topic/4372998
17:30.49brlcadthat's merely a day or two project, unlike nurbs which is several weeks :)
17:31.34dlibrlcad, so, rt_generic_xform(), that's specific enough for me. I will report what I can do later
17:31.53brlcadrt_generic_xform() isn't sufficient, which was my last comment
17:32.13brlcadhave to implement rt_revolve_xform() similar to rt_extrude_xform()
17:32.46brlcadsrc/librt/primitives/revolve/revolve.c and src/librt/primitives/extrude/extrude.c respectively, with the function listed in src/librt/primitives/table.c
17:33.00dlibrlcad, I get some rough idea about what's needed here, need to read the code first
17:33.40CIA-77BRL-CAD: 03brlcad * r43565 10/brlcad/trunk/src/other/tkhtml/Makefile.am:
17:33.40CIA-77BRL-CAD: the clean rule was overriding autoconf's default clean rule, which calls
17:33.40CIA-77BRL-CAD: clean-am. this should fix the build where you follow a 32-bit build with a
17:33.40CIA-77BRL-CAD: 64-bit built and vice versa. stale .o build files were getting left in the
17:33.40CIA-77BRL-CAD: .libs dir causing the build to halt.
17:33.53brlcadworking on that will introduce you to how primitives are implemented, some basic structures, the callback interface, and some light math
17:34.03brlcadall useful and relevant for working on nurbs
17:34.21dlibrlcad, let's see. :)
17:38.12brlcadstarseeker: do you have a clean build?
17:38.24brlcad``Erik: when was the last time you tried a windows build?
17:38.33brlcadneeds a windows build test
17:38.45brlcadmac/linux are clean here
17:40.24brlcadand ``Erik, what can you tell me about the libtie integration?  working on the writeup
17:48.54``Eriktried one yesterday, broke a lot using msvc8, will try another
17:49.41``Eriklibtie's functions are in librt, bots that are oriented or have normals should pass to tie if you set the rt_min_tie (emulated rt_min_piece)
17:50.13*** join/#brlcad Stattrav (~Stattrav@117.192.128.118)
17:50.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:50.15``Erikthe rt_min_tie is set to 4 billion and some change right now pending more testing
17:50.15brlcadhow does one set rt_min_tie?
17:50.23``Erikuh, -c I think?
17:50.36brlcadah, so it'll auto-kick over to tie for 4M+ models now
17:51.21``Erik4m+ bot primitives
17:51.28brlcadright, okay
17:51.32``Erik0xffffffff
17:51.39brlcadah, heh
17:52.09brlcadinteresting, so no way to turn it off then or is 0 special? :)
17:52.19``Erikfrom when that was an int, not a size_t
17:54.01brlcadand rough performance impact on a 4M model is what? 10%-500%?  average 50%?
17:55.06``Erikdidn't have a 4m primitive, at ~2000 it was 200% (100% gain), 200 was like 150% (+50%), 12 was 70% (-30%)
17:56.01brlcadso on a real model, should see the time about cut in half
17:56.43``Erikthat was tesselating a sphere, the 'real' models I tried were tesselations of lots of arbs, not NURBS tesselations from an importer
17:57.03``Erikthe benchmark numbers were from tesselated spheres
17:57.37``Erikjabs cia
17:58.17``Erik0 disables tie as of 6 minutes ago
17:59.01brlcadhehe, awesome
17:59.39brlcadso I'll run a quick test on some bot model I have, see what things look like
18:00.07``Erikthere're a couple rough edges that need cleaned up before I'm comfortable impacting customers with it
18:00.13brlcadany other caveats or useful info other than maybe not so hot for tiny models?
18:00.36``Erikon occasion, it misses :D
18:00.47brlcadrt_min_tie is coming up empty, what's the real name? :)
18:01.13``Erikrt_bot_mintie
18:01.23brlcadthx
18:01.24``Erik(to mimic rt_bot_minpieces)
18:05.36CIA-77BRL-CAD: 03brlcad * r43566 10/brlcad/trunk/TODO:
18:05.36CIA-77BRL-CAD: attr command now sorts alphabetically, but then other users reportedly
18:05.36CIA-77BRL-CAD: also/still want sorting based on creation order (because it makes it easy to
18:05.36CIA-77BRL-CAD: diff and/or find new additions. need a sorting option. kicking off an EDITOR
18:05.36CIA-77BRL-CAD: should now be better too now that the invocation has been re-reviewed recently.
18:10.12``Erikscript.c:1414: warning: comparison between signed and unsigned
18:10.19``Eriksrc/remrt/remrt.c:752: warning: comparison between signed and unsigned
18:11.10CIA-77BRL-CAD: 03brlcad * r43567 10/brlcad/trunk/TODO: WE ARE FREE OF COMPILATION WARNINGS! woot.
18:14.51CIA-77BRL-CAD: 03erikgreenwald * r43568 10/brlcad/trunk/src/librt/primitives/bot/bot.c: rt_bot_mintie=0 now means do not use tie
18:16.43brlcadmy 752 is an FD_MOVE line.. doesn't seem right
18:17.11``ErikI know, I've been grepping around, fbsd might have a bad header
18:17.41brlcadmaybe line index from 0 and it's complaining about the tcp_listen_fd int fd
18:19.29``Erikoohhhhh
18:20.42``Erikgot it
18:21.15``Erik(#ifndef FD_MOVE ... we had our own for os's like fbsd which don't provide)
18:21.54brlcadinteresting
18:24.38brlcadlooks like rt_bot_mintie is only exposed via mged tcl var, not -c
18:25.42``Erikhm, I used rt_bot_minpieces as a template, thought the librt tcl.c was called on rt's startup
18:26.04brlcadi added it
18:26.34brlcadit is a tcl var inside the tcl interp that libtcl has running, but that's not exposed to rt
18:26.53brlcadthey are manually wired to the global
18:27.07``Erikah
18:27.56``Erikwin32 just built, had to remove regex.h from raytrace.h (or update the include paths for most projects) and add ws2_32.lib to a handful of converters
18:29.55brlcadyeah, regex.h inside raytrace.h doesn't sound like a good idea
18:30.14brlcadshould be an implementation detail, not public api requirement
18:31.30brlcadpoor CIA-77
18:31.39starseeker``Erik: guess you're right, I'll have to do the void thing
18:32.56CIA-77BRL-CAD: 03erikgreenwald * r43569 10/brlcad/trunk/include/raytrace.h: conditionalize regex.h
18:35.04starseekerbrlcad: I'm still getting failures on Mac with script.c from src/tab
18:35.16starseekerscript.c:33:5: error: "__STDC_VERSION__" is not defined
18:35.26starseekerscript.c: In function ‘yy_get_next_buffer’:
18:35.27starseekerscript.c:1389: warning: comparison between signed and unsigned
18:40.38``Erikthe windows comment in rt/do.c is due to "initializer not static". might need to assign those in cm_set() as a runtime dealie
18:41.05brlcadaha, that makes more sense
18:41.16brlcadthose variables are in librt, so it can't bind them
18:41.22CIA-77BRL-CAD: 03erikgreenwald * r43570 10/brlcad/trunk/include/raytrace.h: remove regex.h for now, windows would need most vcproj files updated.
18:41.24brlcaddll import suckage
18:46.44CIA-77BRL-CAD: 03erikgreenwald * r43571 10/brlcad/trunk/src/remrt/remrt.c: fdset uses unsigned, so fix if we need FD_MOVE defined
18:52.33CIA-77BRL-CAD: 03brlcad * r43572 10/brlcad/trunk/src/rt/do.c: add support for -c rt_bot_mintie
18:53.22CIA-77BRL-CAD: 03erikgreenwald * r43573 10/brlcad/trunk/misc/win32-msvc8/ (5 files in 5 dirs): link ws2_32.lib for ntohl/htonl
19:00.18CIA-77BRL-CAD: 03brlcad * r43574 10/brlcad/trunk/src/nirt/ (command.c nirt.c nirt.h): add support for setting rt_bot_mintie from within nirt, similar to rt_bot_minpieces. add new -T option in addition to new bot_mintie nirt command.
19:08.24CIA-77BRL-CAD: 03brlcad * r43575 10/brlcad/trunk/NEWS: added -T and bot_mintie options to nirt that correspond with controlling when erik's new support for optimized BoT raytacing kicks on
19:12.50CIA-77BRL-CAD: 03brlcad * r43576 10/brlcad/trunk/src/rt/do.c: expand the comment now that the cause is known. need to set during runtime, not compiletime.
19:13.28CIA-77BRL-CAD: 03brlcad * r43577 10/brlcad/trunk/misc/win32-msvc/CMakeLists.txt: back to not needing libregex search dir
19:25.46CIA-77BRL-CAD: 03brlcad * r43578 10/brlcad/trunk/NEWS: (log message trimmed)
19:25.46CIA-77BRL-CAD: reword tie integration from user-visible perspective. erik integrated the
19:25.46CIA-77BRL-CAD: former 'libtie' high-performance triangle intersection engine (tie) into librt
19:25.46CIA-77BRL-CAD: as a way to get optimized BoT raytracing. initial results showing a halfing
19:25.46CIA-77BRL-CAD: reduction of raytrace time for models at 2k+ triangles. erik added an
19:25.47CIA-77BRL-CAD: 'rt_bot_mintie' option (exposed via mged and rt -c) for toggling when the
19:25.48CIA-77BRL-CAD: optimization kicks in. currently set really high at 4M until further testing
19:41.00CIA-77BRL-CAD: 03starseeker * r43579 10/brlcad/branches/cmake/src/ (libged/search.c librt/search.c):
19:41.01CIA-77BRL-CAD: Not in final form yet (for one thing, the regex in db_plan_t will have to become
19:41.01CIA-77BRL-CAD: void and be cast as needed) but this can run searches now. Can't be committed
19:41.01CIA-77BRL-CAD: to trunk until after release in this form, but committing now in cmake to have
19:41.01CIA-77BRL-CAD: it checked in somewhere
19:45.23CIA-77BRL-CAD: 03starseeker * r43580 10/brlcad/branches/cmake/src/libged/search.c: Whoops, need memory here too.
19:52.04dlomanbrlcad: do we have any Display port to DVI or VGA adapters around the office?
19:52.10dloman(if yo uknow off hand)
19:53.17CIA-77BRL-CAD: 03starseeker * r43581 10/brlcad/branches/cmake/ (include/raytrace.h src/librt/search.h): Stick regex in the private search header for now...
20:23.41starseeker``Erik: bob says tcl is wonderful
20:24.22``Erikespecially on windows?
20:25.54starseekerheh
20:51.56CIA-77BRL-CAD: 03starseeker * r43582 10/brlcad/branches/cmake/ (4 files in 3 dirs): This approach keeps the plan data structure out of raytrace.h, and thus isolates regex.
21:43.55CIA-77BRL-CAD: 03starseeker * r43583 10/brlcad/branches/cmake/ (23 files in 16 dirs): MFC r43582
21:48.02*** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net)
21:58.38CIA-77BRL-CAD: 03starseeker * r43584 10/brlcad/trunk/ (7 files in 3 dirs): Put the new search routines into trunk
21:59.05brlcadhope you cross-compile tested that :)
22:00.39starseekerbrlcad: just mac so far - working on it
22:00.55starseekerhad to re-implement the search . ... stuff
22:01.03starseekerI think it behaves the way you wanted it to now
22:01.16*** join/#brlcad Klebel (~mk@169.229.55.243)
22:02.11brlcadI actually just hope it works with it being injected right before the release, and isn't like that nirt "fix" made right before release
22:02.32starseekerbrlcad: sorry, I know it's a rotten time...
22:02.56starseekerI can back it out in trunk and just work in cmake branch
22:03.49CIA-77BRL-CAD: 03starseeker * r43585 10/brlcad/branches/cmake/src/ (4 files in 2 dirs): MFC r43584
22:03.53brlcadcommitting is fine, you should just be extra care and be testing more than usual
22:04.24starseekernods - it's hot off the press, I just now got it running, so I'm starting the testing now
22:05.03starseekerif you've got a working compile, you might check if the new behavior of (say) search . -maxdepth=0 does what you expect
22:05.34starseekerI think we can squash that TODO item, but since you spotted the issue confirmation would be good :-)
22:05.58brlcadI can check it (and you should too given the timing)
22:06.04starseekeroh, I am
22:06.41starseekerI just ment I wanted to make sure I had the behavior you wanted, given how hard you had to work to explain it to me :-P
22:07.44brlcadat release time, it becomes more like how trunk development used to be -- trunk HEAD should be treated like stable: changes tested on multiple platforms before commit, runtime tested on everything
22:07.49brlcadI know
22:08.12brlcadI mean "you too" should be making extra sure that all of search still works, maybe run through the documented examples
22:08.20brlcadnot just the new feature
22:08.21starseekerah
22:08.26starseekergotcha
22:09.50starseekerhow
22:09.59starseekerbot.c isn't happy
22:11.13brlcadah right, warnings
22:11.22brlcadcompile had -w in effect
22:11.53brlcadperfect example :)
22:13.34starseekergot those, moving on...
22:15.53brlcadyou mean you already got those?
22:17.35starseekerthink so - just remove the unused and cast to size_t for comparisons
22:17.53starseeker(don't want to mess with bot->faces... types right now)
22:18.26brlcadhave them fixed here too
22:19.21starseekerah - feel free to stomp mine
22:19.35brlcadyours matched mine
22:19.40starseekercool
22:19.48brlcadbut you apparently weren't getting unused var warnings like I have here
22:20.00starseekerreally?  you got more?
22:20.05brlcadyep
22:20.09starseekerweird
22:20.25brlcadto be expected
22:21.32brlcadone of the lessons from all the cleanup is that even minor version number differences in gcc result in different warnings, along with changes to compilation options, 32-bit vs 64-bit, optimized vs non-optimized
22:22.24brlcadand they're not a combination that is exactly a superset, so there ends up being something like 3! possible configurations
22:22.35brlcad3! or 4!
22:25.04starseekernods
22:30.06_psilva:(
22:30.21starseeker_psilva: ?
22:35.17starseekerbrlcad: my mac compile is still failing in src/tab on script.c
22:37.14starseekersearch completes all the examples from the man page on potential
22:38.23starseekerbrlcad: what version of flex and bison (or lex/yacc) are you working with?
22:55.22starseekeroh, right
22:55.34starseekercan't really test well on the mac because of that messed up install
22:59.44starseekerwith autotools anyway...
22:59.57starseekersearch looks ok with the cmake build on the mac
23:16.15CIA-77BRL-CAD: 03starseeker * r43586 10/brlcad/trunk/src/libged/search.c: Re-add support for the '.' option (e.g. search . -name s*) but this time do it at the ged level with post-processing of the full search. Also doesn't print the leading '/' character for the '.' searches.
23:17.27CIA-77BRL-CAD: 03brlcad * r43587 10/brlcad/trunk/src/conv/patch/patch-g.c: curious that thick_no only shows up as a potential longjmp clobber var when compiling in 32-bit mode
23:17.47CIA-77BRL-CAD: 03brlcad * r43588 10/brlcad/trunk/src/librt/primitives/bot/bot.c: damnits, found a bug during release testing. disable the optimization so release can proceed.
23:17.51CIA-77BRL-CAD: 03brlcad * r43589 10/brlcad/trunk/TODO: resolve the crash post-release
23:22.18CIA-77BRL-CAD: 03starseeker * r43590 10/brlcad/trunk/src/librt/primitives/bot/bot.c: Clear some warnings on bot.c
23:24.29CIA-77BRL-CAD: 03brlcad * r43591 10/brlcad/trunk/src/librt/primitives/bot/bot.c: quell unused var warnings for the non-optimized case. split vars across impls.
23:26.07_psilvagdc crunch sucks
23:26.45_psilvaneed more comp days from this
23:32.00*** join/#brlcad Klebel (~mk@w72.RIC.Berkeley.EDU)
23:53.03brlcadsushi:~ morrison$ flex --version
23:53.03brlcadflex 2.5.35
23:53.03brlcadsushi:~ morrison$ bison --version
23:53.03brlcadbison (GNU Bison) 2.3
IRC log for #brlcad on 20110302

IRC log for #brlcad on 20110302

00:20.51starseekerwill have to test with newer versions on mac to see if it makes a difference
00:23.45CIA-77BRL-CAD: 03starseeker * r43592 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r43591
00:28.44CIA-77BRL-CAD: 03starseeker * r43593 10/brlcad/trunk/src/libged/search.c: gentoo wants search_results initialized
00:33.39brlcadthat's just fantastic..  mged crash
00:34.03starseekerwinces - what's the issue?
00:34.14brlcaddon't know yet, just crashed opening an nmg
00:34.19starseekerah
00:34.30starseekerfwiw - search seems to be working on gentoo
00:55.57brlcadexcellent
01:07.46*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
02:49.35*** join/#brlcad ibot (~ibot@rikers.org)
02:49.35*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
02:51.00starseekernods - I'll have to look at the current tests and see what he got running
02:51.17starseekerhe breaks things out into analytical and numerical categories in the wiki page
02:51.57starseekerI'm assuming numerical would involve either floating point or some form of quantizing
02:55.44starseekerhuh - looks numerical...
03:04.01starseekerwait... gecode has a flatzinc support setup, which does have some sort of Float support...
03:51.28CIA-77BRL-CAD: 03brlcad * r43594 10/brlcad/trunk/NEWS: release write-up on the integration of TIE with LIBRT and the new shp-g shapefile importer.
04:10.03CIA-77BRL-CAD: 03brlcad * r43595 10/brlcad/trunk/BUGS: encountered an infinite loop bug trying to smooth a bot. might be the same traversal bug encountered earlier, but needs testing / investigating.
04:42.01brlcad``Erik_: harrumph.. I can't seem to get a render through to the tie code
04:42.35brlcadcreated a volume bot, smoothed it, rh orientation, mintie set to 1 .. still kicks over to old way
04:42.41brlcadany suggestions?
04:42.51*** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net)
04:42.53yukonboboh hai
04:42.56brlcadhowdy
04:43.31yukonbobmy friend.
04:43.35yukonbobhow're things?
04:44.31brlcadcrazy busy, trying to push a release out and hitting speed bumps left and right
04:44.33brlcadbbl
04:46.03yukonbobworking through a bump w/ .2 current release + tk...
04:49.20``Erik_does it prep for tie? I may've borked some logic...
04:49.50yukonbob``Erik_: that for me?
04:50.14``Erik_no, unless you're trying to do bot/tie raytracing
04:50.16brlcad``Erik_: prep is where I've added some debug and it's not getting there
04:50.48yukonbobstands back from the prep ties.
04:51.05``Erik_hm, bot.c:208 is untested logic... I can look tomorrie
04:51.44CIA-77BRL-CAD: 03brlcad * r43596 10/brlcad/trunk/src/librt/primitives/bot/bot.c: commit the debug code so it's clear what's going on with the tie integration
04:53.07``Erik_should be in really early tomorrow, so I'll be able to crank up the tunes, chill the office and be somewhat productive
05:38.10yukonbobbrlcad: can I squeak in a patch for configure?
05:38.48yukonbobwill see if still has commit bit...
05:54.24CIA-77BRL-CAD: 03bharder * r43597 10/brlcad/trunk/configure.ac: Direct use of interp->result is deprecated; Use Tcl_GetStringResult().
06:05.04yukonbobI'll look for more later... is not an immediate problem, but will be in future.
06:32.15*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
06:47.18brlcad``Erik: nod, i'll be in probably late morning after a package arrives, but will poke at it some more with the debugger
06:47.41brlcadaddressing a couple other bugs at the moment too
06:49.36*** join/#brlcad Stattrav (~Stattrav@122.172.12.71)
06:49.36*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:52.21CIA-77BRL-CAD: 03brlcad * r43598 10/brlcad/trunk/TODO:
06:52.21CIA-77BRL-CAD: bio.h header was de-netted, bin.h added. found a few other show-stoppers,
06:52.21CIA-77BRL-CAD: though. nmg is busted due to a host/net bug. have to test tie optimization for
06:52.21CIA-77BRL-CAD: release notes (as it's the major highlight). search implements '.' so it needs
06:52.21CIA-77BRL-CAD: a quick test. and finally, verify red/ted work since tom is reporting a failure
06:52.22CIA-77BRL-CAD: in .2 with red.
07:15.15brlcadit looks like the tclvar hook into rt_bot_mintie isn't sticking if set from mged
07:16.59brlcadheh, got it to go in and it crashed
07:17.32brlcad(during prep)
07:20.10brlcadaha, possibly completely unrelated!
07:33.36brlcadooor, maybe it is related..
07:36.53yukonbobgetting build failure on ./src/libbu/bitv.c, w/ "array subscript has type 'char'" at lines 251, 255...
07:37.03yukonbobalso hitting hay.... ciao.
07:44.16CIA-77BRL-CAD: 03brlcad * r43599 10/brlcad/trunk/src/librt/primitives/bot/btg.c: not sure if this is right, but it takes care of rt bombing out with a bad matrix during do_ae() due to zero-sized bounding box
07:53.02CIA-77BRL-CAD: 03brlcad * r43600 10/brlcad/trunk/src/rt/do.c: add a sanity check in case code ends up computing an empty bounding box, so we don't bomb out during bn_mat_inv(). make sure the viewsize is at least not zero.
07:53.59brlcadthat takes care of the crash and bomb, but still no picture, reports invalid segments
08:14.35*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:24.35*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
11:28.17CIA-77BRL-CAD: 03starseeker * r43601 10/brlcad/branches/cmake/CMakeLists.txt: New policy in 2.8.4 - we prefer the old behavior for now
11:31.39CIA-77BRL-CAD: 03starseeker * r43602 10/brlcad/branches/cmake/src/other/libutahrle/ (4 files in 2 dirs): Can't lean on the BRL-CAD checks for subdirs now - utah needs M_LIBRARY
11:33.40CIA-77BRL-CAD: 03starseeker * r43603 10/brlcad/branches/cmake/ (9 files in 4 dirs): MFC r43602
11:36.33dlomanMerning all
11:37.04CIA-77BRL-CAD: 03starseeker * r43604 10/brlcad/trunk/src/rt/do.c: Comment needs terminating
11:43.35CIA-77BRL-CAD: 03starseeker * r43605 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: gentoo seems to want cmax initialized - hopefully max is ok...
11:45.59CIA-77BRL-CAD: 03starseeker * r43606 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: initalize points in dsp
11:48.07*** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no)
11:54.28starseekerO.o
11:54.34starseekersrc/librt/primitives/extrude/extrude.c: In function ?classify_sketch_loops?:
11:54.34starseekersrc/librt/primitives/extrude/extrude.c:394: error: ?center2d? may be used uninitialized in this function
11:54.37starseekersrc/librt/primitives/extrude/extrude.c:1509: note: ?center2d? was declared here
11:54.39starseekersrc/librt/primitives/extrude/extrude.c:394: error: ?rb? may be used uninitialized in this function
11:54.42starseekersrc/librt/primitives/extrude/extrude.c:1507: note: ?rb? was declared here
11:54.43dloman``Erik: Hey man, is there still a tiny proxy running somewhere on seans box?
11:54.45starseekersrc/librt/primitives/extrude/extrude.c:394: error: ?ra? may be used uninitialized in this function
11:54.48starseekersrc/librt/primitives/extrude/extrude.c:1507: note: ?ra? was declared here
11:54.49starseekerthat's got me puzzled
11:55.04dlomanthat is pretty wierd?
11:55.11dlomanoops :/
11:56.01starseekerunless I'm missing something, line 394 doesn't have center2d in it
12:02.32dlomanstarseeker: in fn isect_2D_loop_ray(..) on line 1545, isect_line_earc(..) is called and center2d is passed in.
12:03.25dlomanisect_line_earc(..) in turn calls isect_line2(..), again passing in center2d
12:03.39starseekerbut at that point... why is it reporting uninitalized?
12:03.45dlomanand line 394 is in isect_line2_ellipse()
12:04.22starseekerI tried a V2SET on center2d right after it's declared, and it changes nothing
12:05.31dloman....so that means what?  center2d is initialized?
12:06.18starseekerit means I don't know what to do to convince the compiler it is initialized
12:07.57starseekereven better, it's only on the static build
12:08.05starseekerthey dynamic lib succeeds
12:08.44dlomannice.
12:09.01dlomanwell, outside of tracing things visually, im of no use :)
12:09.50starseekerthe only difference I see in the extruce.o compile lines is the presence of  -Dlibrt_EXPORTS in the dynamic line
12:11.01starseekerno, that's not it...
12:11.03starseekerwhat am I missing
12:14.24``Erik<PROTECTED>
12:14.29starseekeroh -fPIC
12:16.41starseekerI don't believe it
12:16.45starseeker-fPIC is the difference
12:16.51starseekerwhy would that matter???
12:17.52starseekergcc version 4.4.5
12:23.14``Erik-fPIC instructs the linker to generate position independent code
12:23.27``Erikrelative jmp's instead of absolute, etc
12:23.50``Erikgcc -E and gcc -S might be handy if you wanna figure it
12:25.28CIA-77BRL-CAD: 03starseeker * r43607 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: More initializations (why doesn't VSETALL get old_pl[3]??)
12:26.45CIA-77BRL-CAD: 03starseeker * r43608 10/brlcad/trunk/src/librt/primitives/nmg/nmg_plot.c: another initialization
12:27.32CIA-77BRL-CAD: 03erikgreenwald * r43609 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: force cmin/cmax using VSETALL. This should be unnecessary, but some compiler/OS combinations aren't smart enough to catch "int a; if(something) a=0; else a=1;" and assume a is unset.
12:28.15CIA-77BRL-CAD: 03starseeker * r43610 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: whoops, plane not point
12:28.28``Erikthe amin vs min in btg.c was important, they're different numbers :/ (actual geometric min vs fpu friendly padding min, iirc)
12:33.41CIA-77BRL-CAD: 03starseeker * r43611 10/brlcad/trunk/src/librt/search.c: initialize new to NULL
12:44.32CIA-77BRL-CAD: 03starseeker * r43612 10/brlcad/branches/cmake/CMakeLists.txt: Hmm - how did this not trigger before? make sure HAVE_STRINGS_H actually makes it into brlcad_config.h
12:54.01CIA-77BRL-CAD: 03starseeker * r43613 10/brlcad/branches/cmake/src/librt/CMakeLists.txt: I can't believe it, but without -fPIC in the static build possibly uninitialized warnings appear with gcc 4.4.5 on gentoo. Only on extrude.c
12:58.02CIA-77BRL-CAD: 03starseeker * r43614 10/brlcad/trunk/src/liboptical/sh_toyota.c: another initialization
13:02.59``Erikhm, musta lost that in merge *sigh*
13:05.18CIA-77BRL-CAD: 03erikgreenwald * r43615 10/brlcad/trunk/ (include/tie.h src/librt/primitives/bot/tie_kdtree.c): remove obsolete kdtree cache stuff
13:09.38CIA-77BRL-CAD: 03starseeker * r43616 10/brlcad/branches/cmake/src/conv/intaval/CMakeLists.txt: Use BRLCAD_ADD_EXEC for tgf-g
13:10.26brlcadI'l make sure you have access to the new server sometime this week
13:11.02brlcadafter release is posted
13:12.04CIA-77BRL-CAD: 03starseeker * r43617 10/brlcad/trunk/src/conv/nastran-g.c: initializations
13:13.43CIA-77BRL-CAD: 03erikgreenwald * r43618 10/brlcad/trunk/ (3 files in 2 dirs): revive the actual min/max (amin/amax)
13:14.12brlcadstarseeker: zombie is back to life:  https://sourceforge.net/tracker/?func=detail&atid=640802&aid=3197208&group_id=105292
13:18.13CIA-77BRL-CAD: 03starseeker * r43619 10/brlcad/branches/cmake/src/conv/iges/CMakeLists.txt: Use BRLCAD_ADDEXEC for iges
13:21.06CIA-77BRL-CAD: 03starseeker * r43620 10/brlcad/trunk/src/conv/iges/ (conv_drawings.c trimsurf.c): initializations for iges
13:21.18starseekerbrlcad: oh god
13:21.22starseekerok, I'll have a look
13:26.51CIA-77BRL-CAD: 03starseeker * r43621 10/brlcad/trunk/src/librtserver/rtserverTest.c: Quell a few warnings - rts_clean doesn't seem to be defined anywhere
13:31.56CIA-77BRL-CAD: 03starseeker * r43622 10/brlcad/trunk/src/anim/anim_hardtrack.c: initializations for anim
13:32.09CIA-77BRL-CAD: 03erikgreenwald * r43623 10/brlcad/trunk/src/librt/primitives/bot/btg.c: woops, point_t, not TIE_3
13:36.36CIA-77BRL-CAD: 03starseeker * r43624 10/brlcad/trunk/src/burst/grid.c: initialization for burst
13:37.56CIA-77BRL-CAD: 03erikgreenwald * r43625 10/brlcad/trunk/include/raytrace.h: set RT_DEFAULT_MINTIE to 0 (disabled)
13:41.46CIA-77BRL-CAD: 03starseeker * r43626 10/brlcad/trunk/src/fbed/fbed.c: initializations for fbed
13:42.25brlcadwishes one of his compilation environments would have picked up those warnings
13:42.54CIA-77BRL-CAD: 03starseeker * r43627 10/brlcad/trunk/src/gtools/remapid.c: initialization for remapid
13:46.12CIA-77BRL-CAD: 03starseeker * r43628 10/brlcad/trunk/src/shapes/picket_fence.c: initialize matrix
13:48.45CIA-77BRL-CAD: 03starseeker * r43629 10/brlcad/trunk/src/util/pixborder.c: initialize for pixborder
13:49.14starseekerfinally.  there we go
13:50.18brlcad~starseeker++
13:50.23brlcadthanks
13:50.53starseekerdingnabbit.  red problem confirmed
13:55.11CIA-77BRL-CAD: 03starseeker * r43630 10/brlcad/branches/cmake/CMakeLists.txt: Don't care about warnings on the time delta utilties
13:57.15starseekerbrlcad: interesting thing about those warnings - they popped up only when I did a release build - optimizations flags, etc
13:57.31starseeker(well, some of them)
13:59.35``Erikum, lots of funky things go on depending on debug.. like 'HIDDEN' is "" on debug and "static" in release, etc
14:03.25starseekeractually, cancel that - red problem is NOT confirmed, with one possible exception
14:03.36starseekeryou can't rename the region during a red command
14:03.43starseekerother than that, I have success using it here
14:05.43starseekerIIRC, I decided not to allow changing the object name during a red - it complicated things a bit
14:07.08brlcadstarseeker: heh, I just saw yesterday's commit -- didn't realize that you just deleted all of those variables :)
14:07.53``Erikscrum ~1300
14:07.59``Eriker, ~1330
14:08.07brlcadif it can't be changed, it should probably not be in the file ... or it should allow it ;)
14:08.27brlcadotherwise people are going to try
14:08.51brlcadshouldn't be too hard to allow, just keep a copy before and after
14:08.59starseekerugh
14:09.00brlcadapply edits to old, and if name changed, rename
14:10.26brlcadinteresting approach to search "." .. I think I like it
14:18.54starseekerbrlcad: adding renaming support will take a little time - is that something you want prior to release?
14:22.37starseekerbrlcad: if you decide search looks good we can nuke the TODO item for that particular tweak and update NEWS - I was waiting until I was sure it was "done"
14:25.07starseekersaddles up
14:40.55brlcadstarseeker: if it works, then that's stable for release -- but would you follow up with tom to see if that's what he was running into?
14:41.45brlcadthe search todo is my action to look at since I had that particular request
15:37.06*** join/#brlcad PrezKennedy (MK@whitecalf.net)
15:38.17CIA-77BRL-CAD: 03tbrowder2 * r43631 10/brlcad/trunk/src/tab/script.l: eliminate unused function warning
15:55.28*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:33.41starseekerbrlcad: I thought I emailed him for more details, but I see it didn't pop up...
16:34.29starseekerhuh - sent over 2 hours ago
16:43.04CIA-77BRL-CAD: 03starseeker * r43632 10/brlcad/branches/cmake/ (21 files in 17 dirs): MFC -r43631
16:46.58CIA-77BRL-CAD: 03starseeker * r43633 10/brlcad/branches/cmake/CMakeLists.txt: Lovely - check cmake version before we set CMP0017
16:55.18starseekerheh:  http://spacewar.oversigma.com/
16:55.47starseekeralso http://spacewar.oversigma.com/html5/
16:56.30starseeker``Erik: whadya think, original BRL-CAD on a PDP1 emulator in html5? :-P
17:00.45``ErikI don't think it ever ran on a pdp1... mebbe an 11/70, though it might need a vax11/780 by the time it did anything interesting
17:01.09``Erikum, jove appeared in the repo in '83, then mid 85 is when really basic raytracing started happening
17:02.00``Erikthe date flag to svn up makes for some amusing code spelunking if ya find yourself with a bit of free time :D
17:03.48starseekerheh
17:08.12CIA-77BRL-CAD: 03brlcad * r43634 10/brlcad/trunk/src/librt/primitives/nmg/nmg_plot.c: use VINIT_ZERO macro symbol instead of {0.0, 0.0, 0.0} for point_t/vect_t. less error-prone, less typing, and supports converion to fixed point arithmetic down the road.
17:08.39starseekerbrlcad: oops, sorry - there'll be a few of those
17:09.13CIA-77BRL-CAD: 03brlcad * r43635 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: same with HINIT_ZERO for 4D vector initialization.
17:43.32CIA-77BRL-CAD: 03erikgreenwald * r43636 10/brlcad/trunk/src/librt/primitives/bot/btg.c: rewrite prep to be correct and only make one tie_push call
18:26.59CIA-77BRL-CAD: 03erikgreenwald * r43637 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: reincorporate some of the lost changes
21:23.41CIA-77BRL-CAD: 03starseeker * r43638 10/brlcad/branches/cmake/src/mged/points/CMakeLists.txt: Ugh. Go vanilla with the cflags in points dir until it's clear what the issue is
21:57.55starseekerhmm http://www.research.ibm.com/haifa/projects/verification/fpgen/papers/plsrange.pdf
22:02.19starseekerhttp://portal.acm.org/citation.cfm?id=1048200
22:03.19starseekermaybe we can recruit this guy :-) http://johnsogg.blogspot.com/2011_01_01_archive.html
22:16.12starseekerhttp://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.112.3073
22:18.41starseekerhttp://code.google.com/p/sketchsolve/
22:28.59starseekerhah, cool - not related directly to geometric constrants but possibly useful for other things:  http://adaptagrams.sourceforge.net/
22:38.04starseekerreflects that the constraint system is going to require some paper diving...
22:42.20starseekerhmm http://www.cs.purdue.edu/homes/cmh/electrobook/intro.html
23:16.50CIA-77BRL-CAD: 03starseeker * r43639 10/brlcad/branches/cmake/src/conv/step/CMakeLists.txt: Use BRLCAD_ADDEXEC for step-g
23:17.47CIA-77BRL-CAD: 03starseeker * r43640 10/brlcad/branches/cmake/src/libpc/CMakeLists.txt: Yes boost, we know, be quiet already
23:21.03CIA-77BRL-CAD: 03starseeker * r43641 10/brlcad/branches/cmake/ (5 files in 3 dirs):
23:21.03CIA-77BRL-CAD: Rework handling of compile flags - no longer setting strict flags at the
23:21.03CIA-77BRL-CAD: individual target levels, since BRL-CAD is going fully strict. There are a few
23:21.03CIA-77BRL-CAD: local overrides for issues not yet resolved, but the default will now be that
23:21.03CIA-77BRL-CAD: anything new automatically gets the struct flags with all warnings unless
23:21.03CIA-77BRL-CAD: options are turned off.
23:25.29CIA-77BRL-CAD: 03starseeker * r43642 10/brlcad/branches/cmake/misc/CMake/test_srcs/time.c.in: Add the zero for day, not just month.
23:59.25*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
IRC log for #brlcad on 20110303

IRC log for #brlcad on 20110303

00:16.22CIA-77BRL-CAD: 03starseeker * r43643 10/brlcad/trunk/src/libged/combmem.c: Do some initializations for combmem.c, but it's not enough - getting some more of the weird complaints that identify line numbers that don't seem directly related to uninitialized aetvec and tvec
00:21.50CIA-77BRL-CAD: 03starseeker * r43644 10/brlcad/trunk/src/libged/combmem.c: This does it - init 'em all
00:32.38CIA-77BRL-CAD: 03starseeker * r43645 10/brlcad/branches/cmake/src/ (5 files in 3 dirs): MFC r43644
01:28.27CIA-77BRL-CAD: 03starseeker * r43646 10/brlcad/trunk/ (include/raytrace.h src/libged/search.c src/librt/search.c): Move the unique object logic out of libged into a librt function. renaming and cleanup for clarity, more comments in raytrace.h header.
01:31.22CIA-77BRL-CAD: 03starseeker * r43647 10/brlcad/branches/cmake/ (include/raytrace.h src/libged/search.c src/librt/search.c): MFC r43646
01:38.17CIA-77BRL-CAD: 03starseeker * r43648 10/geomcore/trunk/tests/svntest/main.c: Start laying out the search plan for svn geometry testing.
02:05.27CIA-77BRL-CAD: 03starseeker * r43649 10/brlcad/trunk/src/ (libged/search.c librt/search.c): Shift responsibility for making the default toplevel list of objects to librt from libged - this is sensible default behavior and will save doing this every time search logic is used to search the whole database.
02:06.54CIA-77BRL-CAD: 03starseeker * r43650 10/brlcad/branches/cmake/src/ (libged/search.c librt/search.c): MFC r43649
02:08.06CIA-77BRL-CAD: 03starseeker * r43651 10/geomcore/trunk/tests/svntest/main.c: tweak plan - search should iterate over everything by default now.
02:34.59*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
06:26.48*** join/#brlcad Stattrav (~Stattrav@122.172.12.71)
06:26.49*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:57.01*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
09:49.48*** join/#brlcad ibot (~ibot@rikers.org)
09:49.49*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
10:20.45CIA-77BRL-CAD: 03d_rossberg * r43652 10/brlcad/trunk/ (4 files in 4 dirs):
10:20.45CIA-77BRL-CAD: fixed release 43577 changes "back to not needing libregex search dir"
10:20.45CIA-77BRL-CAD: - re-enabled the libregex build
10:20.45CIA-77BRL-CAD: - removed the unnecessary libregex search dirs
11:51.31CIA-77BRL-CAD: 03starseeker * r43653 10/brlcad/branches/cmake/CMakeLists.txt: VERSION_GREATER, not GREATER
11:58.45CIA-77BRL-CAD: 03starseeker * r43654 10/brlcad/branches/cmake/misc/CMake/test_srcs/builddelta_end.c.in: do something with fscanf return to quiet compiler.
12:11.33*** join/#brlcad ibot (~ibot@rikers.org)
12:11.33*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
12:11.43CIA-77BRL-CAD: 03starseeker * r43656 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: whoops, that should have been in trunk - init min and max
12:14.37CIA-77BRL-CAD: 03starseeker * r43657 10/brlcad/trunk/include/raytrace.h: comment tweak
12:40.55CIA-77BRL-CAD: 03starseeker * r43658 10/brlcad/branches/cmake/ (. include/raytrace.h): fix comment in cmake too
12:59.55CIA-77BRL-CAD: 03starseeker * r43659 10/brlcad/trunk/ (include/raytrace.h src/libged/search.c src/librt/search.c): Ah, that's better - don't wipe out the path name list passed to the search functions - that's the responsibility of the function that created the list. provide db_free_full_path_list to make that easier.
13:00.40CIA-77BRL-CAD: 03starseeker * r43660 10/brlcad/branches/cmake/ (include/raytrace.h src/libged/search.c src/librt/search.c): MFC r43659
14:09.45brlcadMISSING from src/librt/CMakeLists.txt: search.c
14:09.45brlcadNEED TO SYNC CMAKELISTS.TXT
14:10.09starseekeronce sec...
14:10.16starseekerupdates local autotools branch
14:11.49CIA-77BRL-CAD: 03starseeker * r43661 10/brlcad/trunk/src/librt/CMakeLists.txt: Sync autotools branch CMakeLists.txt file
14:11.54starseekerthere we go
14:19.50``Erikponders removing strict from tab since script.c complains on both osX.6 and fbsd :/
14:24.14brlcadholy shit that's a lot of "lost changes" erik .. heh
14:24.38brlcadsome of it is ws, but a lot not
14:26.45``Erikyeah, it was a merge from trunk that stomped stuff, unfortunately :/
14:28.07brlcadcool, retesting
14:28.16starseekerneeds to try compiling d_rossberg's CMake stuff to figure out what it is/does, and see if it can be made to do that with cmake branch files - if it can, the new CMake logic can be moved to trunk (even if it doesn't get enabled as the default system)
14:28.30brlcadstarseeker: r43630 .. heh, there are warnings that were that bad in time testing code that YOU wrote??
14:30.00brlcadsame reason they're maintenance burden for production code holds true for build system code too
14:31.40brlcadr43607 also isn't right, it's a hvect, not a vect, so VSETALL doesn't apply ([3] is the fourth H element)
14:33.44starseekerbrlcad: keep reading :-)
14:35.17starseeker43610 should fix 43607
14:36.45starseekerand I fixed the compile warnings on those timing utilities - I took out all the warning flag suppression for them in one of the later commits
14:38.07CIA-77BRL-CAD: 03brlcad * r43662 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: pl is a plane_t, fix a couple places where it's being treated like it's a vect_t.
14:43.33brlcadI see, there were still other problems in that file
14:43.50brlcadone that wasn't immediately evident what [H] should be set to
14:44.03starseekernods
14:44.07starseekerthat is odd
14:44.48starseekerdoes some of that nmg code predate the establishment of the plane_t and vect_t types?
14:45.13brlcadnot really
14:45.26starseekersees if 7.18.2 builds...
14:45.42starseekeror r43153 anyhow
14:45.49brlcadthe problem is probably more code evolution, someone coming in years later and thinking that a particular fastf_t * was one type vs another
14:46.57brlcadfor a long while, some compilers did not like having vect_t or plane_t listed as parameters, wanted the untypedef'd type (fastf_t*)
14:47.08brlcadeven today, I think some compilers still have a problem with it
14:47.11brlcad(gcc)
14:47.24starseekerhuh
14:47.46brlcadideally should change those pl parameters to be plane_t, and see who breaks
14:48.04starseekerprobably after release? ;-)
14:48.31brlcad43613 (-fPIC) is concerning up there with r43630 (-w on build infrastructure)
14:49.03brlcadprobably, more like the next time someone is in that file making logic changes where it can be more carefully tested
14:49.46starseekerbrlcad: 43613 is beyond my debug skills, at least without putting a lot of time into it
14:50.07brlcadfPIC isn't going to be valid for some compilers
14:50.20brlcadand doesn't make sense for static code regardless
14:50.56brlcadpaste the (actual) compilation line and build failure
14:51.09starseekerI'll yank it - I primarily needed to get by it to do other stuff at the time
14:51.28starseekerbuild failure was posted earlier...
14:51.43starseekerI don't have the compilation line handy - it was only on my home gentoo box I saw the issue
14:52.28brlcadkind of one-liner tweak that gets ignored and is fine for a while, then bites someone years down the road taking days to debug and discover
14:53.00brlcadhaving some issue that's PIC/non-PIC related can be disastrous debugging for dynamic loading
14:53.15CIA-77BRL-CAD: 03starseeker * r43663 10/brlcad/branches/cmake/src/librt/CMakeLists.txt: remove the fPIC flag for extrude.c
14:55.55starseekerbrlcad: http://pastebin.mozilla.org/1122628
14:55.57starseekerthat's the error
14:56.34brlcadcan you paste the whole log, from compile line to the end of the error?
14:56.47starseekernot right now - I can tonight
14:57.01brlcadk
14:57.14brlcadahh, looks like it's out of date to, line numbers aren't matching up
14:57.51starseekeruh - that was one of the fun parts of the error - line numbers reported didn't seem to have anything to do with the variables that might be unitialized
14:59.51brlcadI mean the easy fix is to initialize all those vars it mentions
14:59.58starseekerah
14:59.59brlcadif that's indeed the issue
15:00.20brlcadthat might at least hone the warning to something else, leading towards the root cause
15:00.56starseekerlet me see if a release build here can reproduce it... doubtful but you never know
15:05.26CIA-77BRL-CAD: 03brlcad * r43664 10/brlcad/trunk/include/vmath.h: add missing V2INITALL and V2INIT_ZERO macros providing the 2D versions of VINITALL and VINIT_ZERO
15:06.15CIA-77BRL-CAD: 03brlcad * r43665 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: initialize a few 2d vars to zero, just because we like it that way
15:08.26starseekeryeah, thought so - doesn't show up here
15:08.40CIA-77BRL-CAD: 03erikgreenwald * r43666 10/brlcad/trunk/src/librt/primitives/bot/tie.c: reincorporate lost changes
15:10.20CIA-77BRL-CAD: 03brlcad * r43667 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: slew of functions not marked static that should be static. make the compiler's job easier, those functions don't need to be exported.
15:10.38brlcadthat will probably fix the failure between those changes
15:10.48starseekerbrlcad: cool, thanks!
15:19.32brlcadyeah, reading through the code, it's looking like there might be some obscure way that they'd get called without initialization or the compiler was getting confused by sub-scope variables getting passed in as arguments to other functions that had parameters with the same name
15:19.51brlcador it was cleverly following the call tree use and found some path of potential uninitialization
15:20.30brlcadeither way, the "why" doesn't matter so much in this instance since we can simply initialize like it's saying we should without harm
15:20.50starseekernods
15:22.05CIA-77BRL-CAD: 03brlcad * r43668 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: init ra/rb to zero too, pull them back up to the top scope since they're double-declared in the same function.
15:23.26CIA-77BRL-CAD: 03erikgreenwald * r43669 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: get_indices can't be static, it's also used in sketch
15:23.48cjdevlinany chance of a losethos <http://www.losethos.com/> port?
15:26.24starseekercjdevlin: I'm guessing probably not
15:26.37starseekernever heard of it before - how did you come across it?
15:27.25cjdevlini think i got a new release announcement on a mailing list i am on. it's . . . interesting
15:27.48starseekerit's intended for recreational programming, not "production" use
15:28.31starseekerhttp://www.losethos.com/doc/Constitution.html would seem to pretty much rule it out as a worthwhile platform to port to
15:28.33cjdevlinhe created a custom version of c . . . i don't think anything will be ported to this ever . . .
15:30.23starseekerHaiku is a lot more interesting, but someone(tm) would have to get Tk ported to their graphics system
15:31.56starseekerbrlcad got (iirc) all the non-graphical components of BRL-CAD compiled on Haiku at one point, including tcl, but Tk is a whole 'nother animal
15:32.05cjdevlinhaiku is the new beos right?
15:34.12starseekerpretty much
15:40.57cjdevlinwho maintains the .debs on the brlcad site?
15:40.59starseekerwinces thinking about a Haiku compile with the new flags...
15:41.23starseekerwe've had some new work done on those recently...
15:42.12starseekerdon't recall if we actually got new debs uploaded to sf - the only Debian based system I have is my laptop, and even there I compile...
15:42.27*** join/#brlcad Stattrav (~Stattrav@117.202.27.184)
15:42.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:43.06cjdevlinwell, here's the motivation for me asking . . . i am trying to learn how to program. with some assistance from the people in this room i was able to get source compiled a few times. i figured working on just the packaging will be a way to get my feet wet. i am an ubuntu user, but ubuntu is basically debian.
15:43.18cjdevlinhttp://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289632
15:43.33cjdevlinand it seems like people have been trying to get it into debian for quite a while
15:43.51starseekertake a look in misc/debian
15:45.14cjdevlini also don't want to step on toes or reinvent the wheel if someone is actively working on it
15:45.15starseekerah, right - Jordi Sayol
15:45.30starseekerback in January
15:45.54starseekermost recent commit was actually 2/28, so fair to say he's active :-)
15:46.22cjdevlindoes he spend much time here?
15:46.27brlcadcjdevlin: chances are greatly increased if you attempt the port ;)
15:48.16cjdevlinbrlcad: well then, based on my current working knowledge of programming and the graphics libraries available on the target platform: expect commits around 2020 (ish) :)
15:49.05cjdevlinbrlcad the program is only what? a million lines of code?
15:49.25CIA-77BRL-CAD: 03d_rossberg * r43670 10/brlcad/trunk/misc/win32-msvc/Dll/BrlcadCore.def: export rt_bot_mintie() for nirt
15:49.53starseekerbrlcad: I tried compiling 43153 on Redhat and can't reproduce it
15:51.21brlcadcjdevlin: approximately, yep
15:51.38brlcadtwice that if you count all our dependenceis
15:52.07brlcadthis losethos guy is pretty awesome
15:52.09brlcadhilarious
15:52.34starseekerah HAH!
15:52.39starseekersystem regex doesn't work
15:53.09cjdevlinbrlcad: isn't 2million the lines of code that run (ran) Jurassic Park :) ?
15:53.46cjdevlinhe's been working on it full time for more than 7 years . . .
16:00.14starseekerblinks
16:00.20starseekersystem regex works with trunk??
16:03.06brlcaddefine "works"?
16:03.20brlcadshould work..
16:04.10starseekeryes, but that looks like the change - 7.18.2 failed with system, trunk succeeds
16:05.21brlcadso the good news is 7.18.2 binaries might not be working if they're enable all, but an enable all build should work for .2 and trunk
16:05.38brlcader, if they're NOT enable all
16:06.11starseekerright
16:06.13brlcadthat begs the question why system regex would fail -- perhaps a non-portable regex expression being used
16:06.25brlcadred/ted use regex?
16:06.32starseekerI am using some features only supported by newer regex installs
16:06.34starseekeryes
16:06.40starseekerred does anyway
16:07.05brlcadthat should be easy to fix then
16:07.27starseekeruh, define fix...
16:07.41brlcadfinds the expressions
16:08.01starseekerthe part that's throwing me is it succeeds in trunk
16:08.05brlcadthere's no "new" regex feature that isn't supported by older regex in another form
16:08.18brlcadyeah, that's interesting
16:08.31brlcadif trunk succeeds with system regex, then maybe a red herring
16:08.42starseekerwait, let me try trunk autotools
16:08.43brlcadcoincidental, but not the problem
16:08.49starseekerright
16:08.59_psilvaugh.. cant login to 'new' account.. i left large corporations to avoid this crap :(
16:09.15brlcadand then got bought out by one
16:09.26_psilvacries
16:09.45brlcadpresident was a pussy?  sold out?
16:10.02_psilvahe wanted his millions?
16:10.03_psilvaheh
16:10.25_psilvaflash needs to be replaced ;)
16:11.05brlcadjoin the html5 committee?
16:11.15_psilvawe'll see
16:11.58_psilvabunch of flash 'experts' are moving to html5
16:12.13_psilvaand are implementing similar constructs via js/canvas
16:12.19brlcadthis Terry Davis losethos guy is pretty funny, wonder how he had so much time to dedicate to something like that
16:13.02brlcadclassic hacking, for just the hell of it all on his own from scratch
16:13.42brlcadrandom custom constructs, caveats, and inconsisties all over the place, but fun nontheless
16:14.12_psilvawhat's this?
16:14.15cjdevlinit has a cool flight sim though
16:14.32brlcad_psilva:  dude that wrote his own OS http://www.losethos.com/
16:14.47brlcadnot general purpose, just for fun
16:14.49_psilvaah
16:15.07brlcadthe "command line" is actually a C-variant live interpreter
16:15.26_psilvawe had quite a time dealing with the creator of atheos, who's working at funcom atm
16:16.44_psilvawow that's a lot of effort
16:17.15cjdevlinit seems like you guys are maintaining both autotools and cmake? mind if i ask why? (purely a personal info question, not trying to start an argument)
16:17.18brlcadall three videos are pretty intersting
16:17.36brlcadcjdevlin: we're migrating to cmake, but autotools is the oldstay until we switch
16:17.53brlcadyears went into autotools, so it's pretty lock solid, but cmake is the new coke
16:18.23cjdevlinhelps the cross platform effort also?
16:18.30brlcadthat's the main motivation
16:18.51_psilvadid u ever make a new gui for brlcad?
16:19.00brlcadgetting a unified build that'll span linux, mac, other unices, AND windows .. which has been the lone child out
16:19.14brlcad_psilva: two of them, but both still under development
16:19.21_psilvascreens?
16:19.35brlcadarcher is about to go into alpha
16:19.36brlcadhttp://brlcad.org/tmp/archer.png
16:20.11starseekerif I got that right, r43400 seems to work with system regex
16:20.19_psilvainteresting.. tcl?
16:20.29brlcadhttp://brlcad.org/~starseeker/archer_latest.png
16:20.37brlcadhttp://brlcad.org/~starseeker/archer_ronja1.png
16:21.40brlcad_psilva: yeah, archer is .. the "3rd gen" one isn't, but the screenshots are more simple -- pre-pre alpha
16:22.49_psilvaarcher looks nice
16:22.56_psilvabetter than what i remember
16:23.07_psilvaany info on the 3rd gen ui?
16:23.12brlcad_psilva: most of the time has been spent implementing support for NURBS and STEP, library and source code refactoring, and the Geometry Service
16:23.55brlcadmost of the GUI things you'd want require robust NURBS support, CSG evaluation of NURBS, and reliable fast surface tessellation
16:24.19brlcadso the focus has been on NURBS more than the GUI itself, so we can still have verifiable CAD constructs
16:24.29_psilvaic
16:24.55brlcadsome screenies of 3rd gen at http://brlcad.org/wiki/User:Ralith
16:25.50brlcadthe screenie at the bottom actually has an embedded mged command interpreter, input bindings mimicing mged, blender, and a game controller
16:26.04_psilvacool
16:26.10brlcadotherwise, mostly basic infrastructure
16:29.13cjdevlinwas the unix/linux version done in gtk? and now you are writing a new gui in Qt?
16:29.31starseekeroriginal gui work was in Tk
16:29.44starseekernew effort uses a combination of Qt and Ogre
16:38.53starseeker43200 exhibits the failure...
16:55.11starseeker43310 works...
16:56.42*** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ)
16:56.50*** join/#brlcad yukonbob1 (~bch@20-144.wireless.kamloops.net)
17:01.04*** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201)
17:05.44*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
17:23.49starseekerok, 43213 exhibits the failure
17:35.46starseekerhah, cool:  http://prod.nais.nasa.gov/eps/eps_data/137203-SOL-001-005.pdf
17:39.24*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
17:40.49*** join/#brlcad kanzure_ (~kanzure@131.252.130.248)
17:41.08starseekereven cooler:  http://simplesat.gsfc.nasa.gov/drawings.html
17:47.24starseekerwonder if there are public cad drawings for that simplesat...
17:51.36alex_jonistarseeker: nice :)
17:55.31starseekernot a drawing itself, but possibly interesting as a source of layout conventions:  http://mscweb.gsfc.nasa.gov/543web/files/GSFC-X-673-64-1F.pdf
17:57.04starseeker43214 fails...
18:02.04alex_joniheh, if I would have followed that doc I probably would have never finished with my design :)
18:06.27starseekerhmm... http://hesperia.gsfc.nasa.gov/hessi/reference/drawings/hessi10_26_99%20Archive/
18:06.37alex_jonistarseeker: http://juve.ro/blog-files/projects/01298803577/steadycam.pdf
18:07.11*** join/#brlcad epileg (~epileg@188.119.210.222)
18:07.11*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
18:16.53starseekeralex_joni: hah, cool!
18:16.53starseekerwhat license is the model?
18:16.56starseekerlooks like it might be a solid model?  http://juve.ro/blog/projects/01298803577
18:16.57starseeker43216 fails...
18:26.47*** join/#brlcad tofu_ (~sean@BZ.BZFLAG.BZ)
18:29.25*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
18:32.08*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
18:39.39starseeker43235 fails
18:39.48starseekergets lunch
18:58.22*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
19:00.51*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
19:13.27alex_jonistarseeker: haven't decided on the license yet, but something open
19:19.04alex_joninot even sure what licenses are aplicable to solid models and cad drawings
19:28.50starseekerusually I see creative commons
19:29.01starseeker(see openmoko for an example)
19:44.38*** join/#brlcad PrezKennedy (MK@whitecalf.net)
20:31.34CIA-77BRL-CAD: 03starseeker * r43671 10/brlcad/trunk/TODO: The reported red failure was due to disabling compile of local regex, resulting in interference from tcl regex. After commit 43259, this is no longer occurring and proper behavior is restored.
20:51.29CIA-77BRL-CAD: 03starseeker * r43672 10/brlcad/branches/cmake/ (5 files in 5 dirs): MFC r43671
20:59.40CIA-77BRL-CAD: 03erikgreenwald * r43673 10/brlcad/trunk/src/librt/primitives/bot/tie.c: indent
21:11.19CIA-77BRL-CAD: 03erikgreenwald * r43674 10/brlcad/trunk/src/librt/primitives/bot/ (tie_kdtree.c tieprivate.h): de-magic the haschildren/leafnode bit and comment some on bitpacking
21:11.59alex_jonistarseeker: sounds good
21:25.34CIA-77BRL-CAD: 03starseeker * r43675 10/geomcore/trunk/src/other/subversion/other/apr-util/xml/expat/Makefile.in: Looks like a Makefile.in got ignored.
21:35.52CIA-77BRL-CAD: 03erikgreenwald * r43676 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: check alignment on kd nodes
21:40.40*** join/#brlcad vtts (~vytautas@diz.ktu.lt)
21:44.51vttshi, is such problem known on mac os x? http://pastie.org/1630246
21:45.47CIA-77BRL-CAD: 03starseeker * r43677 10/geomcore/trunk/src/other/subversion/other/apr-util/ (87 files in 15 dirs): Sync apr-util directory with apr-util-1.3.10
21:56.11CIA-77BRL-CAD: 03starseeker * r43678 10/geomcore/trunk/src/other/subversion/ (CMake/ThirdParty.cmake CMakeLists.txt): third party build logic ain't happy - get closer, but this won't be enough
22:31.03starseekervtts: yow.  Is that with OpenGL enabled?
22:33.26vttsagl
22:36.15starseekeruh... we don't use agl yet - we work with X11 opengl on the mac
22:36.47vttsok then, I'll try skipping OpenGL and see if it works
22:36.59alex_jonistarseeker: now with license info: http://juve.ro/blog/projects/01298803577
22:37.11starseekernot sure if that'll do anything, but worth a try... that's a pretty new version of OSX
22:37.54starseekeralex_joni: cool! what cad system are you modeling in?
22:38.01alex_joniI'll put the solid up in a couple days (when I get a round-tuit)
22:38.04alex_jonistarseeker: alibre
22:38.17starseekerdoes it export to step?  (drool...)
22:38.21alex_joniyes
22:38.34starseekerawesome
22:39.02alex_joniI found it very nice/cheap (about 2k for the expert version which does CAE, CAM, unlimited everythings, etc)
22:39.22alex_jonilimited CAM though..
22:39.27starseekernods
22:39.38starseekerhey, if it works it works
22:39.40alex_joniright
22:39.48alex_joni"only" 2.5D and 3D
22:40.09alex_jonianyways, I used SW a bit before this, and Inventor
22:40.20alex_jonibut I like alibre better, and it's less than half the price
22:40.31starseekerwonder what engine they're using
22:40.39alex_jonioh, did I mention you get 5 seats for that price?
22:41.09starseekerheh - amazing.  A far cry from the $30,000 per set licensing (back when that was real money)
22:41.23alex_joniheh
22:41.50alex_jonithey use step as the internal datatype
22:41.57alex_jonisome step variant anyways
22:42.03starseekersweet
22:44.34alex_jonithey used to have a limited free version
22:44.45alex_joninow it's 99$/seat for the personal version
22:45.02starseekernods - lot like Mathematica in that respect
22:45.11starseekersuck in the students, then *wham*
22:46.02starseekeralways preferred the open solutions, even if they weren't as full-featured/glitzy, but sometimes you need the functionality (especially for "real work")
22:46.46alex_joniyeah, I know..
22:47.02alex_joniwell.. there's Octave out there ;)
22:47.34starseeker:-).  That's the Matlab-alike - for phyics (my undergrad) Maxima was the major player
22:47.50starseekerAxiom later made an appearance, and then Reduce as well
22:48.05alex_joniah right, was thinking of Matlab
22:50.41brlcadvtts: opengl is fine, but you have to enable compilation of tcl/tk (--enable-all)
22:50.59alex_jonistarseeker: step 203 / step 214 ?
22:51.00brlcadthe system tk on 10.6 is compatible, but will crash because we assume an X11 binding
22:51.14brlcad203 at the moment
22:51.20starseekeralex_joni: I believe 203, but if it's easy why not put up both?
22:52.14starseekeris a greedy sucker when it comes to test cases :-P
22:53.08alex_jonicoming up in a sec
22:54.13alex_joniI can also export ACIS and parasolid (x_t)
22:54.23alex_joniif those are valid test cases let me know
22:54.42starseekerurm.  Interesting, but I don't know if those formats are documented?
22:55.08brlcadsure, why not -- x_t would be useful
22:55.22brlcadit's a text-based format, somewhat easy to parse
22:55.37starseekerthey'd all be handy for "Rosetta stone" work if someone wanted to start figuring out the formats, but for now we've got all we can do to support the ones that are :-P
22:55.46starseekerhaving the same model in multiple formats is quite handy
22:57.33starseeker's jaw hits the floor...
22:59.10vttsbrlcad, make install fails if i enable tcl/tk :(
22:59.12CIA-77BRL-CAD: 03starseeker * r43679 10/geomcore/trunk/tests/svntest/main.c: Commit svntest quick before it changes it's mind - got what appears to be a working assembly search. Not doing much intelligent with it yet, but that went surprisingly smooth.
22:59.43alex_joniok, models uploaded
23:00.57starseekeralex_joni: awesome, thanks!
23:02.12brlcadvtts: what's the failure?
23:03.09alex_jonistarseeker: let me know if you can open them
23:08.26starseekeroooh, wow - step-g doesn't like the 203 file
23:09.23starseekerexcellent - good  test case
23:09.41alex_joniheh
23:10.52starseekeractually is quite a good test - lots of objects, but not huge
23:10.55alex_joniwell, good night all
23:11.04starseekernight, and thanks again!
23:11.06alex_jonihas to get up early
23:11.11starseekeryuck
23:11.25alex_joninot _that_ early.. around 7am (early for me)
23:11.45starseekerheh - for me that's the dead zone - either 5am or 9am work
23:12.03alex_joniI'm more the 9am guy :)
23:12.05vttsbrlcad, I didn't save it :(, will pastebin it tomorrow
23:12.11alex_jonibut it's after 1am here.. so :/
23:12.19starseekeralex_joni: cool, night!
23:14.41starseekermust head out too...
IRC log for #brlcad on 20110304

IRC log for #brlcad on 20110304

01:36.29*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
03:00.15starseekerbrlcad: http://pastebin.mozilla.org/1124576
04:44.32brlcadstarseeker: thanks
04:44.37brlcadtry with that fix
04:44.44CIA-77BRL-CAD: 03brlcad * r43680 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c:
04:44.44CIA-77BRL-CAD: pull the declaration of center2d (and his friends) up to the top scope to make
04:44.44CIA-77BRL-CAD: sure the warning reflects the current file state. preprocessor directive in
04:44.44CIA-77BRL-CAD: that function was missing a semicolon, so perhaps that was confusing gcc? see
04:44.44CIA-77BRL-CAD: if we still get an uninitialized use warning now that it's outside of the loop.
04:44.52brlcadI think I understand what it's detecting
04:45.29brlcadit is really obscure and apparently not without bugs if those line numbers are to be believed
04:46.30brlcadbut the center2d var was declared inside a loop, which I believe is only initialized once, but not per iteration like one might expect so it's possibly warning based on the future use.
04:47.08brlcadthe only thing unique about that function, however, was an inconsistent macro call, so still a little bit of a mystery
04:47.26brlcadthat'd be a good one to see the post-preprocessor output being fed to gcc
05:45.01*** join/#brlcad roberthl_ (~robert@v001.rhl.me.uk)
05:52.40brlcadoutstanding spelunking on the red failure, great to know exactly why it was failing but working with HEAD
05:53.12brlcadstarseeker: so do you know which regex feature wasn't supported?
05:54.02brlcadcurious how our regex worked and theirs didn't, because theirs is actually a never derivative
05:54.16brlcadunless if it's something like the regex enums don't match, hmm
05:54.52brlcadaha, yep that's it
05:56.22brlcadREG_NEWLINE is 300 for Tcl and 10 for ours
05:56.28brlcadREG_EXTENDED matches
05:59.12brlcadso that mystery is solved
06:00.15brlcadone take-home lesson to keep in mind for cmake is that it will have to make sure include directories are NOT listed if a src/other dep is not going to be compiled, otherwise that same type of problem can happen with any of them (png, libz, ..)
06:54.44*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
06:58.14*** join/#brlcad Robert___ (~robert@v001.rhl.me.uk)
07:06.46vttsany way to fix this? http://pastebin.com/rFeVqwHG
07:07.51vttshappens when I click on Edit -> Combination Editor
07:09.12vttssame goes for "Attribute Editor" and similar oneline error in command window for geometree command
07:09.36vtts(mac os x)
07:12.33vttsversion from svn r43679
08:04.12*** join/#brlcad Stattrav (~Stattrav@122.172.12.71)
08:04.12*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:14.20*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:52.07starseekerbrlcad: is this what you need?  http://bzflag.bz/~starseeker/extrude.preprocess
12:52.24starseeker(that's without applying you're latest fix)
12:53.16starseekerbrlcad: as a rule, the include directory variables should do the right thing when a src/other dep is turned on or off
12:53.20starseeker(for cmake)
12:53.46starseekerthat one is a particular problem because we can have the situation where regex is off and tcl is on
12:54.20starseeker(or was until the rename anyway)
12:58.58starseekerbah s/you're/your/
13:00.52starseekersweet - that last tweak to extrude looks like it got it
13:00.56dloman@anyone:  How are tcl scripts 'automatically' loaded when mged launches?  Aka, if I have a tcl script or two I'd like to put in a few of my scripts i've written and make them load whenever mged launches....
13:01.07starseekerthanks for following that up brlcad - that was waaay out of my depth :-P
13:01.35starseekeruh... I think you can do that by putting source statements in .mgedrc?
13:01.46dlomanrighto, got that part
13:02.03dlomanjust with no user configging, aka 'its part of mged'
13:02.49starseekeruh... you'd have to stick them in one of the directories that libtclcad's autopath logic (or the system tcl/tk) know about and alter the pkgIndex.tcl file (I think?)
13:03.07starseekertake a look at what src/tclscripts files do
13:03.36dlomanawesome, thanks.
13:06.28starseekereyes the failure of toyjeep.g to convert with release flags turned on... http://pastebin.mozilla.org/1126164
13:06.51starseekerthat seems to happen ONLY when I turn on release build flags - with debug flags it succeeds
13:09.01starseekeris that another one specific to my system or has someone else seen it?
13:14.13starseekerthis is the problem child:  http://bzflag.bz/~starseeker/pipeproblem.asc
13:20.45d_rossbergstarseeker: what do you mean with "convert"?
13:27.25starseekerasc2g
13:32.37starseekerd_rossberg: oh - have you had any chance to see if your particular cmake logic can work with the new cmake build?
13:33.49d_rossbergno, haven't tested yet
13:34.17starseekerhmm - maybe I'm wrong, asc2g failed with both builpes...
13:35.07starseekerd_rossberg: k.  I'll try to take a look myself if I get a chance - that's the main hurdle for being able to move the CMake logic to trunk (even if we don't use it as the "default" build logic)
13:35.54starseekers/builpes/both build configs/
13:37.31starseekerhere's a little more detail on the pipe failure: http://pastebin.mozilla.org/1126269
13:39.32starseekerlooks like VDOT is coming back with -1, which acos doesn't like...
13:42.43d_rossbergmaybe it's -1.0000000..0001 ?
13:44.19d_rossbergbtw, i'll update may brlcad cmake branch for a short code review ...
13:48.43dlomanwow, 35 mins to svn up.  that's just painful :/
13:50.52CIA-77BRL-CAD: 03starseeker * r43681 10/brlcad/branches/cmake/misc/CMake/test_srcs/timedelta_end.c.in: check fscanf here too to make compiler happy
13:53.07starseekerah, good - just needed a clean build - still avoids erroring out with debug and does with release
13:56.24starseekerthis is as much as I know currently:  http://pastebin.mozilla.org/1126326
14:02.26starseekerwhy is acos(-1) not happy...
14:03.57starseekerd_rossberg: you may be right... let's see...
14:11.21starseekeryep
14:11.27starseekerd_rossberg: thanks :-)
14:11.33starseekernow, what to do...
14:15.44CIA-77BRL-CAD: 03starseeker * r43682 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c:
14:15.44CIA-77BRL-CAD: acos isn't happy if we go outside the domain -1,1 and it looks like floating
14:15.44CIA-77BRL-CAD: point fuzz is taking us inside in some cases and out in others - peg it to -1 or
14:15.44CIA-77BRL-CAD: 1 if we're within VUNITIZE_TOL to avoid uncertainty principle effects in
14:15.44CIA-77BRL-CAD: conversion behavior
14:16.58starseekeractually, that may not be enough...
14:18.36d_rossbergstarseeker: how about "angle = bn_pi - acos(min(1., max(-1., VDOT(v1, v2))));"?
14:20.49``Erikor vmath's CLAMP()
14:22.20starseekerit's tricky, because we DO want pipes to fail the check if they really do define a pipe that's not within floating point fuzz of sane limits
14:22.46starseekerI'm just worried that borderline cases will still crop up...
14:24.24starseekerif the value is less than -1.0 + fuzz it should fail... but whether a particular value hits that threshold will vary from system to system...
14:24.36starseeker-1.0 - fuzz rather
14:25.53starseekerit's almost like if it starts straying into bad (fuzzy) territory we need to clamp not the VDOT result but the input geometry values themselves to keep them out of the danger zone
14:27.21starseekerbut how do we do that?
14:28.19d_rossbergfirst you have to put meaningful values to acos() and tan()
14:29.10d_rossbergonly if this was the case you may evaluate new_bend_dist
14:30.03d_rossbergand in my opinion the VDOT() problem is a double precision problem
14:30.19d_rossbergthere you have to "help" a little bit
14:32.22starseekerI'm betting what happened was a modeler in mged pushed the pipe right to its limits, which worked on that system but not on another.  We need another category of return value from the check which says "valid but dangerous" to keep the modeler in MGED from setting to that value but to allow existing geometry that already has the borderline values to work
14:34.29brlcadstarseeker: yeah, that's what I would have needed wrt extrude.c
14:39.48starseekeruh... has somebody been monkeying with MGED mouse bindings?
14:40.30starseekerboth left and right mouse buttons zoom in, and perspective is on whether I ask for it or not...
14:41.53starseekerneeds to head in here...
14:43.49brlcadstarseeker: yeah, I messed with mouse bindings recently because of that problem, but maybe didn't get it right
14:44.07brlcadlet me know when you're stable to test a change
14:45.39CIA-77BRL-CAD: 03brlcad * r43683 10/brlcad/trunk/TODO: report that comb editor isn't working and jeep conversion failure
14:46.33starseekerbrlcad: go ahead - I'm done monkeying for the moment
14:49.07starseekeruh, pipe not torus (or are you seeing torus failures?)
14:49.19brlcadups, right
14:49.31brlcad"torus bend" failure
14:49.45starseekerthat change I made to pipe.c does work, but I don't know if it's "right"
14:52.43starseekerwe need an "editing" check I think that is tighter than the import check, but will allow movement of settings towards safer directions
14:54.55starseekerin the case of an import that has settings meeting import tolerance (i.e. "this was valid on some system but is fuzzy/dodgy here") but not editing tolerance "on this system we don't want this value, but since we already have it don't fail"
14:56.41starseekerhits the road
14:56.53d_rossbergstarseeker: you may move the cmake logic to trunk, the brlcad.dll won't work but it looks like it can be fixed with reasonable effort
14:57.40d_rossbergand don't bother the user with your numerical problems ;)
14:58.16d_rossbergprefer to solve the numerics to writing a dialog
14:58.33starseekerone last note - I dunno how reproducible it is, but perspective was on with the jeep in release build and off in debug build
14:59.23d_rossbergon my system (MSVC) acos() accepts invalid values, the result is a nan
15:00.28d_rossberganyway, this kind of problem may arise always
15:03.30d_rossbergif you can not be sure that the result of VDOT() is between -1 and 1 (as the theory would say) _and_ acos() has a problem with it you have to test it
15:15.29d_rossbergbtw, your test isn't optimal: e.g. local_vdot = -1.5 would still crash
15:18.09brlcadoops, there he goes :)
15:22.19CIA-77BRL-CAD: 03bob1961 * r43684 10/brlcad/trunk/src/libtclcad/ged_obj.c: Fixed a problem with rect_mode that was causing an offset rectangle to be drawn.
15:26.35*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
15:26.36*** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ)
15:28.02*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
15:39.27CIA-77BRL-CAD: 03brlcad * r43685 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c:
15:39.27CIA-77BRL-CAD: why there are custom blocks of code to unitize the vector instead of calling
15:39.27CIA-77BRL-CAD: VUNITIZE() is curious and potentially related to the fuzzy instability.
15:39.27CIA-77BRL-CAD: regardless, tweak the dot product result if it just barely over/under-shoots due
15:39.27CIA-77BRL-CAD: to precision problems. using NEAR_ZERO/NEAR_EQUAL here isn't optimal since
15:39.28CIA-77BRL-CAD: it'll clamp values already within the valid [1.0,-1.0] range to the limit of
15:39.29CIA-77BRL-CAD: that range.
15:40.26brlcadd_rossberg: good point about the range, but the dot should be between 1,-1 since they're both unit vectors .. code just wasn't obvious that they were being unitized
15:45.01CIA-77BRL-CAD: 03brlcad * r43686 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: still need the lengths of v1/v2 for subsequent input validation
15:55.43d_rossbergbrlcad: if vdot > 1.0 => vdot = 1.0 and if vdot < -1.0 => vdot = -1.0 otherwise acos() may crash the program!
15:57.04brlcadthey're already unit vectors so vdot shouldn't be more than fuzz, or you saying check it anyways because it may crash (e.g., if there is REALLY bad fuzz)
15:57.21brlcadworks for me
15:57.46d_rossbergcheck it the simple way, you do not know for sure what "small" is
16:00.13d_rossbergotherwhise the code is hard to understand (why he checks for 1.0+VUNITIZE_TOL? what happens if vdot is >= 1.0+VUNITIZE_TOL?)
16:01.20CIA-77BRL-CAD: 03brlcad * r43687 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: daniel has a good point, they're already unit so no harm saying anything outside of range is clamped to the range limit
16:06.37CIA-77BRL-CAD: 03brlcad * r43688 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: um, call CLAMP() dummy
16:09.42*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
16:18.35*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
16:18.35*** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net)
16:18.35*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
16:18.35*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
16:18.36*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
16:18.36*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
16:18.36*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
16:18.36*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
16:18.36*** join/#brlcad vtts (~vytautas@diz.ktu.lt)
16:18.36*** join/#brlcad PrezKennedy (MK@whitecalf.net)
16:18.36*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
16:18.36*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
16:18.36*** join/#brlcad kanzure_ (~kanzure@131.252.130.248)
16:18.36*** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no)
16:18.36*** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
16:18.36*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
16:18.36*** join/#brlcad willdye (~willdye@fern.dsndata.com)
16:18.36*** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net)
16:18.36*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
16:18.36*** join/#brlcad kanzure__ (~kanzure@bioinformatics.org)
16:18.36*** join/#brlcad ChanServ (ChanServ@services.)
16:18.36*** mode/#brlcad [+o ChanServ] by verne.freenode.net
16:19.59*** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2)
16:20.13*** join/#brlcad CIA-14 (~CIA@208.69.182.149)
16:22.13*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
16:22.39*** join/#brlcad kanzure (~kanzure@131.252.130.248)
16:30.01*** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ)
16:30.01*** join/#brlcad kanzure (~kanzure@131.252.130.248)
16:30.01*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
16:30.01*** join/#brlcad CIA-14 (~CIA@208.69.182.149)
16:30.01*** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2)
16:30.01*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
16:30.01*** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net)
16:30.01*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
16:30.01*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
16:30.01*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
16:30.01*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
16:30.01*** join/#brlcad vtts (~vytautas@diz.ktu.lt)
16:30.01*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
16:30.01*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
16:30.01*** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no)
16:30.01*** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
16:30.01*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
16:30.01*** join/#brlcad willdye (~willdye@fern.dsndata.com)
16:30.02*** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net)
16:30.02*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
16:30.02*** join/#brlcad kanzure__ (~kanzure@bioinformatics.org)
16:30.02*** join/#brlcad ChanServ (ChanServ@services.)
16:30.02*** mode/#brlcad [+o ChanServ] by verne.freenode.net
16:42.00*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
16:45.19*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
16:55.14*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ)
17:05.01CIA-14BRL-CAD: 03brlcad * r43689 10/brlcad/trunk/TODO: torus bend pipe failure should be working now, needs one final test on the platform that had the float fail.
17:36.21dlomanquestion about the tclIndex file:  is that generated by something or do we/can we manually edit that (to add tcl scripts) ?
17:37.29tofuit's autogenerated
17:38.43*** join/#brlcad ezzieyguywuf (~wolfie@cpe-071-070-255-232.nc.res.rr.com)
17:39.25ezzieyguywufhow do I delete a shape after I have made it with in? I know I can remove it from the framebuffer thing with erase, but I want to get rid of it completely.
17:39.50brlcaddloman: if you delete the file, it'll get regenerated
17:40.24brlcadsame for pkgIndex.tcl
17:40.31dlomankk, so how do i add a new tcl script then... just put the .tcl file into the src/tclscripts dir?
17:40.52brlcaddepends on what the script is
17:41.07brlcadsomewhere in the src/tclscripts hierarchy, but the routines are organized by purpose
17:41.27dlomani fixed the 'grouper' script (by request) so it now works with 7.18
17:41.52dlomanfigured id finally put it in the repo
17:42.13brlcadthat'd be the mged subdir then, or a subdir under there
17:43.00dlomankk. danke
17:43.01brlcadsuggest reading a few of the other tcl files in here
17:43.05brlcad*there
17:43.14brlcadto make sure that it'll self-validate and load correctly
17:45.05brlcadsrc/tclscripts/mged/reid.tcl is a simple example of mged-command validation
17:45.15ezzieyguywufwaits
17:45.34brlcadsolclick.tcl is another
17:46.00brlcadezzieyguywuf: kill
17:46.12ezzieyguywufbrlcad: excellent thanks.
17:46.16brlcadthe mged quick reference sheet lists all of the basic commands
17:46.23brlcadavail on the website under docs
17:46.40ezzieyguywufbah, I should look at that. I was going through the docs in order, and I'm still on the tutorial thing.
17:46.44ezzieyguywufMaking a mug as we speak :-P
17:47.00brlcadexcellent
17:48.47ezzieyguywufincidentally, I have a sort of general question about brl-cad: is it a good replacement for, say, SolidWorks or Pro/E. i.e. will I be able to make solid model represenations of parts, put assemblies together, and generate drawings in a relatively quick manner (once I'm proficient of course)?
17:50.10brlcadezzieyguywuf: you will be able to make solid model representations of parts, put assemblies together, and do so in a relatively quick manner once you ar proficient, but it does take some time and practice to become proficient
17:50.25brlcadwouldn't say any worse than sw or proe, but definitely different
17:50.37brlcadnow drawing, though, are a different matter.
17:50.58brlcadyou can generate drawings, but not with dimensioning information
17:51.02brlcadat least not yet
17:51.08ezzieyguywufbrlcad: is there perhaps a third-party program you would recommend for doing drawings? with dimensioning and tolerances etc.
17:51.44brlcadopen source options are pretty limited, qcad comes to mind for 2D
17:52.11ezzieyguywufhm, but in that case I'd have build the part from scratch anew?
17:52.19brlcadwe're the next closest, but then annotations and dimensioning are still under development (my task for the upcoming month actually)
17:52.58yukonbob_annotations ++
17:53.11ezzieyguywufinteresting. Well, I plan on spending some time getting familiar and proficient with brl-cad (or whichever open source CAD package I settle on) before I try using it for any big projects. That will probably be a year + out.
17:53.18brlcadezzieyguywuf: example of what you can get now:  http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html
17:53.32brlcadrun "rtedge" in mged (or outside of mged) and you'll get a hidden-line rendering
17:54.23ezzieyguywufnice. But say I wanted to get that rapid-prototyped: could I export it into an appropriate file format for doing so?
17:55.18ezzieyguywufobviously if it was a part I wanted to have machined, I would need a drawing. but if it was going to be machined on a C&C machine, I think those just take solid-model files as well.
17:58.28brlcadezzieyguywuf: http://brlcad.org/tmp/converters_page23.jpg
17:58.49brlcadwe've had things rapid-prototyped from our files before with relative ease
17:58.58brlcadit depends how well modeled the object is
17:59.22brlcadmost of the rapid prototypers handle STL (or iges for some of the better ones)
18:00.16starseek1rezzieyguywuf: if you can't run qcad (I don't think the free version ever got updated to Qt4) you might try the fork librecad
18:00.24brlcadfacetizing a model is REALLY tricky business, only working without assistance about 85-95% of the time
18:00.41brlcad(most exporters require facetization)
18:00.55ezzieyguywufhm, I see.
18:01.17brlcadnote even packages like proe aren't 100%, they're around 90-95%
18:01.23ezzieyguywufI use gnome as my graphical environment, and gentoo just pulls in w/e qt libs it needs when I install stuff, so I don't think qcad will be a problem.
18:01.30ezzieyguywufare you familiar with free-cad? how does that stack up?
18:02.32brlcaddecent project, leverages opencascade for nearly everything is actually useful .. but not something I'd consider useful for production work
18:03.09ezzieyguywufhm I see.
18:03.21brlcadreally depends on your specific use case and data, though
18:03.30brlcadthey might have just enough to do what you need
18:03.32ezzieyguywufwell thank you for your time. I'll keep working through the tutorials, and see where that takes me as far as long-term brl-cad use.
18:03.35brlcadthey're just really in their infanccy
18:03.48brlcadno problem
18:04.01brlcadfeedback is definitely welcome as you work your way through
18:04.05*** join/#brlcad ezzieyguywuf (~wolfie@unaffiliated/ezzieyguywuf)
18:04.24brlcadif you run into a problem, folks are usually here to help
18:05.42ezzieyguywufyea, well first bit of feedback would be that I've found some very minor discrepencies between the tutorial and the prog, i.e. the first time it tells you to do 'Edit >> Set H' it says "Hit Accept when you're done" but doesn't tell you that Accept is in the Edit menu :-P
18:06.25brlcadgood point
18:06.36brlcadthe "accept" command will also work
18:09.00ezzieyguywufah, good to know.
18:09.56ezzieyguywufI'm kinda beating myself up for not taking notes on these discrepencies. Also when it mentions colors in the Combination Editor, you have to first click on Show Shader to get that option.
18:11.24CIA-14BRL-CAD: 03brlcad * r43690 10/brlcad/trunk/doc/docbook/lessons/en/ (mged06_creating_a_goblet.xml mged09_globe_in_display_box.xml): apply suggestion from ezzieyguywuf to make sure we refer to the Edit *Menu* when telling then to select Accept.
18:12.16ezzieyguywufbrlcad: the menu itself is actually mentioned, but on about the third accept, two lessons later (I think. just for clarity)
18:14.32brlcadnods
18:14.42CIA-14BRL-CAD: 03brlcad * r43691 10/brlcad/trunk/doc/docbook/lessons/en/ (2 files): update other references to Accept on the edit menu, change click to select
18:15.08ezzieyguywuf:-D
18:16.13ezzieyguywufso BRL-CAD was originally written and used by the 'ballistics research laborator' right? And one of the selling points (that I read on the site) is that its more than just 'skin deep'. What does all this mean though? I mean, does it mean I can design a mug and then drop a rock on it and see what happens?
18:18.44brlcadthe "Ballistic Research Laboratory" (BRL), yes
18:19.17brlcadmore than just skin deep is a reference to our solid modeling underpinnings
18:19.37brlcadas well as complete modeling of object interiors
18:20.23brlcadso if I'm modeling a vehicle, we're geared to represent every little bit of detail, do so with incredible efficiency, and still be able to analytically evaluate the model
18:21.06brlcadevery nut, bolt, wire, interior and exterior, and have it actually be volumetrically accurate and mathematically well-defined
18:23.40*** join/#brlcad ezzieyguywuf (~wolfie@unaffiliated/ezzieyguywuf)
18:23.50ezzieyguywufwow, irssi just froze for the first time in...years
18:23.57brlcadwelcome back ;)
18:24.05ezzieyguywufthanks :-)
18:27.18*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
18:27.25brlcadso don't know when you got cut off there, but hopefully answered your question
18:28.34starseekerawesome - DOJ is starting an antitrust investigation of MPEG-LA
18:38.24*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
18:38.24*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
18:38.24*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
18:38.24*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
18:38.24*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
18:38.24*** join/#brlcad kanzure (~kanzure@131.252.130.248)
18:38.24*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
18:38.24*** join/#brlcad CIA-14 (~CIA@208.69.182.149)
18:38.24*** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2)
18:38.24*** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net)
18:38.24*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
18:38.24*** join/#brlcad vtts (~vytautas@diz.ktu.lt)
18:38.24*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
18:38.24*** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no)
18:38.24*** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
18:38.24*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
18:38.24*** join/#brlcad willdye (~willdye@fern.dsndata.com)
18:38.24*** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net)
18:38.24*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
18:38.24*** join/#brlcad kanzure__ (~kanzure@bioinformatics.org)
18:38.24*** join/#brlcad ChanServ (ChanServ@services.)
18:38.25*** mode/#brlcad [+o ChanServ] by verne.freenode.net
18:40.25ezzieyguywufI don't know where we got cut off either, let me check my logs
18:40.52ezzieyguywuf<PROTECTED>
18:44.32ezzieyguywufah yea, another quirk of the tutorial (and this is the second case of this, lesson 11. can't recall the frist): tute says to run mater mug.r<ENTER> but the mater command expects Usage: mater region_name shader r g b inherit
18:45.10brlcadjust two lines missed then
18:45.15brlcad13:20 < brlcad> so if I'm modeling a vehicle, we're geared to represent every little bit of detail, do so with incredible efficiency, and still be able to analytically evaluate the model
18:45.19brlcad13:21 < brlcad> every nut, bolt, wire, interior and exterior, and have it actually be volumetrically accurate and mathematically well-defined
18:45.49ezzieyguywufbrlcad: but the actual analytical evaluation is done outside of brl-cad?
18:45.51brlcadezzieyguywuf: yeah, that's a relatively recent change to 'mater' that I'm not happy with -- it's not supposed to require all usage parameters
18:45.54brlcadbasically a bug
18:46.20ezzieyguywufbrlcad: ah. I thought maybe I (read gentoo) compiled it wrong, and this it wasn't interactive as it should have been.
18:46.37brlcadbrl-cad performs _geometric_ evaluation quite robustly, more complex analytic evaluation is performed outside
18:46.39ezzieyguywufI agree: why take away the interactive option of the tool? leave it in.
18:46.54brlcadit wasn't intentional
18:46.57ezzieyguywufah ok.
18:47.05brlcadjust an oversight during a code change a while back
18:47.53ezzieyguywufthese complex analytic evaluations that are performed outside, they'd have to be done reading the brl-cad database though, right? or does brl-cad provide an api to easily access the data that the external program would be? also, what are some examples of external programs for performing these analyses? ansys?
18:48.17brlcadAPI
18:48.22CIA-14BRL-CAD: 03brlcad * r43694 10/brlcad/trunk/TODO: mater command lost interactive functionality, need to restore
18:48.42brlcadthere are literally dozens
18:49.08brlcadwe provide a ray query interface which allows you to sample geometry in any matter you need for an analysis
18:49.27brlcadso lots of codes use that interface for a whole range of advanced purposes
18:49.48brlcadmedical dosage analysis, vulnerability/lethality analysis, signal analysis, heat studies, structural
18:50.14ezzieyguywufhrm, interesting. very interesting.
18:50.16brlcadour closest link is V/L, the code's name is MUVES -- a closed code developed by the usgov
18:51.14brlcadthe geometric analyses we directly perform are presented and exposed area calculations, volume, weight/mass, moments of inertia, centroids, and aforementioned shotline queries
18:51.43brlcadah, also overlap/interference detection
18:51.50brlcadmaybe a couple others, but those immediately come to mind
18:53.10ezzieyguywufso I can do a lot with a solid-model mode in BRL-CAD.
18:53.56brlcadright
18:54.19brlcadour weakness is converting to a surface model (polygonal) and direct design
18:54.49brlcadhttp://brlcad.org/Industry_Diagram.png might give you an idea
18:55.50brlcadstill mostly accurate though we have expanded to right a little bit with NURBS and STEP support
18:56.17ezzieyguywufhrm, I can't make heads or tails of that diagram :-P
18:56.30brlcadlots of layers of information to digest
18:56.47ezzieyguywufah, I see tha BRL-CAD shaded region now.
18:57.03ezzieyguywufso, I'm most familiar with SolidWorks: where would that fall on that diagram?
18:57.33ezzieyguywufor, more importantly, I'm starting work as a Mechanical Engineer soon: which aspects of that diagram would you think would be most useful to me professionaly?
18:57.36ezzieyguywuffor design work.
18:58.05brlcadmight help to read it this way: CADD is basically AutoCAD industry, MCAD is systems like GibbsCAM, the center 'CAD' domain is where you'd place Solidworks, ProE, NX, CATIA
18:59.05brlcadCAID is rather specialized systems, but that'd be systems like Rhino3D
18:59.54ezzieyguywufah hah. the diagram is now making more sense.
18:59.58brlcadthe dotted domains are different purposes that those domains tend to cater to
19:00.47ezzieyguywufwhat is NURBS and STEP?
19:01.08ezzieyguywufand can BRL-CAD produce a mesh to use in, say, OpenFOAM?
19:01.22brlcadSTEP is a file exchange format
19:02.13brlcadsimilar to IGES, successor
19:02.16brlcadNURBS is a boundary representation format -- what a lot of commercial CAD systems use to represent surfaces
19:02.27starseeker(Non-Uniform Rational BSplines)
19:02.33ezzieyguywufah, I see.
19:02.41brlcadezzieyguywuf: http://brlcad.org/d/node/82  <-- talks about converters in a bit more depth
19:03.55ezzieyguywufok, question about the tutorial (sorry to keep shifting the convo back and forth): I'm still working on the mug, and when I do tree mug.r it shows that body.c is composed of u bodyout.s - bodyin.s, but a) the inner rcc is not dotted and b) when I raytrace the inner rcc is not cut out from the outer one. rather they seem to be merged into one.
19:04.06ezzieyguywufis it maybe that I have more things drawn on the screen than I want?
19:04.14ezzieyguywufis there a way to ls everything that is currently active?
19:04.29``Erik_heh, pixdiff of regular vs -c "set rt_bot_mintie=1" ... http://brlcad.org/~erik/bot20110304.png  (vs a while back with http://brlcad.org/~erik/bot20101229.png)
19:04.44brlcadezzieyguywuf: type "who" .. you might have multiple objects displayed
19:05.35brlcad``Erik: not too shabby!
19:05.42ezzieyguywufwho lists bodyout.s, bodyin.s, handle.s
19:05.45``Erik(only on 64b, crashes on 32b still)
19:05.48brlcad``Erik: mirrors fail to convert?
19:06.05``Eriksame source model, not sure why they're off
19:06.27brlcadlooks like you fixed all of the original failures
19:06.52``Erikyeah, backing off a tiny bit did that... more concerned about the 32b issue, then I need to get back to geomcore
19:06.56brlcadezzieyguywuf: so when you raytrace, you're raytracing those three primitives, not mug.r
19:07.34ezzieyguywufah
19:07.41brlcadB mug.r will erase those three you're viewing and draw mug.r, then it should go to dotted for the subtracted objects and raytrace as you're expecting
19:07.48ezzieyguywufB mug.r...you beat me to it :-P
19:08.09brlcad:)
19:08.28ezzieyguywufok. mug looks proper, and yet the inner rcc is still not dotted.
19:08.49ezzieyguywufI guess its a 'minor' thing but it bugs me because the dots would make things easier to visualize pre-raytrace
19:09.05brlcadcan you post up your .g file somewhere?
19:09.32vttshowdy, r43679 gives http://pastebin.com/BmmDXE2u when selectin Edit->Combination Editor (and few others), does anybody know how to fix it?
19:09.36brlcadanon ftp to brlcad.org if you don't
19:09.39ezzieyguywufyea, one sec. wait, I can't exactly pastebin it...
19:09.53brlcadvtts: saw your report last night, it's on our list to verify
19:10.12vttsok, thanks
19:10.24brlcadthanks for reporting it
19:10.37ezzieyguywufhttp://ompldr.org/vN25zOQ <--- mug.g
19:10.56brlcadvtts: is this your own compile?
19:11.12brlcadvtts: if it is, retry with an --enable-all build
19:11.28vttsbrlcad, it is with --enable-all
19:11.38brlcadokay, good to know
19:12.18vttsto be precise: --enable-optimized --enable-threads --enable-all --with-agl
19:13.50vttsis there a way to define a custom phong based custom shader (like plastic but with custom defaults)?
19:14.24ezzieyguywufdoes brl-cad have a facility by which I can say, for example, "insert an rcc with its center at the same location as rcc1, a diameter that is 0.2 less, and a height that is 2 more (than that rcc1)" or do I have to manually check the dims of the first in order to make the second?
19:14.27``Erik'define' like write your own C evaluator, or just set different defaults?
19:15.02vttsi'd just like to assign my_plastic to a region
19:15.17vttsmultiple regions that is
19:15.53vttsor any other way to change properties for multiple objects
19:16.22vttsi'm thinking about custom shader and change'ing it's default settings, but not sure if it is possible
19:16.50brlcadvtts: yes there is, you can customize any of the phong parameters
19:16.57CIA-14BRL-CAD: 03erikgreenwald * r43695 10/brlcad/trunk/src/librt/primitives/bot/bot.c: we actually trigger this correctly now, so remove the extra debugging info
19:17.28brlcadvtts:  the combination editor has a shader button, select it, enter your object name, hit enter, and you should see all of the parameters available
19:17.42vttsyeah i'm using it now
19:17.58brlcadezzieyguywuf: does your wireframe look like this:  http://brlcad.org/tmp/mug.png
19:18.39*** join/#brlcad roberthl (~robert@v001.rhl.me.uk)
19:18.42brlcad(besides the line thickness) the inner rcc looks dashed here
19:18.50*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
19:18.54vttsbut have few objects and was thinking if it would be possible to define custom shader, assign it to regions, and modify its parameters (instead of settings for every object)
19:19.37ezzieyguywufbrlcad: it does not. let me take a screenshot.
19:20.06brlcadvtts: ah, that'd be "shader objects" which we don't yet implement but is on our wish list
19:20.17vttsok then
19:20.23brlcadvtts: you can copy shaders from objects to objects without too much difficulty
19:20.54ezzieyguywufbrlcad: http://ompldr.org/vN25zYw
19:20.54vttsok, i guess i'll catch up with that with tutorials
19:21.19ezzieyguywufvtts: which tutorial are you on? I'm on the mug :-P
19:21.27brlcadezzieyguywuf: huh, that is bizzare
19:21.29vttsezzieyguywuf, i guess the same
19:21.46ezzieyguywufbrlcad: crazy huh? Maybe I have an odd version? how can I check my vers?
19:21.47brlcadezzieyguywuf: try "Z"
19:22.01brlcadthen redraw the mug
19:23.00brlcadyour version is on the window titlebar, 7.16.8 -- wireframe code hasn't really changed
19:23.16ezzieyguywufbrlcad: http://ompldr.org/vN25zZg
19:23.20brlcadyou can try opening one of the example geometry database files, havoc.g for example,
19:23.32vttswhat could you recommend to generate something like first/third-angle projections (with measurements if possible)?
19:24.32brlcadezzieyguywuf: yeah, at a glance I would say we didn't have the same .g so apparently a bug of some sort
19:24.54brlcadezzieyguywuf: hate to say it, but try restarting mged, redraw
19:25.18ezzieyguywufI'll try, though this has persisted across multiple sessions of mged with different databases
19:25.20brlcadnote that the raytrace rendering not changing underneath is correct, not a bug
19:25.54brlcadvtts: first/third-angle projections?
19:25.55ezzieyguywufbrlcad: yea I know, I zoomed into the wireframe to make it easier to see, but left the raytrace so you could see it really was hollowed out.
19:26.09brlcadvtts, do you mean a perspective view?
19:26.20brlcadezzieyguywuf: k, just making sure :)
19:26.25brlcadsome are confused by that
19:26.30brlcadit's intentional
19:26.33vttsbrlcad, yes, but for printing with measurements and so on.
19:27.22brlcadvtts: Misc -> Perspective will turn on perspective viewing
19:27.32ezzieyguywufhttp://ompldr.org/vN25zZw brlcad: also, I sometimes get a garbled mged screen, as seen in this screenshot. if I shift-translate the object, though, it draws appropriately.
19:27.58brlcadyou can set the exact angle on the command line with "set perspective [value]" or "set perspective" to see the current value
19:27.59ezzieyguywufbrlcad: yea, restarted, still not dashed.
19:28.03ezzieyguywufI'm doing 'draw mug.r'
19:28.49brlcadezzieyguywuf: that's probably with the framebuffer enabled and you resize the window, yes?
19:28.50vttsbrlcad, view'ing is not the problem, multiplane is quite good
19:29.05vttsbut i'd like to generate some specs. with measurements
19:29.25brlcadezzieyguywuf: you're seeing uninitialized framebuffer memory -- can either turn the framebuffer off, or (as you found out) refresh
19:29.42brlcadnot the best, but has been low priority to address since data isn't affected
19:30.03ezzieyguywufbrlcad: ah ok. is framebuffer something that is brl-cad specific, or is it the same framebuffer that is referred it in my linux kernel etc?
19:31.09brlcadezzieyguywuf: it's the same concept as referred to in the kernel, but different construct
19:31.10CIA-14BRL-CAD: 03brlcad * r43696 10/brlcad/trunk/TODO: resizing embedded framebuffer sucks, fix it
19:31.11ezzieyguywuf=== load framebuffer; +++ refresh framebuffer; === <rest of code> :-P
19:32.08brlcadvtts: ezzieyguywuf just asked about that earlier today (as do many) .. annotations and dimensions are currently being worked on but not yet ready
19:32.39brlcadyou can get the model rendered as a hidden line rendering but annotations would have to be added manually in another tool unfortunately until that support is complete
19:33.08vttsok, thanks
19:33.24ezzieyguywufwhat does 'mater' stand for?
19:34.00vttsphysical substance :)
19:34.19ezzieyguywuf:-P and how are the mater and shade commands different?
19:34.28brlcaduntil then, this is about as close as you'll get http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html  and  http://brlcad.org/gallery/s/screenshots/extractor.png.html
19:34.46brlcadeasily scripted for a series of views, but still no annotations
19:35.02vttsok, np
19:35.11CIA-14BRL-CAD: 03starseeker * r43697 10/brlcad/trunk/TODO: Got a report of nirt not working correctly on Windows - Bob has reproduced this and is working on it
19:35.46brlcad'help mater'  .. mater is short for material
19:35.52ezzieyguywufah ok.
19:36.29brlcadwhich is a bit of a misnomer in that context, because it's technically just the shader for visualization -- the actual material code is set/used elsewhere
19:36.57ezzieyguywufyea, I was getting confused. "Where's the density? Material properties? Etc?"
19:37.41starseekerbrlcad: should we add a rename of mater->shader to the deprecation.txt file?
19:37.56brlcadoof
19:38.13brlcadprobably, but that's hard even for me to swallow .. because it's been 'mater' forever :)
19:38.37ezzieyguywuflol. its cool, I'll just keep thinking of that character from the Cars (tm) movie :-P
19:39.05brlcadmater is still better way to set the other combination properties, object color and inheritance
19:39.12brlcadshader only sets the shader
19:39.18brlcadso would have to resolve the other two
19:40.42brlcadstarseeker: probably best to just hit up the lower hanging fruit first, that one requires figuring out new command(s) and options to cover mater's existing commands
19:40.50brlcads/commands/settings/
19:41.05starseekernods
19:41.11starseekerjust a thought while it came up
19:44.47brlcadyeah, I think you're right
19:44.51brlcadjust maybe "not now"
19:46.20ezzieyguywufso is there a way to print out the geometry of a given object? i.e. if I create an rcc and later want to see what its vertex, height and radius are?
19:48.07brlcad'l'
19:48.11*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
19:48.12brlcadfor list
19:49.16brlcadezzieyguywuf: oh, and to answer your question from earlier, there are a few custom commands for creating objects based on cylinder end points
19:49.31brlcadrcc[tab][tab] should show them, help should describe them
19:50.18starseekerbrlcad: sweeeeet.  The head of the old simplesat project sent me about 180 autocad dwg files detailing the simplesat
19:50.30ezzieyguywufI was asking more for in general though. For example, in SolidWorks I usually create an object, draw some costruction lines, and then place things 'tangen' or in the 'middle' or 'coincident' etc.
19:50.43ezzieyguywufs/tangen/tangent/
19:50.47brlcadstarseeker: AWESOME!
19:50.55brlcadare they solid or drawings only?
19:51.01ezzieyguywufI wonder if I can build things relative to other things in brl-cad as well.
19:51.12starseekerdrawings only, but he says it was all him so they should be public domain
19:51.21starseekerawesome material for a modeling project :-)
19:51.22ezzieyguywufbrlcad: well, I guess drawings. but then I can 'mate' solid things in an assembly using similar relations.
19:51.36ezzieyguywufoh, nwm you were asking him.
19:52.05starseekerezzieyguywuf: heh, sorry - irc conversations are often kinda jumbled
19:52.06brlcadezzieyguywuf: there are ways, but they're fairly manual ways and they won't (yet) stay constrained
19:52.22ezzieyguywufhrm I see.
19:52.40ezzieyguywufI can see that being an issue if I make a part and end up wanting to scale it, for whatever reason.
19:52.48ezzieyguywufhow would you approach that in brl-cad?
19:53.00ezzieyguywufedit the database directly?
19:53.04brlcadthey'll scale up just fine
19:53.35brlcadbecause you'll have combined associated objects together into common regions or groups, and the scale would apply to all members
19:53.44ezzieyguywufwell, in the mug example: if I wanted a mug twice as big, I'd have to double the size of the inner rcc, the outer rcc, and resize the handle appropriately.
19:53.55brlcadah, no you woudln't
19:54.06brlcadyou'd just apply a matrix edit to the mug, and scale it
19:54.32ezzieyguywufhrm i see. the subject of a later lesson in the tutorial maybe?
19:55.08brlcadif you select Edit -> Matrix Edit, then select mug.r, then select any one of your primitives in the next window, you'll be able to select Scale on the Edit menu among a whole other range of edit options
19:55.12brlcadyep
19:55.31ezzieyguywufcool cool, I'll keep trudging along then.
19:55.32brlcadit starts out really basic just because there are so many foreign concepts
19:55.40ezzieyguywufyea I gotcha.
19:55.49brlcadeven for people with CAD experience, we deviate in some respects
19:55.53brlcads/some/many/ :)
19:55.55ezzieyguywufits like learning to walk again, except its learning te solid model again :-P
19:56.09ezzieyguywuflol.
19:56.42brlcadnods, I hear ya
19:57.12brlcadworking on improving our usability is a bigger-picture area we're working on, but that's major long-term complicated work :)
19:57.50brlcaddeveloping a new easier-to-use gui while not alienating existing expert modelers is pretty tricky..
19:58.10ezzieyguywufmeh, I'm not afraid to spend a week or two learning a new software.
19:58.19ezzieyguywufkinda got used to it working with linux :-P
19:58.51ezzieyguywufbrlcad: I kind of like that I can do everything from a command-line if I want
19:59.05brlcadwith the exception of two of them, all the models on http://brlcad.org/gallery/s/renderings/ were completely designed within BRL-CAD in anywhere from a couple days to a couple months for the more complex models (which some of the experts have down to just a couple weeks for even the most complex)
19:59.11ezzieyguywufone of the reasons I stuck around: I was mucking about in SolidWorks last week and had to do some repetitive stuff and thought to myself, "hey, this would be so easy to script"
19:59.39brlcadnow scripting is actually one of our strengths! :)
19:59.50brlcadwe do that better, more flexibly, than most
20:00.15brlcadyou just have to know the command layer basics first :)
20:00.16ezzieyguywufyea! that's why I want to learn brl-cad.
20:02.18brlcadthe goliath is a pretty good example of what's possible in a short amount of time -- that was modeled by a summer student from scratch (starting with a ruler and pad of paper, and the mged tutorials) in about 6 weeks
20:02.33brlcadhttp://brlcad.org/gallery/s/renderings/goliath/
20:04.08ezzieyguywufso theoretically, I could take that goliath model and run it through an FEA program do a heat-transfer analysis on it somehow?
20:04.22ezzieyguywufi.e. the project is useful for than just pretty pictures?
20:05.07CIA-14BRL-CAD: 03starseeker * r43698 10/brlcad/branches/cmake/ (20 files in 6 dirs): MFC r43697
20:05.31brlcadthe actual one they measured: http://armor.callihan.cc/gallery/goliath/06-Aberdeen_0165.JPG
20:05.42brlcadsure
20:06.48brlcadthe bridge to FEA is a pain because most require conversion from solid model to polygonal, but we do have a stable export path through Sandia National Lab's Cubit tool, which is one of the best at finite element meshing
20:06.49ezzieyguywufmulitpane mode = awesome.
20:11.11vttsit would be even better if there was a way to make secondary planes react to view changes of the primary one :)
20:11.54ezzieyguywufvtts: ah hah, that would be sweet
20:12.06ezzieyguywufI like how its un-coupled though, that comes in handy too.
20:12.14ezzieyguywufbut I see how coupling two or more views would be nice.
20:12.37brlcadvtts: how would they react?
20:13.58vttswell they all have a center point
20:14.14vttsit would be nice to see changes relative to it
20:14.46vttse.g. moving view, or changing azimuth
20:15.52vttsI'm not used to it, so shortly after starting using it got confused about orientation of the object in secondary panes
20:16.00vttsbut thats just me
20:16.17ezzieyguywufif I am in edit mode, how do I shift the screet without resizing the object I'm editing?
20:16.26*** join/#brlcad kanzure (~kanzure@131.252.130.248)
20:16.26*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
20:16.28ezzieyguywufI can zoom it/out with left/right click, but I want to pan too
20:16.48*** join/#brlcad kanzure (~kanzure@131.252.130.248)
20:17.09vttsezzieyguywuf, try using "x", "y", "z" keys
20:17.14vttsezzieyguywuf, or ae command
20:17.36brlcadezzieyguywuf: there are a slew of bindings (including pan)
20:17.51brlcadshift grips document lists them
20:18.34starseekerthinks tonight would be a good time to see how the libredwg project is coming... I can convert these to something else on-by-one if I have to, but scripting it would be so much nicer/easier...
20:18.42vttsby the way, ctrl+alt+mouse-click doesn't work as it's supposed to on mac :(
20:27.16CIA-14BRL-CAD: 03erikgreenwald * r43699 10/brlcad/trunk/ (5 files in 2 dirs): more tfloat->fastf_t/TIE_3->vect_t|point_t conversion
20:27.46ezzieyguywufso the diff between combinations and regions is that a combination is a combination of primitave objects to make a particular, more complex geometry, whereas a region is a combination of combinations and/or primitative objects to create a complex object with material props right?
20:28.36starseekerezzieyguywuf: a region is regarded as a solid object - if two regions overlap, it is a modeling error
20:28.52starseekercombinations under a region can overlap
20:31.38ezzieyguywufbut how come I go to the combination editor to edit shading etc, and not the 'region editor'
20:32.03starseekerbecause the same editor can edit both regions and combinations
20:32.08starseekerregions are just combinations with a flag set
20:32.09ezzieyguywufhrm, I see.
20:32.50starseekerin hindsight it would probably have been better to make the user interface respect the whole "regions are special" mantra a bit more, but it currently reflects the implementation reality (regions are combs with a flag)
20:33.24ezzieyguywufalso: is sloppy focus hard coded into mged? I have my window-manager set up so that focus does NOT follow the mouse, only mouse clicks. but between my framebuffer and mged command-line I see sloppy focus.
20:33.40ezzieyguywufstarseeker: good to know.
20:33.50starseekernot sure about the focus
20:35.22*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
20:36.17ezzieyguywufok question: how come when I change the color via the combination editor, I have to blash the respective region/combination in order to see the new color?
20:36.53starseekeryou mean why isn't the color update reflected in the wireframe?
20:37.53CIA-14BRL-CAD: 03erikgreenwald * r43700 10/isst/trunk/configure.ac: libtie is no more, just librt
20:37.57ezzieyguywufstarseeker: yea.
20:38.26starseekerif we're drawing a model with a LOT of lines (BoT models can have huge numbers) a wireframe view update is non-trivial from a resource perspective
20:38.35starseekerthat'd be my guess
20:38.39ezzieyguywufhrm, I see.
20:38.44ezzieyguywufwhat is BoT?
20:38.50starseekerbag of triangles
20:38.50CIA-14BRL-CAD: 03erikgreenwald * r43701 10/isst/trunk/gtk/ (gui.c isst.h local_worker.c main.c net_worker.c): update to compile against latest BRL-CAD
20:39.22brlcadezzieyguywuf: in brl-cad language groups are assemblies, regions are parts, and combinations are the mechanism for structuring regions and groups
20:39.55vttsstarseeker, is there a command to check if regions overlap?
20:39.55ezzieyguywufso combinations are like drawings.
20:40.08ezzieyguywufin SolidWorks that is (I caught the assemblies and parts reference)
20:40.14starseekervtts: rtcheck
20:40.20vttssuperb
20:40.45brlcadman, lot of irc network issues today
20:40.56ezzieyguywufsilly irc.
20:42.15brlcadezzieyguywuf: sort of like "drawings", but since we're strictly 3D-only, we refer to them more as "shapes"
20:42.36ezzieyguywufgotcha gotcha.
20:42.38brlcada shape becomes solid and occupies space when you put it in a region
20:43.11ezzieyguywufso it makes sense to use a 'region editor' then, and not a 'combination editor' yea?
20:43.31ezzieyguywufsince strictly speaking combinations are just representations of what will eventually be a solid object.
20:43.56brlcadit really should just be an "object editor" and show you parameters accordingly based on the object you're editing
20:44.22brlcadthe next generation interface eliminates that distinction
20:44.32brlcadjust shows a panel of parameters
20:44.37ezzieyguywufah hah. b/c I can change the color of the wireframe which represents the combination.
20:44.43ezzieyguywufcool.
20:44.49CIA-14BRL-CAD: 03erikgreenwald * r43702 10/isst/trunk/sdl/ (Makefile.am event.c isst.h main.c myplugin.c): disable texture fonts, make compile with current BRL-CAD
20:46.58brlcadnotes our release TODO is getting LONGER faster than it's getting shorter.. urg!
20:47.31ezzieyguywuflol.
20:54.39CIA-14BRL-CAD: 03starseeker * r43703 10/geomcore/trunk/tests/svntest/main.c: Got lists of assemblies and regions, but a deep keep of the region is not quite so simple. This seems like it might be another case where librt functionality is in order, but might already be there... need to check
21:22.52brlcadstarseeker: sorry to say it but search is nfg
21:23.44brlcadactually seems royally busted, all three tests failed on a simple model
21:24.58starseekeryou're kidding
21:25.08starseekerwhat tests?
21:26.40brlcadtried:  search . -name mug.g  (returned error about failing to make a plan)  search / -name mug.g  (returned nothing)  search .   (crashed mged)
21:26.41starseekerdebates between screaming and crying...
21:28.20brlcadprobably best to just revert trunk to prior state for release, get it into the next release .. assuming tie bot raytracing works; if it doesn't then we have more time still
21:28.48brlcads/mug.g/mug.r/ .. was using the .g ezzie posted earlier
21:29.00brlcadhttp://ompldr.org/vN25zOQ
21:30.48brlcadlooks like "search /" has plan problems, returns unknown option passed to find_create()
21:31.05brlcadthen Error: Failed to build find plan.
21:31.22starseekerI don't believe it
21:31.30starseekerhow did it go south so fast?
21:31.38starseekeror maybe I was dreaming...
21:31.41starseekerwill revert
21:32.25brlcadthe librt code can probably stay, doesn't have to be full revert
21:33.03starseekerwill need to revert raytrace.h
21:33.14starseekergrinds teeth...
21:34.09CIA-14BRL-CAD: 03starseeker * r43704 10/geomcore/trunk/tests/svntest/main.c: something not right here... keep isn't creating much of anything in the way of geometry...
21:34.28starseekernot good... can't afford this right now
21:35.07brlcadyou're in good company, lots of hard show-stoppers
21:35.23brlcadsee if bob can fix the combination editor while's he's in there working on nirt :)
21:36.57starseekerbrlcad: real quick - does search in its current form work on the command line?
21:37.07CIA-14BRL-CAD: 03erikgreenwald * r43705 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: clean up #if 0 stuff
21:37.10starseekere.g. mged mug.g search . -name mug.r
21:38.18brlcad. works, / doesn't
21:38.25brlcadinteresting
21:38.45brlcadsearch . also still crashes
21:40.41starseekersees one error right off
22:02.57starseekerbrlcad: before I revert, can you give r43706 a go?
22:03.09CIA-14BRL-CAD: 03starseeker * r43706 10/brlcad/trunk/src/ (libged/search.c librt/search.c): Variety of fixes to both libged and librt search logic.
22:04.59brlcadsure
22:07.57CIA-14BRL-CAD: 03erikgreenwald * r43707 10/brlcad/trunk/ (5 files in 2 dirs): revert to 43698, caused weird errors in output
22:09.03CIA-14BRL-CAD: 03starseeker * r43708 10/brlcad/trunk/src/libged/search.c: Catch another odd input case
22:09.18brlcadwow, isn't that like all of your changes ``Erik
22:10.55``Erikheh, this was a really weird one, bunches of misses showing up even on cubes
22:11.02``Erikbastage O.o
22:16.51starseekerwaits in suspense...
22:19.24ezzieyguywufhow can I do a primitive selection from the command-line?
22:21.26brlcadstarseeker: rebuilding now, testing in a few
22:21.35brlcadezzieyguywuf: sed
22:21.35CIA-14BRL-CAD: 03brlcad * r43709 10/brlcad/trunk/TODO: combination editor bug confirmed, mged init on mac DISPLAY issue wasn't specific to mged so not a show-stopper (mged stall if started from Terminal, restarting X11 fixed it)
22:21.57brlcadsed and oed are the two ways to go into an edit mode from the command line
22:22.17brlcadthe latter being pretty powerful, but a bit obtuse to use -- there is a tutorial dedicated to it on the website
22:22.40brlcadit's how you'd scale up, translate, rotate groups of geometry
22:24.00ezzieyguywufbrlcad: ah, thanks.
22:24.20ezzieyguywufheh, funny how so many of mged commands are the same as unix commands.
22:24.21CIA-14BRL-CAD: 03erikgreenwald * r43710 10/brlcad/trunk/ (4 files in 2 dirs): shift tie min/max to point_t
22:39.28brlcadstarseeker: that's looking MUCH better already
22:39.56brlcad'search .' and 'search /' don't do the right thing, but quick test with -name and -type seem to work as expected
22:41.16brlcadglobbing doesn't seem to be working right
22:41.38brlcade.g.: search . -name *
22:42.31starseekertry search . -name \* maybe?
22:42.36brlcadhm. same test that worked on the simple model is returning nothing for havoc for both "search . -type c" and "search / -type c" ..
22:42.39starseekeror from the command line search . -name \\*
22:42.40brlcadtried that, nothing
22:43.02brlcadyeah, variety of regression failures even for /
22:43.06starseekerodd, works here...
22:43.22starseekeroh wait, type...
22:43.37starseekerno, that works too...
22:43.54brlcadworked on the mug model, but not havoc
22:44.35starseekertries havoc
22:45.10starseekerseems to work...
22:45.32starseekeruh...
22:45.36starseekerwhat platform?
22:46.03brlcad10.6
22:46.39CIA-14BRL-CAD: 03starseeker * r43711 10/geomcore/trunk/tests/svntest/main.c: Woot - that was it, ignore nref in node write and we get content
22:46.56brlcadhm, worked if I restarted mged
22:47.10brlcadhope you're not using static variables somewhere...
22:47.42starseekernot intentionally...
22:51.59brlcadthere we go, got it to repeat
22:51.59brlcadnot sure how it's caused, but eventually, I can get it into a state where it stops working
22:52.04starseekergreat
22:52.11starseekerstarts reverting...
22:52.32brlcadsounds like it's really close, but just not very stable
22:52.55starseekerit just returns nothing?
22:53.01brlcadyea
22:53.11brlcadopened havoc, everything I tried worked
22:53.13starseekerand you just did searches for a while?
22:53.14brlcadincluding globbing
22:53.40brlcadthen swapped to mug.r, repeated random -type -name searches
22:54.07brlcadsome intentionally working but some not working (that should, like "search ." and "search /")
22:54.22brlcadthen switched back to havoc (via opendb), and it was dead
22:54.43starseekeruh... what do you expect for search . and search / - there's no plan there
22:54.54brlcadplan is optional
22:55.17brlcadaccording to usage at least, which is how 'find' is too -- should return everything
22:55.24brlcadno plan
22:57.15starseekerI doubt that has ever been true - if it was, it was accidental
22:57.15brlcadsearch . becomes very similar to "ls *", search / becomes like "tree [tops]"
22:57.15brlcadI remember trying it earlier at one point and you had it working :)
22:57.19starseekernot intentionally
22:57.24brlcadsubpath searching seemed to have issues too, search /havoc -type c
22:57.36brlcadsearch /havoc/. -type c was fun
22:57.51brlcadfun as in didn't do anything :)
22:58.30starseekerit's a pretty good bet the option parsing for the strings isn't up to all those options
22:59.22brlcadnods
22:59.57starseekerI had to be getting lucky on how things fell through earlier, 'cause I sure didn't have anything sophisticated in place
23:00.08brlcadthat last one would have been fine, heck could even limit usage to just "search [.|] [plan]" but having it stop outright after a bit is disconcerting :)
23:00.09starseekerthe "do nothing" thing worries me more
23:00.24brlcadyep
23:00.35starseekeryou can't hook a debugger up and track it somehow?
23:00.45starseekerwill try to reproduce...
23:01.04brlcadnot at the moment, have build working on the other issue, but can poke on it some more in a bit
23:01.34starseekercool - I'll lay off reverting for now then.  From what ``Erik was saying, it sounds like he's got a bit more to go there
23:02.05brlcad``Erik: think it'll be this weekend or you'll need more time?
23:03.01starseekerthink he's on his way home
23:10.23brlcadk, sending an update to the list then
23:18.35*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
23:20.19ezzieyguywufyou know, I start mged from a terminal. unless I explicitly type exit into mged, though, the process stays alive. i.e. I can X out the framebuffer window (which destroys the mged prompt window as well) and kill the term that I launched mged from and the process persists. I feel like this is a serious issue.
23:20.38starseekerbrlcad: the iteration over dbip->dbi_Head is failing - all the directory pointers are coming back null
23:20.49starseekerhow could that happen?
23:33.20brlcadstarseeker: maybe something is freeing memory
23:34.10starseekerit's not that... I checked ls, it's working
23:34.19starseekermost are null, but clearly not all
23:34.22``Erikit works for 64b, 32 gets off... I think there may be a rogue ptr += sizeof(bah*) that's not quite right or something... feel free to take a look if ya want, there's not that much code... the optimized split routine is a major portion, and it's not used with the default path
23:34.26starseekerforgot it's a hash table
23:34.41``Erik(mebbe I'm too deep in it, fresh eyes might spot something obvious)
23:35.43``Erik(my only 32b box is fbsd, which might align things different than other platforms, too...)
23:36.34starseekeris down in the pattern matching in the back trace now, which is scary scary turf...
23:36.49brlcadezzieyguywuf: if you can characterize exact steps to reproduce the problem and what you're expecting it to do (even if it's exactly the steps you just mentioned), please report it as a bug to the bug tracker:  https://sourceforge.net/tracker/?func=add&group_id=105292&atid=640802
23:37.09ezzieyguywufbrlcad: sure.
23:37.12brlcadclosing the graphics window is supposed to shut down mged (whereas closing the command window is not)
23:37.30brlcadI known issue on Mac OS X makes it not close there, but should work for linux
23:37.47brlcadand windows, don't know that it's been tested there in a while
23:37.50ezzieyguywufmaybe its cuz I'm running it in gnome and not a qt-based DE
23:38.07brlcadshouldn't matter, but can describe your setup in the report
23:38.37ezzieyguywufyou sure that link you gave me is right?
23:44.11CIA-14BRL-CAD: 03brlcad * r43712 10/brlcad/trunk/TODO: yet another, gqa gets in line
23:46.53brlcadiirc, it's actually the job of the terminal program to decide whether to kill or detact processes that are still running if a terminal session is closed
23:46.54brlcadso that might be a gnome-terminal issue
23:46.54brlcadbut closing the graphics window should have exited mged
23:46.54brlcadit's right if you already have an sf account, otherwise, can go here:  https://sourceforge.net/tracker/?group_id=105292&atid=640802
23:46.54brlcadbug reports require an sf account so we can interact with the submitter
23:53.39starseekeraaand I wiped out the process that reproduced it
23:53.40starseekerlovely
23:55.31starseekerah ha
23:55.58brlcadneeds a good shader example
23:59.30CIA-14BRL-CAD: 03starseeker * r43713 10/brlcad/trunk/src/librt/search.c:
23:59.31CIA-14BRL-CAD: Looks like that doggone global was stuck in 'on', and because it started that
23:59.31CIA-14BRL-CAD: way the plans never formed properly - they assumed no output command was needed
23:59.31CIA-14BRL-CAD: when it was. The global was inherited from the design of find, and I never
23:59.31CIA-14BRL-CAD: cared for it, but it'll be a bit of work to do it any other way so for now just
23:59.31CIA-14BRL-CAD: make sure it's zero before we start forming plans.
IRC log for #brlcad on 20110305

IRC log for #brlcad on 20110305

00:02.30starseekerbrlcad: I can't get it to enter the bad state again, but I just managed to see that that variable was on before I lost the other debug session
00:02.44starseekerpretty sure that's it - it would make sense
00:07.57brlcadwhat variable?
00:08.03starseekerdb_search_isoutput
00:08.14brlcadstatic?
00:08.27starseekerchecks...
00:08.49brlcadshouldn't really be anything static in the code pushed up into librt, or even the code in libged really
00:08.49starseekerno
00:09.01brlcadas that implies statefulness
00:09.12starseekersearch.c in librt, line 103
00:09.44starseekerit does control state during the building of the plan, iirc
00:10.12brlcadahh, worse!
00:10.13brlcadglobal
00:10.18brlcadthat's statefulness
00:10.21starseekernods
00:10.29starseekerthat's been thre
00:10.33starseekers/thre/there
00:10.36starseekerfrom the get-go
00:11.05starseekerso probably we never stressed the other search implementation enough to spot it, or we got lucky and avoided any badness accidentally
00:11.24brlcadyou have full controll of the calling params, should be easy to eliminate
00:11.39starseekeryou mean pass it around?
00:11.48brlcadbetter than a global
00:12.00brlcadespecially in a lib
00:12.01starseekercan do that, but it means changing a lot of function arg lists to match a new template
00:12.08starseekernods
00:12.44starseekerI can do it, but not tonight - I'm a half hour late now :-/
00:12.57brlcadat a minimum, the global could be changed to be a static scope global, so it's only accessible via those functions
00:13.01brlcadnods
00:13.11brlcadno worries, we have at least a couple days of debugging
00:13.23starseekergqa blew up too... augh
00:13.55starseekermaking sure the formation of the plan starts with it at zero should do for now, and next week I'll eliminate the global
00:14.03brlcadsuspect gqa will be easy
00:14.35starseekerat least the pipe fix was kinda nifty - nice work on that (you and d_rossberg)
00:14.59starseeker(and ``Erik for suggesting clamp)
00:16.48starseekerwhile I'm at it, I'll try to get search . and search / to work - could cheat and just supply -name * by default if no plan is available
00:17.21starseekeror probably just -print
00:18.01starseekeractually, come to think of it that should be the result of calling db_search_formplan with an empty argv list - will have to confirm that
00:18.15starseekerheads out
00:18.39brlcadyeah, I suspect it'll just happen if you specify no plan
00:29.04CIA-14BRL-CAD: 03brlcad * r43714 10/brlcad/trunk/src/librt/db5_types.c: put bu_vls_true() to use so that we can more robustly detect true/false string values for standard attributes. note that the bu_str_true() will match 'R' as true too since only clearly negative values constitute false.
00:30.48CIA-14BRL-CAD: 03bob1961 * r43715 10/brlcad/trunk/src/libged/nirt.c: Fixed a bug in libged/nirt.c that was tripping in the /* skip commands */ section of the windows specific code when an object being passed to nirt contained -e in its name.
00:36.29brlcadpretty awesome: http://www.engineeringtv.com/video/Opposed-Piston-Opposed-Cylinder
00:44.06CIA-14BRL-CAD: 03brlcad * r43716 10/brlcad/trunk/src/librt/db5_types.c: ws cleanup
00:50.28*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
01:57.29*** join/#brlcad dloman_ (~claymore@BZ.BZFLAG.BZ)
01:58.33*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ)
02:30.09*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
03:44.09starseekertofu: looks like the pipe fix is confirmed
03:47.43CIA-14BRL-CAD: 03starseeker * r43717 10/brlcad/branches/cmake/ (10 files in 5 dirs): MFC r43716
04:23.47starseekeraaaand libredwg doesn't get to first base
04:30.28starseekergrowl... http://www.opendesign.com/teigha_viewer can view 'em but not export 'em
04:31.29brlcadstarseeker: those are prime for import into autocad or proe then export as iges, step, and dxf
04:32.42starseekernods - proe can read them and export them as a number of things (including pdf, which is probably most immediately useful since they aren't solid) but it'll be a long slog to do 180 one by one (especially into multiple formats)
04:33.08starseekerinstalled rpm on gentoo just to get that viewer, too... grumble
04:33.18brlcadiirc, proe on the linux side can be scripted
04:52.14CIA-14BRL-CAD: 03brlcad * r43718 10/brlcad/trunk/src/libbu/booleanize.c:
04:52.14CIA-14BRL-CAD: expand on bu_str_true() so that we can distinguish more strongly between values
04:52.14CIA-14BRL-CAD: that seem to be false or true and 'everything else'. Unrecognized responses
04:52.14CIA-14BRL-CAD: still return as true, but should return as >1 so callers can distinguish yes/no
04:52.14CIA-14BRL-CAD: from possible input exceptions. return the first character as the exception
04:52.15CIA-14BRL-CAD: value for posterity.
04:52.49CIA-14BRL-CAD: 03brlcad * r43719 10/brlcad/trunk/include/bu.h: document that callers can distinguish potential exceptions with return values >1
05:24.33CIA-14BRL-CAD: 03brlcad * r43720 10/brlcad/trunk/src/mged/cmd.c: even with the plain wrapper, if the ged func returns GED_MORE, respect its authoritah
06:09.56CIA-14BRL-CAD: 03brlcad * r43721 10/brlcad/trunk/src/mged/cmd.c: (log message trimmed)
06:09.56CIA-14BRL-CAD: implement some nifty redraw code that looks at what objects are displayed and
06:09.56CIA-14BRL-CAD: what command-line arguments were specified. if displayed objects are being
06:09.56CIA-14BRL-CAD: listed on the command line, then they are potentially being edited so go ahead
06:09.57CIA-14BRL-CAD: and redraw them. while this might cause redraw lag for huge models on commands
06:09.57CIA-14BRL-CAD: that are merely read-only, the more common problem is the display not being
06:09.58CIA-14BRL-CAD: refreshed when it should for commands that DO edit the geometry, leading to user
06:14.10CIA-14BRL-CAD: 03brlcad * r43722 10/brlcad/trunk/NEWS:
06:14.10CIA-14BRL-CAD: with the automatic redraw code now in the base wrapper, about 120 mged commands
06:14.10CIA-14BRL-CAD: will potentially refresh the display that would have otherwise including dozens
06:14.10CIA-14BRL-CAD: that modify geometry. display updates on changes should improve usability,
06:14.11CIA-14BRL-CAD: reduce confusion, and help mged be more consistent
06:18.25CIA-14BRL-CAD: 03brlcad * r43723 10/brlcad/trunk/src/libged/mater.c: (log message trimmed)
06:18.25CIA-14BRL-CAD: restore incremental prompting functionality to the mater command. even better
06:18.25CIA-14BRL-CAD: than before. leverage GED_MORE for additional prompting for any unspecified
06:18.25CIA-14BRL-CAD: arguments. also takes advantage of bu_str_true()'s ability to detect input
06:18.25CIA-14BRL-CAD: exceptions. this feature was prompted by discussions with ezzieyguywuf via IRC
06:18.25CIA-14BRL-CAD: and having run into the problem myself several times, where mater
06:18.26CIA-14BRL-CAD: unintentionally stopped prompting for missing arguments when it was migrated to
06:23.41CIA-14BRL-CAD: 03brlcad * r43724 10/brlcad/trunk/NEWS:
06:23.41CIA-14BRL-CAD: restored interactive prompting for mged's 'mater' command, which was
06:23.41CIA-14BRL-CAD: functionality lost during the migration to libged.this feature was prompted
06:23.41CIA-14BRL-CAD: after discussions with ezzieyguywuf via IRC and after having run into the
06:23.41CIA-14BRL-CAD: problem myself several times while modeling. tutorial documentation was
06:23.41CIA-14BRL-CAD: inconsistent as it relied on the interactive prompting for instruction.
06:24.55*** join/#brlcad Stattrav (~Stattrav@122.167.249.60)
06:24.55*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:52.55CIA-14BRL-CAD: 03brlcad * r43725 10/brlcad/trunk/src/libged/mater.c: restore the previous mater command behavior to report the current values being set when prompting the user for new values. approximate the old text not worry too much about getting a perfect match.
06:59.31CIA-14BRL-CAD: 03brlcad * r43726 10/brlcad/trunk/src/libged/mater.c: go ahead and expand the green and blue component values. also make it clear that the values being shown are the current values.
07:04.01*** join/#brlcad Stattrav (~Stattrav@122.167.168.51)
07:04.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:59.27CIA-14BRL-CAD: 03brlcad * r43727 10/brlcad/trunk/src/libged/mater.c:
07:59.28CIA-14BRL-CAD: further efforts to mime the old behavior or better. make the g and b color
07:59.28CIA-14BRL-CAD: components optional once again if the color is being deleted. add back support
07:59.28CIA-14BRL-CAD: for deleting the shader string and color setting. use '.' to skip parameters
07:59.28CIA-14BRL-CAD: (here we deviate from original since we can't yet set default more parameters.
08:00.25*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
08:02.00CIA-14BRL-CAD: 03brlcad * r43728 10/brlcad/trunk/src/libged/mater.c: fix the prompt if we're skipping/deleting the color, account for an offset of two.
08:02.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:10.22*** part/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
08:17.43CIA-14BRL-CAD: 03brlcad * r43729 10/brlcad/trunk/src/libged/mater.c: offset pushing towards the wrong direction, be positive. also catch the error case where color has been deleted but then later is 'skipped'.
08:25.46*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
08:29.56CIA-14BRL-CAD: 03brlcad * r43730 10/brlcad/trunk/src/libged/mater.c: tweak the usage, let user know which channel is teh suck
08:30.36CIA-14BRL-CAD: 03brlcad * r43731 10/brlcad/trunk/doc/docbook/lessons/en/mged11_refining_mug.xml: update tutorial example interactive output for the mater command to reflect new form
08:32.15CIA-14BRL-CAD: 03brlcad * r43732 10/brlcad/trunk/TODO: mater now properly prompts for missing parameters interactively
08:35.51*** join/#brlcad Stattrav (~Stattrav@122.172.15.235)
08:35.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:37.26CIA-14BRL-CAD: 03brlcad * r43733 10/brlcad/trunk/ (NEWS TODO):
08:37.26CIA-14BRL-CAD: bob reportedly fixed the bug causing nirt to not work on windows. user reported
08:37.26CIA-14BRL-CAD: that nirt on windows was failing if run in a command window. bob found a
08:37.26CIA-14BRL-CAD: problem where it was getting tripped up on objects with '-e' in their name.
09:22.29*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
09:57.52*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
11:13.16CIA-14BRL-CAD: 03jordisayol * r43734 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): update copyright to 2011
13:11.14starseekermakes a note to check into Pro/Batch
13:30.42starseekeryeah... the Tegiha file convertor worked under wine, and librecad can open the dxf files (so can we with dxf-g) but there aren't any good ways I can find to get decent pdf output - gonna have to use Pro/Batch or something like it
13:46.46starseekerO.o freecad is in main portage now?  (wrong category, media-gfx, but still...)
13:47.16starseekertries it... haven't had great luck with the sci overlay builds to date...
14:34.06CIA-14BRL-CAD: 03starseeker * r43735 10/brlcad/branches/cmake/src/librt/ (search.c search.h):
14:34.06CIA-14BRL-CAD: Globals are evil - need to pass db_search_isoutput around as a parameter during
14:34.06CIA-14BRL-CAD: the process of forming the plan. As a side benefit, it shouldn't be necessary
14:34.06CIA-14BRL-CAD: for f_print to reset the value anymore, since the scope of the variable is now
14:34.06CIA-14BRL-CAD: limited to the plan forming process
14:34.30starseekerbrlcad: I think that's got it
14:34.44starseekerstill need to fix behavior for search . and friends
14:50.27*** join/#brlcad piksi (piksi@pi-xi.net)
15:01.40*** join/#brlcad piksi (piksi@pi-xi.net)
15:03.31*** join/#brlcad piksi (piksi@pi-xi.net)
15:03.46*** part/#brlcad piksi (piksi@pi-xi.net)
15:40.28ezzieyguywufwow, brlcad you've been busy.
15:40.36ezzieyguywufI  still need to submit that bug report...
16:04.03ezzieyguywufah, another discrepency I noticed in the tutorials is when it tells you to cp certain shapes, it never tells you that you have to draw them first before you can do anything to them.
16:31.30starseekerthose hessi dwg files may be even more extensive than simplesat...
16:31.35starseekersweet
16:48.18*** join/#brlcad piksi (piksi@pi-xi.net)
17:35.17ezzieyguywufheh, I'm running mged vers 7.16.8 which is > vers 6.0 so according to the tute the order of inside should be botto-top-rear-front-right-left but instead I got front-rear-right-left-bottom-top
17:36.50vttsare all menu actions executable from command line? e.g. is it possible to enter multi pane mode, set active pane, show model axes on it and so on?
17:41.44ezzieyguywufvtts: pretty sure you can. checkout the quick reference card.
17:42.11vttsdidn't find it there
17:42.14ezzieyguywufhrm.
17:42.42vttsi can change view options of an active pane, but don't know how tu change mode or switch to other pane
17:43.30vttsfound a few functions in the source, but don't know where to get id from (e.g. setmv id)
17:44.43vttseh... silly me... id is on the title bar
17:44.59vttsdoes a face-palm action
17:45.24ezzieyguywuf:-D
18:04.20ezzieyguywufhrm, still no dotted lines for me....
18:33.23ezzieyguywufso man, its taking a while for the raytracer to raytrace this toy truck. sometimes it even fails. Could it be I'm doing something wrong?
18:33.38ezzieyguywufI would expect perfermance for something of this simple geometry to be pretty good.
18:36.08ezzieyguywufhttp://ompldr.org/vN29hYw screenshot of raytrace after ~1min
19:40.56*** join/#brlcad Stattrav (~Stattrav@117.192.133.151)
19:40.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:15.05ezzieyguywufso....what are my chances of modelling an airfoil using brl-cad?
22:22.24CIA-14BRL-CAD: 03jordisayol * r43736 10/brlcad/trunk/ (10 files in 3 dirs): add new GNU/Linux mime-type icons for geometry db file v.4 and v.5
23:13.39RalithWould there be any interest in an effort to add GPU accelereation to the raytracer?
23:58.35*** join/#brlcad piksi (piksi@pi-xi.net)
IRC log for #brlcad on 20110306

IRC log for #brlcad on 20110306

00:07.51starseekerRalith: I'm sure there would be, but I doubt it would be easy
00:07.56starseekerwhat did you have in mind?
00:08.38starseekerezzieyguywuf: with what fidelity?  real airfoil modeling is usually done with NURBS as far as I know, due to the need for precision surface contour control
00:12.32starseekerwe can raytrace NURBS, but we can't yet model them
00:14.05starseekerbrlcad: this looks interesting:  http://snap.lbl.gov/pubdocs/SNAP_Solid_Model_Rev_A.stp
00:15.02starseekeranother one here:  http://planetquest.jpl.nasa.gov/documents/TPF-C_assy.stp
00:15.49starseekerhttp://www.pppl.gov/tritium/
00:19.27Ralithstarseeker: been playing around with OpenCL lately and having fun, mostly
00:19.35starseekercool
00:19.56starseekerRalith: brlcad knows more about how that would apply - I know it's of interest
00:20.01Ralithkk
00:25.25starseekerbrlcad: if step-g is right, the snap, tpf-c, and tritium models all contain solid breps
00:32.13starseekerhttp://des-docdb.fnal.gov/cgi-bin/ShowDocument?docid=4041&version=1 - iges files
00:34.51starseekerhttp://www-eng.lbl.gov/~hoff/ALICE/
01:04.39starseekerthat's actually fairly nifty: http://des-docdb.fnal.gov/0040/004041/001/BLANCO-DECAM%20MODEL.bmp
01:25.01starseekeroh, wow
01:25.05starseekerhttp://des-docdb.fnal.gov/cgi-bin/ShowDocument?docid=336&version=22
01:25.11starseekerhttp://des-docdb.fnal.gov/0003/000336/022/BLANCO%20STEP%20FILE%20AUG%2031%202009.jpg
01:40.57brlcadezzieyguywuf: you shouldn't have to draw to cp -- you only have to draw if you intend to modify/edit them
01:49.32brlcadvtts: yes, they pretty much are all accessible, though some are really tricky on the command line or are completely undocumented or assume tk or ...
01:52.04brlcadvtts: to turn model axes on/off, see the 'rset' command -- in particular "rset ax", "rset ax model_draw 1"
02:06.07brlcadto set multipane, it takes two commands:  set mged_gui(id_0,multi_pande) 1 ; setmv id_0
02:07.50brlcadoops, not pande :) pane
02:13.14brlcadsetting the active pane is similar: set mged_gui(id_0,dm_loc) ul ; set_active_dm id_0
02:13.27brlcadul | ur | ll | lr
02:17.38brlcadezzieyguywuf: yeah, something doesn't sound right -- that should be nearly instantaneous, can post your .g and I'll take a look at it, but from your cpu monitor something is definitely fishy with them both reporting ~90%
02:18.59brlcadRalith: there's always interest in improving raytrace performance, so long as it's validated too ... it's really easy to go fast, it's a lot harder to go fast and be verifiably correct
02:20.48brlcadstarseeker: woot! that's an awesome iges find ...
02:21.07brlcad220MB engine model
02:26.08Ralithbrlcad: what all's involved in ensuring validity?
02:28.01brlcaddepends on the type of changes
02:29.41brlcadbut usually, current behavior is considered a baseline, regression tests are set up, then the new implementation is compared to the existing/old implementation, and any differences beyond floating point tolerance have to be explainable (or ideally, no differences)
02:30.28brlcadbasically the new has to be compared to the current and differences have to be explainable
02:30.42brlcadeven subtle grazing cases
02:32.26brlcadfor our practical purposes, the common testing we usually perform are to have baseline raytrace images, then generate a new set of images with the new code
02:33.16cjdevlincould this (eventually) be useful in maintaining a windows build: http://coapp.org/   ?\
02:33.45brlcad1 RGB value difference in any one channel ("off-by-one") is considered ok; anything more is considered a deviation that is an error in one of the two implementations
02:34.45brlcadcjdevlin: for smaller projects that don't do proper external dependency management, probably
02:35.22brlcadotherwise, it's not very interesting since we ship an exe that has everthing needed to run, and we have everything needed to compile from source with a checkout
03:14.14Ralithsounds fairly straightforward
03:17.54brlcadyep, the process is pretty simple -- actually figuring out why something ends up different is the hard part
03:18.08brlcadespecially for grazing
03:18.34brlcadcan't brush anything off as just computation difference
03:41.54brlcadstarseeker: I think I've now downloaded almost everything you listed and a lot more :)
04:17.43starseekerbrlcad: heh - what else did you find?
04:18.23starseekerconcentrated on the BLANCO models from fermi due to bandwidth issues...
04:19.49starseekerdunno for the life of me why they didn't gzip the step/iges files, it makes an enormous difference
06:05.45brlcadjust more models
06:06.04brlcadall related to those projects
06:06.17brlcada few other peripheral items, drawings
06:19.11ezzieyguywufbrlcad: still want to see the .g for my toy truck? I moved on to the walkie-talkie and had no slowness with that.
06:19.36ezzieyguywufas far as my airfoil questions, I have some x-y coordinate files with about, I dunno, 200 points. That's as high a fidelity as I need.
06:19.53ezzieyguywufI know NACA airfoils have an equation associated with them, and it'd be great to be able to model those...
06:20.11ezzieyguywufhttp://ompldr.org/vN29sMg <--- truck.g
07:29.26*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
09:23.10*** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no)
12:24.50starseekerezzieyguywuf: airfoil shapes are a little bit tricky
12:26.34starseekeryou might be able to get close-ish with ell, rpc, rhc, and friends in various combinations but the primitive paramaters there aren't likely to correspond to the airfoil parameters, and to really do an airfoil shape properly you almost certainly need NURBS
12:27.18starseekerif you have xy points, an interesting possibility might be to create a proc-db that took those xy points and generated spline curves with them...
12:27.42starseekerbut that's not going to be easy
12:33.04vttswhats is the command equivalent for "Move Face 1234" for later use with tra?
12:36.14starseekervtts: um... unfortunately, I don't know of any way to select a particular face other than the gui
12:36.37starseekerthere may be one, but if so I don't know offhand what it is
12:37.01starseekerwould have to dig into the source code
12:37.27vttsthe menu executes: press "Move Face 1234"
12:38.40vttsor something like that
12:40.05vttsalthough facedef does something like that in one shot
12:43.17vttsjust would be nice to have an alternative which works with offsets
16:13.34*** join/#brlcad Stattrav (~Stattrav@117.192.130.135)
16:13.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:43.06starseekerturns on all the warnings for opennurbs and watches the slaughter... ho boy
17:44.14starseekerlot of unsafe floating point comparisons... wonder if I can safely script a search/replace for those with a near_zero macro...
17:45.27starseekermutter... unused params too... may need the UNUSED macro
17:46.16starseekeryeah, probably not scriptable
19:38.44ezzieyguywufstarseeker: so, tl;dr is that there is not really a good way to make an accurate airfoil using brl-cad at the moment?
19:38.55ezzieyguywufI'll be rapid-prototyping this thing, so a 'ruff estimate' won't suffice.
19:39.32starseekerezzieyguywuf: yeah, that's an accurate statement
19:43.53ezzieyguywufgrumbles.
20:00.38brlcadezzieyguywuf: you could import your 200ish points into BRL-CAD directly as a point cloud or polygonal mesh data, but the problem will be deriving a smooth surface that fit those points
20:01.09brlcadwithout knowing the equations, anything you create is going to be an approximation
20:01.28ezzieyguywufbrlcad: I know the equation, I found it in wikipedia :-P
20:01.39brlcadyou can make a perfect-fit surface for those 200ish points (using a smoothed mesh), but it'll still be a mesh
20:02.02ezzieyguywufI see where the problem is though: usually, I import the 2D airfoil data and extrude it, but in brl-cad we work with solid primitives from the get-go
20:02.25brlcadwe support extrusions from 2D
20:02.33ezzieyguywufreally? how?
20:02.38brlcadour 2D shapes support points, polylines, arcs, and bsplines
20:03.09brlcadit's not great for interactive editing, to say the least -- meant more for data import -- but it's possible
20:03.12brlcadhttp://brlcad.org/wiki/Sketch
20:03.36ezzieyguywufHrm, maybe I haven't read enough of the documenation, but from everything I've done its 'create a box, create another smaller one and subtract that from the first' etc etc
20:03.48brlcadeasier would probably be to mode the 2D sketch in QCAD, export that as dxf, import into BRL-CAD as a sketch, then extrude
20:04.06brlcadsketch isn't going to be covered by that tutorial series
20:04.19brlcadthere are a half dozen or more advanced primitives like that
20:04.55ezzieyguywufinteresting.
20:07.55starseekerneeds to study doxygen some.. will have to be careful here.
20:08.11starseekerconversion isn't automatable, from the looks of it
20:09.35starseekericu is a good example at least... *read*read*read*
21:07.42*** join/#brlcad Stattrav (~Stattrav@117.192.135.227)
21:07.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:12.06vttshow to make wireframe with hidden lines? "z clipping" doesn't seem to work :/
21:52.20*** join/#brlcad kanzure_ (~kanzure@bioinformatics.org)
21:53.02*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
IRC log for #brlcad on 20110307

IRC log for #brlcad on 20110307

01:14.33starseekervtts: rtedge
03:43.26brlcadstarseeker: so good news is I figured out the cause for why the combination editor no longer works, bad news is it was the pacakge require replacements you put in leu of ITcl_Init() in mged's setup.c
03:56.28CIA-14BRL-CAD: 03brlcad * r43737 10/brlcad/trunk/ (NEWS TODO src/mged/setup.c):
03:56.29CIA-14BRL-CAD: fixed the combination editor. didn't achieve understanding into the underlying
03:56.29CIA-14BRL-CAD: cause (left as an exercise to the reader), but changing Itcl_Init() to a
03:56.29CIA-14BRL-CAD: 'package require Itcl' was not equivalent. iwidgets ends up attempting to
03:56.29CIA-14BRL-CAD: create a class twice (LabeledFrame) causing a runtime error. changed back so
03:56.29CIA-14BRL-CAD: release can progres.
04:03.00CIA-14BRL-CAD: 03brlcad * r43738 10/brlcad/trunk/src/util/: rtwizard moved to tclscripts
04:08.36CIA-14BRL-CAD: 03brlcad * r43739 10/brlcad/trunk/src/tclscripts/rtwizard/rtwizard.tcl: use the same initialization approach archer uses so rtwizard will run prior to installation
04:19.24CIA-14BRL-CAD: 03brlcad * r43740 10/brlcad/trunk/src/bwish/ (cadAppInit.c main.c):
04:19.24CIA-14BRL-CAD: same patch applied to mged for unbreaking the Combination Editor applies here.
04:19.24CIA-14BRL-CAD: confirmed that archer and rtwizard were non-functional, would not start, due to
04:19.24CIA-14BRL-CAD: multiple class errors. this reverts the package require back to an Itcl_Init(),
04:19.24CIA-14BRL-CAD: itk too. archer/rtwizard now start up again.
04:23.05brlcadvtts: the bug you reported here is now fixed, thanks
04:26.52CIA-14BRL-CAD: 03brlcad * r43741 10/brlcad/trunk/NEWS: (log message trimmed)
04:26.53CIA-14BRL-CAD: may or may not be specific to Mac OS X, but the bug report and confirmation were
04:26.53CIA-14BRL-CAD: both on Mac OS X. the bug prevented both archer and rtwizard (both bwish-based)
04:26.53CIA-14BRL-CAD: from running. they'd abort out during initialization with a multiple class
04:26.53CIA-14BRL-CAD: error. problem was isolated as a change to the way bwish initialized. thanks
04:26.53CIA-14BRL-CAD: to vtts for reporting the related combination editor bug via IRC. Runtime
04:26.54CIA-14BRL-CAD: release testing for the previous release presumably happened on Linux, so this
04:30.52starseekeris getting rather tired of Itcl/Itk
04:31.04*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
04:31.10brlcadoops
04:31.15starseekeris getting rather tired of Itcl/Itk
04:32.19brlcadI presume those package require changes were tested on Linux?
04:32.39starseekerI've been using them to do everything for a while now
04:32.58starseekerWindows, Mac and Linux
04:33.14brlcadon Mac?  rtwizard loads?
04:33.33starseekerdunno about rtwizard - will have to check tomorrow if I can make it in
04:33.42starseekerhas a leak somewhere
04:33.47brlcadmged would start just fine, it wasn't until it hit a panel that used iwidgets
04:33.49starseekerbasement carpet is wet
04:33.55brlcadfun!
04:33.57brlcadnot
04:34.07starseekerand we found out one of our cats has gone blind
04:34.13starseekerthis has been a real kicker of a weekend
04:34.14brlcadaw
04:43.46CIA-14BRL-CAD: 03brlcad * r43742 10/brlcad/trunk/TODO: search seems to be working much better now, but noticed several non-critical test failures that current usage docs (and reasonable expectations) indicate they should work. most are pretty simple.
07:10.55*** join/#brlcad ibot (~ibot@198.60.114.207)
07:10.55*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
09:06.27*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
09:15.17*** join/#brlcad Stattrav (~Stattrav@117.192.250.99)
09:15.17*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:23.05*** join/#brlcad Stattrav (~Stattrav@122.172.203.101)
10:23.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:06.05dlomanyawns
11:08.33dlomanSo.... if a cmake find script isn't finding libraries... where should i put the paths to the libs?  in PATH or LD_LIBRARY_PATH ?
11:21.26Ralithmight as well try and see
11:27.04*** join/#brlcad Stattrav (~Stattrav@117.192.225.133)
11:27.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:56.19*** join/#brlcad Stattrav (~Stattrav@117.192.238.155)
11:56.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:13.44starseekerdloman: depends on the script
12:13.49starseekerwhich script is failing?
12:19.21dlomanfindqt
12:19.38starseekertry putting the bin directory that has the qt binaries in PATH
12:19.39dlomanat i verified qt is in /usr/lib32
12:19.44dlomanright on
12:19.49dlomanjust sat back down
12:19.54dlomangonna try that very thing :)
12:20.01starseekerheh
12:22.08dlomanso yeah.... lots of rain + sudden temp drop + stupid winds == nastly little mess up here.
12:22.41dlomanone entire side of my jeep is coated in 1/2" of snow/ice stuff that's hard as a rock.
12:22.48starseekerow
12:22.50dlomanbroke both my ice chippers on it.
12:23.15starseekeris trying to figure out where the water that soaked his closet carpet is coming from...
12:23.35dlomancheck the walls.
12:23.42dlomanwe just had a leak fixed.
12:23.42starseekerguessing either the roof finally gave up the ghost or a hole in the siding over the front door...
12:23.54starseekerwalls are pretty dry
12:24.00dlomanours were too :)
12:24.12dlomanleaking in the second story (of 3 stories)
12:24.24dlomanwas running down a beam or two in the main load bearing wall.
12:24.28dlomancrazy
12:24.38starseekerdloman: who did you call to get it taken care of?
12:24.57dlomanoh man.  Its the contractor that originally put our roof on.
12:25.08starseekerah
12:25.11dlomanname is down stairs, but its a MD contractor
12:25.28dloman$200 min visit fee, but that covers 90% of leak fixes and shingle replacements.
12:25.55starseekersounds interesting
12:30.07dlomanill dig up the name the next time I head downstairs.
12:32.35starseekerdloman: awesome, thanks
12:36.34dlomanSo who knew:  Batman Begins score == great coding music :)
12:37.01starseekerhehe
12:37.20starseekerprobably won't be in today, or if he is it'll be later
12:37.41starseekerneed to schedule leak fix due and get dehumidifier rented
12:47.21dlomanCranford Contractors: 410 792 7663
12:47.40dlomanthey got here pretty quick (2 day turnaround) considering all the wind we've been having lately
12:48.02dlomanthis is my first experience with them, but they seemed to have fixed up the roof pretty well.
12:50.52starseekerhmm... I probably need somebody to deal with siding as well as roof
12:53.40dlomanah bloody hell.
12:53.52dloman:/ gotta get QT.
12:53.59starseekerhehe
12:54.17dlomanthought it was installed, but noooooo.  nothing can be that easy
12:55.28dlomanI so need an 8 core laptop.....
13:12.38brlcadPATH is binaries, LD_LIBRARY_PATH is libraries (for linux/bsd, not other platforms)
13:13.17dlomanbrlcad: kk awesome
13:23.34dlomanhahaha, just a a film trailer for "Inner city vs Outer space"
13:23.47dlomanstreet thugs vs space aliens
13:23.54dlomanaaaahahahaha, i love it.
13:24.06dloman"Attack the Block" i think its called.
14:38.20*** join/#brlcad ezzieyguywuf (~wolfie@unaffiliated/ezzieyguywuf)
14:42.36epilegbrlcad: actual trunk successfully compile in ubuntu and fedora, but i get errors in opensuse, and i'm a bit lost. Can You help me please?
14:42.36epileghttp://paste.debian.net/109872/
15:08.37ezzieyguywuf[10:08:27] IRCnet: irc.freenode.net:6667 (IRCnet)
15:08.39ezzieyguywufwhoops
15:14.57CIA-14BRL-CAD: 03davidloman * r43743 10/geomcore/trunk/src/utility/ (Config.cxx GSUuid.cxx): Add some includes to make compiling on Ubuntu 10.10 work.
15:21.33CIA-14BRL-CAD: 03davidloman * r43744 10/geomcore/trunk/ (2 files in 2 dirs): More includes to make compiling on Ubuntu 10.10 work.
15:25.38CIA-14BRL-CAD: 03davidloman * r43745 10/geomcore/trunk/src/GS/GSClient.cxx: cast uint64_t to long long to make printf happy
15:30.43CIA-14BRL-CAD: 03davidloman * r43746 10/geomcore/trunk/ (3 files in 2 dirs): Final round of adding includes to make compiling on Ubuntu 10.10 work.
15:49.30CIA-14BRL-CAD: 03erikgreenwald * r43747 10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: add search.c
16:12.37brlcadepileg: sure, the key there is "warnings being treated as errors"
16:13.21brlcadso either "make STRICT_FLAGS="  or run configure with --disable-strict
16:14.41epilegok, i'll try with "--disable-strict"
16:31.24CIA-14BRL-CAD: 03brlcad * r43748 10/brlcad/trunk/src/libfb/tcl.c: expand the function declarations from K&R form to complete 'real' prototypes. these probably belong in a lifb_private.h header or (better) wrapped into a callback btable.
16:31.46brlcadthat should quell the warning too
16:41.08epilegbrlcad: solved! successfully compile and install on openSUSE
16:42.34epilegBTW I do not find the way to make an application as default for some mime-type in KDE. no problem in GNOME. Someone nows how to do it?
16:42.46epileg*knows
16:50.36*** join/#brlcad Stattrav (~Stattrav@117.192.144.236)
16:50.36*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:03.13*** join/#brlcad Stattrav_ (~Stattrav@117.192.145.13)
17:11.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:30.51dlomanIs there a built in try/catch framework inside the TCL we use?
17:40.24vttsbrlcad, thanks for the fix, just checked it, works like a charm
17:43.54vttsif you are in the mood, there is another one, with "archer -h": http://pastebin.com/unDAYkfJ
17:44.17vttsmac os x, r43748 build with --enable-all
17:45.00vttsalthough launching it with other options doesn't cause this
17:45.47vttsunfortunately i don't have ogl support, so cannot see anyting past the startup screen
18:03.01*** join/#brlcad Stattrav_ (~Stattrav@117.192.142.105)
18:12.10*** join/#brlcad Stattrav (~Stattrav@117.192.137.168)
18:12.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:25.43``Erikwell, poop, tcl ignores --disable-64bit-build
18:35.13dlomanSo it turns out that the Children of Dune OST is pretty darn good.
18:41.15*** join/#brlcad Stattrav_ (~Stattrav@117.192.138.0)
18:51.14CIA-14BRL-CAD: 03davidloman * r43749 10/geomcore/trunk/src/libJob/JobManager.cxx: QT ripout cleanup: JobManager *should* start workers when JobManager::start() is called.
18:57.43CIA-14BRL-CAD: 03brlcad * r43750 10/brlcad/trunk/BUGS: archer's kill command seems to be working better now
18:59.04CIA-14BRL-CAD: 03brlcad * r43751 10/brlcad/trunk/TODO: write up a bunch of archer to-do tasks that are necessary before archer can go into beta (some are even alpha blockers). mostly focusing on usability and migration.
19:01.33CIA-14BRL-CAD: 03davidloman * r43752 10/geomcore/trunk/ (include/AbstractJob.h src/libJob/AbstractJob.cxx): Wire UUIDs back into abstractjob.
19:13.19CIA-14BRL-CAD: 03davidloman * r43753 10/geomcore/trunk/tests/libJob/ (BasicJMTest.cxx PrintToStdOutJob.cxx): Get BasicJMTest working again.
19:15.04CIA-14BRL-CAD: 03davidloman * r43754 10/geomcore/trunk/tests/libJob/BasicJMTest.cxx: Bad Developer: Redundant delete calls for JM. Forgot to delete PrintToStdOutJob objects on exit.
19:25.38CIA-14BRL-CAD: 03davidloman * r43755 10/geomcore/trunk/docs/CMakeLists-Template.txt: Drop template. Very outdated.
19:29.11CIA-14BRL-CAD: 03davidloman * r43756 10/geomcore/trunk/tests/coreInterface/: Drop coreInterface test ....dunno how I missed removing this earlier.
19:30.35CIA-14BRL-CAD: 03davidloman * r43757 10/geomcore/trunk/tests/ (libEvent/BasicEventTest.cxx libNet/PrintingMsgHandler.h): Remove a few lingering QT ghosts
19:34.46CIA-14BRL-CAD: 03davidloman * r43758 10/geomcore/trunk/src/ (CMakeLists.txt adminpanel/): Drop Adminpanel. Old research project that is no longer useful.
19:36.53CIA-14BRL-CAD: 03davidloman * r43759 10/geomcore/trunk/include/ (AppLauncher.h BaseApp.h): Drop unused application launch framework.
19:37.36CIA-14BRL-CAD: 03davidloman * r43760 10/geomcore/trunk/src/libJob/ (JobWorker.cxx JobWorker.h): Remove a few more lingering QT ghosts
19:43.14CIA-14BRL-CAD: 03davidloman * r43761 10/geomcore/trunk/CMakeLists.txt: Remove CMake's search for QT. ....and with that, Geomcore is 100% qt free.
19:43.45brlcadwoot
19:44.03brlcadhoray for simplified dependency management ;)
19:46.47CIA-14BRL-CAD: 03brlcad * r43762 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: unnecessary cast
19:48.05``Erikadminpanel doesn't require qt? or is it not part?
19:48.32dlomanit was a research thingy
19:48.39dlomanalready been superseded
19:48.48dlomanso i just deleted it.
19:49.43``Erikaight, cool.. saw some gui pieces, so I wasn't touching it
19:54.54dloman``Erik: starseeker thanks for all the help!
19:57.33starseekerthat reminds me - the assembly and region trial on Friday succeed in something like 30 seconds as opposed to 5 minutes for havoc
19:59.08starseekerdloman: you're welcome :-)
20:01.14starseekerbrlcad: are you volunteering to make new icons? :-P
20:01.15CIA-14BRL-CAD: 03jordisayol * r43763 10/brlcad/trunk/misc/debian/brlcad.sh: add brlcad man path to manpath env. variable in GNU/Linux
20:25.12*** join/#brlcad ezzieyguywuf (~wolfie@cpe-071-070-255-232.nc.res.rr.com)
20:43.37*** join/#brlcad Stattrav (~Stattrav@117.192.129.10)
20:43.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:48.41brlcadstarseeker: if it's holding up beta, sure
20:48.57brlcadthat one isn't an alpha hold-up, but should be fixed by beta
20:49.51starseeker<PROTECTED>
20:50.10CIA-14BRL-CAD: 03erikgreenwald * r43764 10/brlcad/trunk/src/librt/primitives/bot/tie_kdtree.c: clean up #if0 blocks, commented out printfs, etc
20:50.11starseekerthose were mostly just "better than grey pixels"
20:54.37brlcadI noticed that there were a bunch of icons missing, I only listed the few that had some bigger issue
20:55.29brlcadisolates the nmg bug down to ~100 lines
21:01.52yukonbob1brlcad: what's the script and what are it's requirements (ie: needs certain database, certain brl-cad version, certain env?)
21:11.40brlcadyukonbob1: it's our tcl test suite
21:11.55brlcadruns hundreds of commands through mged
21:12.20brlcadone of the hundreds is crashing, and it wasn't immediately obvious which one exactly
21:25.06*** join/#brlcad Ralith (~ralith@d142-58-35-248.burnaby.sfu.ca)
21:33.37*** part/#brlcad epileg (~epileg@unaffiliated/epileg)
21:36.43yukonbob1brlcad: ah -- is this only w/ most recent versions of brl-cad, or would I be able to witness w/ 7.18.0
21:36.47yukonbob1?
21:41.45brlcadit's been in there for over a year, it's part of our regression testing
21:41.50starseekerbrlcad: missing?  you mean primitives without icons?
21:43.00brlcadyeah
21:43.31brlcade.g., not a big deal that rpp doesn't have an icon
21:43.37starseekerah
21:44.01brlcadexpecially since it'd then have to be rectified against arb8's icon since they'd look identical
21:44.05starseekertried to at least get something for most of the significant ones, although adimttedly some of them suck...
21:44.46brlcadI was just listing the things that might affect release, not a critique or comment on the progress made to great
21:44.56brlcadto *date .. great stuff
21:45.16starseekernods - we really need a proper graphic artist for "release quality" graphics
21:45.27starseekerthat's a skill all its own
21:45.51brlcadsince we were talking about release issues the other day, I thought I'd offload several things that I've noticed
21:47.29starseekercool - thanks!
21:47.30brlcadmaking proper graphics isn't hard - you just have to be hyper observant, obsessive attention to detail, or decent amount of experience
21:47.38starseekernow if only we could get time to work on them...
21:48.25brlcadyep
21:48.43brlcadit takes a long time to make good graphics
21:49.37brlcadcoders undervalue graphics designers (oh that's easy, just takes a couple hours..) as often as managers undervalue coders (oh that's easy, just takes a couple days)
21:50.12CIA-14BRL-CAD: 03starseeker * r43765 10/brlcad/branches/cmake/ (27 files in 15 dirs): MFC r43764
21:52.52*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
21:55.16starseekerbrlcad: I don't suppose we can bsd license common.h by any chance?
22:00.08*** join/#brlcad ibot (~ibot@rikers.org)
22:00.08*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
22:22.21CIA-14BRL-CAD: 03brlcad * r43766 10/brlcad/trunk/src/librt/ (Makefile.am primitives/nmg/nmg.c): partial revert of the ntohl/htonl conversions made to NMG since they cause a crash. turn off strict since we're temporarily reverting back to bu xdr routines.
22:23.08starseekerbrlcad: after release, do you mind if I try to straighten out whatever the issue was with package require Itcl and go back to that approach?
22:23.38starseekeris taking a stab at updating the CMake logic for current code and now remembers why he went the other route...
22:27.09brlcadstarseeker: there's not really copyright-worthy in common.h, at least nothing I'd worry about reusing on a whim :)
22:27.21starseekerah, cool :-)
22:27.39starseekerwill need the UNUSED macro or something like it to make openNURBS happy with strict flags...
22:28.02brlcadstarseeker: you can sort it out before or after the release (preferably on a platform where you can reproduce), the issue was really just getting back to a stable point
22:28.21starseekernods - I'll wait for now
22:28.32brlcadi have my suspicion as to the cause
22:28.43starseekerwhat's that?
22:28.46brlcadit's double declaration of classes
22:28.53brlcadso basically inconsistency
22:28.57starseekerah
22:29.03brlcadI think you just didn't take it far enough
22:29.14brlcadyou make itcl and itk package require but not iwidgets
22:29.29brlcadso iwidgets was static loaded, but the other two not
22:29.31starseekerO.o  
22:29.45brlcadso something went awry in tcl's book-keeping of what is loaded
22:29.47starseekerI didn't realize there was a library to be statically loaded with iwidgets
22:29.59starseekerthought it was just a bunch of tcl scripts
22:30.19brlcadit is
22:30.37brlcadbut it does a Tcl_Import of iwidgets
22:30.50starseekerahhh
22:31.14brlcadI don't know -- I could be way off, but that's something that came to mind
22:31.33starseekerwonders how the heck it works for him...
22:31.44brlcadshould frankly be able to remove itcl/itk/iwidgets from bwish/mged
22:31.54brlcadmake the scripts package require correctly
22:32.16starseekeroh, you mean do it "normally" in the src/tclscripts files?
22:32.25brlcadright
22:32.52brlcadthere's no benefit for the cad commands to be auto-loaded on instantiation of an interpreter
22:33.00brlcadI mean, no major one at least
22:36.11starseekershould be fair to package require BRL-CAD or some such...
22:38.29CIA-14BRL-CAD: 03brlcad * r43767 10/brlcad/trunk/src/fbed/Makefile.am: per-target cppflags wasn't added until 1.7+ so use AM_CPPFLAGS instead
22:42.35starseekerrtwizard runs here - I wonder if that's due to the screwy install setup I have...
22:48.36starseekerbrlcad: remind me why we're importing itcl/itk/iwidgets into the global namespace?
22:49.33brlcadbetter question is what will break if we don't import it, and that I do not know
22:49.49starseekerhmm
22:50.28brlcadplenty broke from what should have been an equivalent change ;)
22:52.53starseekerOh, I wasn't planning on doing it now :-P
22:53.03starseekerwe have enough release problems without borrowing more
22:53.29starseekerI'd just really like to get to where our Tcl/Tk stuff isn't so cranky and fragile anymore
22:54.57starseekerO.o I can't reproduce the failure here - what platform did you see it on?
22:57.04brlcadmac, 10.6
22:57.25brlcadvtts was also on mac iirc, dunno which version
22:57.48brlcadmine is usually an enable-all build for testing
23:18.28brlcadstarseeker: when you wrote the tcl mged tests .. what state did you leave them in?
23:18.43brlcadi.e., were they working?
23:23.18starseekerat the time they were, I believe
23:23.25starseekerthat was a long time ago
23:23.50starseekerPro/Batch sucks
23:24.40brlcadinteresting
23:25.06brlcadbecause I got a magic bomb translating halfspaces, null parameter, that I can't see having ever worked
23:26.16starseekerhuh
23:26.34starseekershrugs - I may have messed it up somehow
23:27.26brlcadno no
23:27.33brlcadthe problem was in librt
23:28.01starseekeroh, you mean an actual problem with the halfspace, not the test scripts?
23:28.12brlcadI added the support, I just don't see how translating a half ever worked with the out pointer was null
23:28.18brlcadright
23:39.21brlcadhm, well that's positive.. seems to be crashing on linux too
23:39.37brlcadstarseeker: if you have a build, can you test what make test in regress/mged does?
23:43.31CIA-14BRL-CAD: 03brlcad * r43768 10/brlcad/trunk/src/librt/primitives/half/half.c: how did this ever work? if the out pointer is null, we need to initialize and create one. nearly identical to what extrude does now.
23:43.43starseekerum... need to make an autotools build, one sec
23:45.32brlcadtry without that change first
23:45.35CIA-14BRL-CAD: 03starseeker * r43769 10/brlcad/branches/cmake/src/ (bwish/cadAppInit.c bwish/main.c mged/cmd.c mged/setup.c): CMake branch isn't set up to build with itcl/itk C api - need to resolve the package require issues.
23:45.43starseekerk
23:48.16starseekerbrlcad: when rtwizard is crashing, is it from an installed location or the build dir?
23:49.17starseekerheh - just noticed, shapelib is actually an lgpl dependency
23:49.25starseekerlooks like our first
23:54.13starseekerinteresting - comb.tcl already has a package require Iwidgets
23:54.21brlcadstarseeker: actually it's dual-licensed
23:54.22brlcadMIT
23:54.29starseekerah, cool
23:54.44brlcadan odd dual-license, but I wasn't going to complain
23:54.46starseekerwonders what the point of a dual LGPL/MIT license is...
23:55.16starseekerautotools build clunking along
23:55.31starseekerwill have to remember how to run those tests again - completely forgotten
23:56.55brlcadcd regress/mged && make test :)
23:56.56starseekeriirc, I had notions of replacing the sh regression logic with tcl regression logic for cross-platform compatibility...
23:57.04starseekeroh, I got it that far?  cool
23:57.19brlcadlooks like my linux failure has been fixed with recent changes
23:57.55starseekerrtwizard appears to have package require calls too
23:58.48starseekersomewhat bemusingly, I don't see such a call in archer
23:59.46brlcadiirc, my rtwizard invoke was pre-install
IRC log for #brlcad on 20110308

IRC log for #brlcad on 20110308

00:01.05brlcadI rarely test from install unless I'm nearing release testing, several extra minutes saved per compile, which adds up fast
00:04.42starseekernods - I'm the same way
00:05.06starseekerit's a possible difference to check - the cmake build and the autotools build runs are quite different
00:05.56brlcadnods
00:06.45brlcadyeah, I just verified that your halfspace test failed for half on linux too
00:06.56brlcadit's the oed.mged set of tests
00:07.04starseekerhmm - wonder if I just commented it out and moved on...
00:07.19brlcadI was running them manually since they're easier to isolate
00:07.23starseekersome of those were a little tricky to set up, so I may have just assumed I had done it wrong
00:07.30starseekernods
00:07.37brlcadso it maybe always has failed
00:08.10brlcadthing is, it stops the whole testing progression and stops pretty early on with it trying to move a half
00:08.24starseekerpossibly - that has to be over a year since I've touched those, and probably longer, so I don't recall much
00:08.24brlcadwith the fix, it gets all the way to the end
00:08.29starseekersweet!
00:08.39brlcadsuccessfully even
00:08.45brlcadnow the log is another matter...
00:09.00brlcadheh, it lists slews of errors and failures, but it's not clear which are intentional and which are not
00:09.12brlcade.g., saw a "killall*" in there
00:09.35brlcadbut then that might have been a prefix or something too
00:09.38starseekerurm... don't recall if I got to the intentional failure checking or not...
00:10.00starseekermainly recalls a lot of time spent on primitives and quick reference card commands
00:10.52starseekerbrlcad: you still build primarily in the source tree?
00:11.01brlcadwell then, it looks like I maybe just implemented non-pushed matrix edit support for halfspaces
00:12.27brlcaddepends on the platform, maybe half the time but I wouldn't say it's primarily in or out
00:13.11brlcadsome platforms are almost exclusively out of dir (linux), some are mix in/out depending on what I'm doing (mac), and others still are almost always in dir (release)
00:13.19starseekerk - don't know why that would still matter but also something to keep in mind
00:14.03brlcadpossible, but it was a pretty isolated failure with the double-class error
00:14.35brlcadi'll give it another test post-release
00:16.02starseekerbrlcad: I think we found your new commuter car:  http://blogs.wsj.com/tech-europe/2011/03/07/the-car-faster-than-a-speeding-bullet/
00:21.57starseekerbrlcad: yep:  ERROR: NULL rt_half_internal pointer, file primitives/half/half.c, line 505
00:22.13starseekerupdates to confirm fix
00:22.18brlcadcool
00:22.28brlcadpretty much confirms, awesome
00:22.49brlcadhm, I don't see how/where oed actually applies the matrix
00:31.10starseekerbrlcad: for which test?
00:31.44starseekeroh, confirmed that regression is fixed with the latest update
00:32.58brlcadthat's bizzare though too
00:33.10brlcadthe test does oed / oed_half.c/oed_half.s
00:33.35brlcadthen merely presses accept
00:33.47brlcadthat results in the halfspace import fail
00:33.53brlcadfishy
00:33.57starseekerO.o
00:35.13brlcad*sigh* .. back to gdb for understanding
00:37.10starseekertechnically we don't have to pass those for release, they were never added to the "offical" regression testing...
00:37.58brlcadit's not a matter of passing the test, it's a failure related to code that changed
00:38.23brlcadthe tests are simple enough, they're worth checking into to make sure something else wasn't horked
00:38.57starseekernods - just noting that some of the "failures" may be nothing new...
00:39.31brlcadsure
00:39.42brlcadbut they're the closest thing to a test at this point for all the librt code that was changed
00:39.49starseekerah, point
01:10.52starseekerhmm... cmake build succeeds in running rtwizard and archer on 10.6, although I do see those kCGError messages
01:11.03starseekerwill have to try autotools tomorrow
01:15.27*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
02:48.01CIA-14BRL-CAD: 03brlcad * r43770 10/brlcad/trunk/NEWS:
02:48.01CIA-14BRL-CAD: inadvertently reviewing and fixing bugs for release, fixed a never-implemented
02:48.01CIA-14BRL-CAD: feature of halfspaces. if you put them into a combination and apply a matrix to
02:48.01CIA-14BRL-CAD: the combination, librt would bomb with an invalid magic error. the half
02:48.01CIA-14BRL-CAD: primitive was updated to handle that case which is used by mged to apply
02:48.02CIA-14BRL-CAD: matrices to wireframes without writing to a disk record.
02:49.00CIA-14BRL-CAD: 03brlcad * r43771 10/brlcad/trunk/TODO: technically unbusted though only because it's half-reverted. still investigating the cause, but todo is todone.
03:16.09brlcadgives bottie a final round of testing
03:16.32starseekerbrlcad: the last report on bottie was "consistently crashing"
03:17.47CIA-14BRL-CAD: 03brlcad * r43772 10/brlcad/trunk/src/librt/primitives/half/half.c: oops, wrong cast
03:19.10brlcadheh, k
03:29.04brlcadjust worked with a simple sphere test case
03:30.04brlcad50% speedup
03:30.46brlcad(of tie vs bot .. sph was around 200% faster)
03:33.58starseekercool
03:34.14starseekerhuh, this is interesting:  http://www.cs.mtu.edu/~shene/COURSES/cs3621/NOTES/
03:34.16brlcadnice 300% improvement on a model with just 9k tris
03:34.25brlcad600k rtfm vs 200k rtfm
03:35.15brlcadI think I've seen that site
03:37.16starseekerneeds to read through that
03:37.18brlcadand it scales nicely on a big image, 21 sec vs 7 sec
03:37.23starseekerawesome :-)
03:37.26brlcadthe whole team should read through that
03:37.41brlcadabout once a year ;)
03:37.52starseekerhehe
03:38.24starseekerwill probably rediscover it around this time next year
03:57.13brlcadwow, actual 10x increase on a 0.5M poly bot (simple sphere)
04:00.28brlcadand on a 1.2M poly...
04:02.41brlcad3 sec vs 62 sec
04:02.58brlcadhawt
04:04.33brlcadso that's about as good as it will probably get comparison-wise since it's a simple shape that's best for kdtree being compared with a bot not using pieces optimization (default) and is but a single simple shape
04:09.00brlcadnice, 5x increase on t62
04:09.13brlcad(after removing the silly "I want normals" limitation)
04:10.05brlcadhm, maybe not on that one ...
04:23.32brlcadyeah, that wasn't right, looking to be about 40% faster (about 13s vs 21s) on a fully hierarchical bot t62
04:44.20*** join/#brlcad ibot (~ibot@rikers.org)
04:44.20*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
05:55.51CIA-14BRL-CAD: 03brlcad * r43773 10/brlcad/trunk/NEWS: looks like today is the day. reword the BoT-TIE metrics having directly observed (valid) performance from 40% to 20x faster. include details that the acceleration is presently disabled by default.
05:58.37CIA-14BRL-CAD: 03brlcad * r43774 10/brlcad/trunk/TODO: peformance tested, results very promising
06:00.02``Erikbottie breaks on 32b
06:00.40``Eriktook some work to get a 32b linux build (needs fixing), but it breaks there, too, not just fbsd
06:01.55CIA-14BRL-CAD: 03brlcad * r43775 10/brlcad/trunk/src/librt/primitives/bot/bot.c: since it's disabled by default, is there really any point in requiring normals and orientation? tested on several unoriented and normal-free bots with success too.
06:02.04``Erik(--disable-64bit-build causes failed build on a 64b linux build, -m32 is not being added correctly to src/other)
06:02.22brlcadyep, see README.Linux about that
06:02.58brlcadyou basically have to force it kicking and screaming
06:03.54``Erikheh, had to ./configure CFLAGS=-m32 CXXFLAGS=m32 and then force compile tk and another with /usr/lib/libfonconfig.so.1 instead of -lfontconfig
06:04.25brlcadprobably because you need LDFLAGS-m32 too
06:04.45``Erikno, there is no /usr/lib/libfontconfig.so ... mebbe an arl screwup
06:05.02brlcadprobably, I manually fixed a couple bad X11 libs
06:05.11brlcadbad == missing symlink
06:05.47brlcadeither way, results looking pretty good now
06:05.53``Erikaaanyways, 32b tie crashes where I tried it, I've a lot of mods at work digging into it, but if you wanna dig in, knock yourself out... imma go unconcious
06:06.25brlcadi'm satisfied with it, I'm pressing for release tagging -- one last thing to check on
06:06.51brlcadit was working well enough to put numbers on the gains
06:07.14brlcadt62 is pretty darn close to real-world, it was around 40%
06:07.15``Erikit takes a bit of work to trigger, so whatever... I'm not keen on release notes when it doesn't work 32b, but *shrug* I have more important stuff to worry about
06:07.33brlcadthe notes say it's disabled by default and preliminary
06:07.44brlcadso there can be a future not when it's not off by default
06:09.43CIA-14BRL-CAD: 03erikgreenwald * r43776 10/brlcad/trunk/TODO: note 32b issue for bottie
06:10.21``Eriktomorrow; geomcore.
06:12.16CIA-14BRL-CAD: 03brlcad * r43777 10/brlcad/trunk/TODO: huzzah! .. looks like the nmg failures were related to one of the other failures (probably nmg) because now everything is working again.
07:00.49brlcadtomorrow; tag.
07:00.53brlcader, today
07:46.36*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:28.59*** join/#brlcad epileg (~epileg@188.119.210.222)
08:29.02*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
09:13.01*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:39.23*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
12:51.07*** join/#brlcad Stattrav (~Stattrav@117.192.248.2)
12:51.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:58.10*** join/#brlcad Stattrav (~Stattrav@122.167.250.138)
12:58.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:59.37starseekerreflects that a function to find all local maximums and minimums in a dsp dataset would probably be a good start at more intelligent spline surface generation...
13:16.35*** join/#brlcad Stattrav (~Stattrav@122.167.250.138)
13:16.35*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:22.07*** join/#brlcad Stattrav (~Stattrav@122.167.250.138)
13:22.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:22.30*** join/#brlcad dli (~dli@dsl-173-248-211-229.acanac.net)
13:31.37*** join/#brlcad Stattrav (~Stattrav@122.167.250.138)
13:31.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:42.51*** join/#brlcad Stattrav (~Stattrav@117.192.248.2)
13:42.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:49.34CIA-14BRL-CAD: 03starseeker * r43778 10/brlcad/branches/cmake/CMakeLists.txt: Add some documentation on what the distcheck routine does
13:50.20CIA-14BRL-CAD: 03jordisayol * r43779 10/brlcad/trunk/ (misc/debian/rules sh/make_rpm.sh): change the number of simultaneous jobs on "make", during deb/rpm building process
13:53.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:52.22``Erikhm, dns issues with brlcad.org ?
15:04.18CIA-14BRL-CAD: 03brlcad * r43780 10/brlcad/trunk/misc/Makefile.am: debian/application-x-brlcad.png was replaced with two v4/v5 png files
15:05.30brlcadshouldn't be
15:06.35``ErikI can't resolve from several different machines
15:06.39``Erikincluding bz
15:08.40brlcadworking for me
15:08.55``Erikon bz? tried other machines to avoid cache artifacts?
15:09.06epileg``Erik: not working here in Spain
15:09.33brlcadjust reset named, try again
15:12.08``Erik"no servers could be reached"
15:12.52``Erik(from several different machines using different dns servers, other domains resolve)
15:13.08brlcadwhat query you using?
15:13.19brlcaddoes "nslookup google.com - bzflag.bz" work for you?
15:13.25``Erik"nslookup brlcad.org" and "dig brlcad.org"
15:13.41``Erikyes, that works
15:14.43brlcadoh my
15:14.58epileghere in spain, exactly same as ``Erik
15:15.07``Erikon one machine, I got, um
15:15.17``Erik;; reply from unexpected source: 76.96.5.201#53, expected 68.87.71.230#53
15:15.20``Erikstuff like that
15:15.46brlcadcould be related to zoneedit migration
15:17.00``Erik*shrug* we'll see if it clears up, ah surpose
15:19.16brlcadyeah, NS1.ZONEEDIT.COM is not responding
15:20.05brlcadall three appear to be snookered
15:20.08*** join/#brlcad ezzieyguywuf (~wolfie@cpe-071-070-255-232.nc.res.rr.com)
15:20.12``Erikthey don't have site redundant secondaries? O.o
15:21.29``Erikah, pay per secondary, lame :)
15:22.15``Erikjabs some code for a while
15:23.17brlcadis paying for a secondary
15:23.28brlcadthat's why there's three, one's even in the uk
15:23.37brlcadall three are unreachable
15:23.56``Erikheh, 99.998, guess this is that .002
15:27.29``Erikirssi for noobs lessons *sigh* :D
15:32.51brlcadof 7 dns servers, looks like 5 of them are down
15:35.08brlcader, 13 of 19
15:39.46starseeker``Erik: oh, don't worry - in another 10 years or so I may not be a noob anymore
15:46.01*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:47.03``Erikso'z I gotta enjoy it while I can, right? :>
15:47.21starseekerheh
15:49.10brlcadnote that brlcad.org is still reachable as bzflag.bz (at least for now)
15:50.04brlcadhttp://63.246.136.17/d/ will get you to the website
15:50.19``Erikayup, that's what I did earlier for my comic page, before calling out the dns issue (was poking around to see if the httpd was having issues, if'n ya look at the sudo log)
15:51.13CIA-14BRL-CAD: 03erikgreenwald * r43781 10/geomcore/trunk/TODO: UUID is wired in and QT is gone
15:58.19``Erikhttp://www.youtube.com/watch?v=xQqQ-Kcjowg   "rental car olympics"
16:12.21brlcadheh
16:21.27*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
16:23.08*** join/#brlcad Nohla (~Nohla@64.76.19.227)
16:33.58dlibrlcad, my first try for rt_revolve_xform(), http://pastebin.com/Tf3Qsg7J
16:34.53dlibrlcad, still reading include/rtgeom.h
16:57.27*** join/#brlcad Stattrav (~Stattrav@117.202.21.22)
16:57.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:19.38starseekerO.o
17:25.11starseekerWhat the... I'm seeing warning messages on OSX that are suppressed by adding -Werror
17:34.32starseekerno, that's not it...
17:37.08starseekerAh - it's the presence or absence of STRICT_FLAGS in brlcad_config.h
17:37.48starseekerOhhhhh. I see.
17:38.22starseekerbu.h linen 160
18:05.24CIA-14BRL-CAD: 03starseeker * r43782 10/brlcad/branches/cmake/ (6 files in 5 dirs): (log message trimmed)
18:05.24CIA-14BRL-CAD: Rework how CFLAGS are assigned in CMake. Major changes are using build type
18:05.24CIA-14BRL-CAD: specific flags to hold things instead of the catch-all, and changing the
18:05.24CIA-14BRL-CAD: STRICT_FLAGS brlcad_config.h include to WARNING_FLAGS. The way CMake sets
18:05.24CIA-14BRL-CAD: things up, turning on the warnings but not strict just means you're expecting to
18:05.24CIA-14BRL-CAD: see all the same output without failing. Conditionalizing the bu.h
18:05.24CIA-14BRL-CAD: undef/redefine logic on strict and not warning violated that principle, because
18:18.32CIA-14BRL-CAD: 03starseeker * r43783 10/brlcad/branches/cmake/CMakeLists.txt: Setting linker flags now, not compiler flags
18:20.45CIA-14BRL-CAD: 03starseeker * r43784 10/geomcore/trunk/tests/svntest/main.c: don't do a region subdirectory
18:21.23CIA-14BRL-CAD: 03erikgreenwald * r43785 10/geomcore/trunk/src/utility/GSThread.cxx: destroy the mutex in the GSMutex destructor
18:51.15starseekerbrlcad: I still can't reproduce the rtwizard/archer/bwish issue
19:25.47*** join/#brlcad Nohla (~Nohla@64.76.19.227)
19:45.24*** join/#brlcad Nohla (~Nohla@64.76.19.227)
19:50.52CIA-14BRL-CAD: 03starseeker * r43786 10/brlcad/branches/cmake/ (10 files in 9 dirs): MFC r43785
20:01.18CIA-14BRL-CAD: 03starseeker * r43787 10/brlcad/branches/cmake/src/other/ (13 files in 6 dirs): Ah, right - src/other builds actually have to do their thing properly now. Get tkpng, tktable and tkhtml set up with some find_package calls.
20:12.37CIA-14BRL-CAD: 03starseeker * r43788 10/geomcore/trunk/ (CMake/ CMakeLists.txt cmake/): Do like most other projects and put our CMake modules in a CMake directory
20:21.28*** part/#brlcad epileg (~epileg@unaffiliated/epileg)
20:37.01CIA-14BRL-CAD: 03starseeker * r43789 10/geomcore/trunk/ (3 files in 2 dirs): Make realpath happy on OSX
20:49.58CIA-14BRL-CAD: 03jordisayol * r43790 10/brlcad/trunk/ (3 files in 2 dirs): add an "update gtk icon cache" and some minor improvements on "install" and "remove" scripts of deb/rpm packages
20:59.53*** join/#brlcad dli_ (~dli@dsl-69-171-148-245.acanac.net)
21:01.21CIA-14BRL-CAD: 03bob1961 * r43791 10/brlcad/trunk/src/tclscripts/lib/TkTable.tcl: Added a TkTable::see method.
21:06.09CIA-14BRL-CAD: 03erikgreenwald * r43792 10/geomcore/trunk/src/libNet/NetMsgRouter.cxx: update getListOfHandlers to work correctly with STL maps
21:20.05CIA-14BRL-CAD: 03brlcad * r43793 10/brlcad/trunk/src/libged/gqa.c:
21:20.06CIA-14BRL-CAD: add some error recovery to gqa so that we don't bomb out during
21:20.06CIA-14BRL-CAD: bu_malloc/bu_calloc when passed a zero size allocation. probably means
21:20.06CIA-14BRL-CAD: something earlier went awry but check here regardless so we can be more graceful
21:20.06CIA-14BRL-CAD: about halting.
21:20.29starseeker``Erik: that's got it, thanks!
22:34.36CIA-14BRL-CAD: 03starseeker * r43794 10/geomcore/trunk/tests/svntest/main.c: Put each geometry object into its own directory.
22:39.03starseekerbrlcad: about 50 seconds when I put each object in its own directory (regions and assemblies)
23:10.30CIA-14BRL-CAD: 03starseeker * r43795 10/brlcad/branches/cmake/include/bu.h: Go ahead and keep the old comment
23:13.47CIA-14BRL-CAD: 03starseeker * r43796 10/brlcad/trunk/ (configure.ac include/bu.h): STRICT_FLAGS -> WARNING_FLAGS - just a rename as far as autotools is concerned, no behavior change
23:45.26CIA-14BRL-CAD: 03starseeker * r43797 10/geomcore/trunk/src/GS/ (9 files): First step of renaming geoclient and geoserv to geomclient and geomserv
23:47.36CIA-14BRL-CAD: 03starseeker * r43798 10/geomcore/trunk/src/GS/ (geomclient.cxx geomserv.cxx): geoclient and geoserv renamed to use geom prefix - sounds less like geospatial related software
IRC log for #brlcad on 20110309

IRC log for #brlcad on 20110309

00:00.55CIA-14BRL-CAD: 03brlcad * r43799 10/brlcad/trunk/TODO: add a couple tasks I've had squirreled away for a couple years, visualization requests from external application devs
00:01.17``Erikwait, what? we're not making map software?
00:01.39starseeker``Erik: yeah, yeah... it was bothering me
00:02.29starseekeralthough come to think of it, whadya bet there's something somewhere out there called geoserv?
00:03.16``Erikquite a bit, it'd seem
00:04.26starseekeryou're kidding - no one grabbed it?
00:04.41``Erikthere's a company, a .org, a lot of GIS stuff, ...
00:16.47*** join/#brlcad ibot (~ibot@rikers.org)
00:16.47*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release prep for 7.18.2 under way (20110202)
00:21.51CIA-14BRL-CAD: 03starseeker * r43804 10/geomcore/trunk/TODO: Add some notes and thoughts about immediate next steps to the TODO for geomcore
00:24.42brlcadlooks like DNS is restored
00:26.42starseekeryep - sweet
00:26.49``Erikshould probably have unified test output and a shell script to fire them all off and make a dashboard
00:27.09``Eriklet's do it in xml... wrapped in couchdb... :D
00:27.15starseekerheh
00:27.31starseekerreally should look at CDash
00:28.09starseekerespecially for geometry service, it's output would be a nice "ooo, shiny" progress report
00:32.44CIA-14BRL-CAD: 03starseeker * r43805 10/geomcore/trunk/ (doc/ docs/): docs->doc
00:48.07CIA-14BRL-CAD: 03starseeker * r43806 10/geomcore/trunk/ (. doc/Doxyfile doc/Doxyfile.in doc/docbook/):
00:48.07CIA-14BRL-CAD: Nifty tweak for doc directory - although it's early to be thinking along the
00:48.07CIA-14BRL-CAD: lines of docbook, set up an svn:externals property to pull the xsl sheets and
00:48.07CIA-14BRL-CAD: any other resources from BRL-CAD's doc/docbook directory, instead of duplicating
00:48.08CIA-14BRL-CAD: them in geomcore. Also rename Doxyfile - that will need to have some hardcoded
00:48.08CIA-14BRL-CAD: paths replaced with CMake variables.
00:48.58brlcadzoneedit was hit was a DDoS earlier, hence the downtime
00:49.47brlcadscript is chugging along .. :)
00:54.23``Erikhow goeth account migration?
00:54.56``Erikslaps on his booties and heads into town O.o
00:55.07brlcadrelease bugs
00:55.46brlcadhave taken six days longer than expected now, so a bit backed up
00:56.17CIA-14BRL-CAD: 03starseeker * r43807 10/geomcore/trunk/doc/doxygen/: add doxygen dir
00:59.31CIA-14BRL-CAD: 03starseeker * r43808 10/geomcore/trunk/doc/ (Doxyfile.in doxygen/CMakeLists.txt doxygen/Doxyfile.in): Add a CMakeLists.txt file for doxygen building
01:07.38CIA-14BRL-CAD: 03starseeker * r43809 10/geomcore/trunk/ (CMakeLists.txt doc/CMakeLists.txt doc/doxygen/Doxyfile.in): Add some logic for doxygen building - dunno if it works yet
01:12.31brlcadinitial stats coming in on the raw filesystem overhead
01:14.57brlcadcreating 526 dirs takes approximately 1.25 seconds
01:15.16CIA-14BRL-CAD: 03starseeker * r43810 10/geomcore/trunk/tests/svntest/CMakeLists.txt: May need TCL_INCLUDE_DIRS for svnTest
01:15.42brlcadkeeping all objects in havoc above and at region is approximately 62 seconds
01:16.44brlcadfile size expands from 576k to 2420k
01:20.50brlcadof those 62s keeping geometry, 60s comprised overhead time reinvoking mged and re-reading the .g file -- so the actual keep operation (create file, traverse tree, write to file) is only about 2s of time
01:21.32CIA-14BRL-CAD: 03starseeker * r43811 10/geomcore/trunk/doc/doxygen/ (CMakeLists.txt Doxyfile.in): Exclude src/other. Doxygen generation works now for geomcore, but turned off by default.
01:22.06starseekerhuh - so maybe I am doing something wrong with the svn stuff
01:22.18brlcador svn overhead is just that much
01:24.05brlcadov the 60s spend reinvoking mged and re-reading the .g, approximately 56s is spent reinvoking mged .. so about 4s to read the .g 526 times
01:24.37brlcadundoubtedly cache'd fs data making that fast
01:25.10*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
01:25.51brlcadtakes approx 0.05s to open, read all 526 .g files, and cat them together
01:29.00brlcadinterestingly, havoc.g: 586k, uncompressed into dirs: 2420k, reconstituted into single .g: 870k
01:29.41CIA-14BRL-CAD: 03starseeker * r43812 10/geomcore/trunk/doc/doxygen/CMakeLists.txt: Whoops, add the headers to the party
01:30.43brlcadthat model apparently has a decent amount of sub-region reuse going on to cause a 42% expansion
01:30.58brlcadso it'll be a good test case later too
01:34.26brlcadand I think that's about all we need to know for now.. the best case overhead is going to be about 3s-4s to do a round-trip dir breakout, traverse tree, write out objects, read them back in, and recreate .g -- the rest is overhead elsewhere
01:35.05starseekernods - cool
01:35.12brlcadconsidering the vast majority of that 4s is only during import with <1s during export, that sounds entirely reasonable
01:37.46brlcadfor anyone else looking to play with a .g break-out, this script will do the trick:
01:37.51brlcadfile=whatever.g ; for i in `mged -c $file search / 2>&1 ` ; do obj="`basename $i`" ; reg="`mged -c $file search $i -type r 2>&1`" ; if test "x$reg" = "x$i" ; then echo "mkdir $obj" ; echo "mged -c $file keep $obj/${obj}.g $obj" ; elif test "x$reg" = "x" ; then echo "# skipping $obj" ; else echo "mkdir $obj" ; echo "mged -c $file keep -R $obj/${obj}.g $obj" ; fi ; done | tee doit.sh
01:38.48brlcadfrom there you can sh the script or cat the mkdirs to a new script or count regions, non-regions, skipped sub-objects, etc
01:39.00brlcadhugs search
01:40.06brlcadand if I'd had a newer install on hand, I could have skipped the silly "basename $i" with 'search .' instead of 'search /'
01:46.07starseekerexcept those no-arg search requests are still busted...
01:46.30starseekerthere's some subtlty there I haven't figured out yet
02:02.08brlcadactually, "search /" that I'm using there works just fine with 7.16.10
02:02.30starseekernods - I know, the new setup broke it
02:02.33brlcadso I'd wager it's some new checks for args you've added
02:02.57brlcadmaybe a simple check that just needs to be removed, or an off-by-one argc
02:03.00starseekerthere's something more to it than that
02:03.20starseekerI passed in a null argv, and got some kind of crash
02:03.35starseekerin the paren squish logic, if memory serves
02:03.45starseekerhaven't had time to hunt it down
02:03.48brlcadok
02:04.01brlcadruns away
05:49.55brlcadstarseeker: curious changes to the WARNING_FLAGS/STRICT_FLAGS for the attr params -- is strict vs warning compilation options in cmake dependent or independent on each other?
05:51.18brlcadin autotools, the two options are dependent so you can have warn but not strict, warn and strict, not warn and not strict, or not warn and strict
05:52.55brlcadthat change on the cmake branch looked like it made 'warn and strict' not possible (because our own bu_log cannot compile with the attr warnings, but we want attr warnings for stdio functions (the warn and not strict case) so they can be fixed
05:54.11brlcadof the four cases, warn+strict is the most important to make default since it keeps things the most clean, but that's where the printf-attr warning becomes problematic
06:02.37*** join/#brlcad Stattrav (~Stattrav@117.192.242.239)
06:02.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:05.50*** join/#brlcad Stattrav_ (~Stattrav@122.167.250.138)
10:53.00*** join/#brlcad Stattrav (~Stattrav@122.172.4.189)
10:53.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:13.17starseekerbrlcad: um... warn + strict should be the default
12:14.00starseekerbrlcad: you can have all four combinations with cmake too
12:14.29brlcadexcept by tying attr_format123 to warnings, that should stop the build
12:14.41starseekeruh... how?
12:14.46starseekerOH
12:14.59starseekermy definiton of warning and strict are probably slightly different
12:15.11starseekerin cmake, struct is JUST -Werror
12:15.49brlcadand your warnings probably doesn't include -Wformat
12:15.55starseekerchecks
12:16.02starseekerI believe it does
12:16.43starseekerIt's part of Wall
12:16.47starseekerchecks gcc docs
12:16.50brlcadthen it should halt the build :)
12:17.06starseekerwithout Werror, it's just a warning
12:18.05brlcadour own print-style functions (e.g., bu_log()) declare themselves to be printf-style functions, so some versions of gcc recognize that and validate the arguments against the format specifier
12:18.27starseekerright - that was happening on the mac as a warning with -Wall (not an error)
12:18.45brlcadwhich is fine and dandy for all the stdio functions, even fine for most of our functions, except where we've extended the format specifier and added %V, which will kick off a warning
12:19.18brlcadso our own bu_log() statements will issue a warning where we don't want one, halting the build if strict is enabled
12:19.28starseekerare you expecting -Wformat, on its own without -Werror, to error out in the case of bu_log?  Because that's not the behavior I saw
12:19.37starseekerright
12:21.14brlcadthat's a bad thing :)
12:21.37starseekerUh... why?  -Werror makes it hault
12:21.48starseekerwithout -Werror, it's just informative
12:21.55starseekerI thought it made sense
12:22.07brlcadI don't think you're seeing the issue yet
12:22.42brlcadwe want strict+warning to be the default, yes?
12:22.51starseekeryes - it is
12:23.15*** join/#brlcad Stattrav_ (~Stattrav@122.172.4.189)
12:23.39brlcadif warning implies Wformat warnings, which it should, then Wformat will issue warnings on our exisiting bu_log() calls
12:24.02starseekerbut we don't want that and never will
12:24.02brlcadas currently written, warnings that cannot be quelled because we have no way to tell gcc about %V
12:24.36brlcadwe don't want that, but gcc is going to give us that because we turn on Wformat
12:24.40starseekerright - the STRICT_FLAGS trick quelled them for strict builds
12:26.15brlcadand now they're toggled based on whether warnings are on/off, yes?
12:26.27brlcad(in cmake branch)
12:27.15starseekerthe workaround in bu.h for -Wformat is toggled ONLY when the warnings themselves are on, independend of whether STRICT is also specified (i.e. whether -Werror is added to the mix, which is all STRICT does in CMake)
12:27.22brlcadthey being the attr_format attributes in particular
12:27.49starseekerin CMake, STRICT doesn't duplicate the WARNING flags the way configure.ac does
12:27.55brlcadI get that Werror is all strict is, that's fine and entirely expected
12:28.17brlcadthe issue is whether the warnings settings turns those attributes on/off
12:28.49starseekerdon't we always want them turned off anytime -Wformat is there, regardless of whether we're strict or not?
12:28.50brlcadif attribute is on when warnings is on, then warnings+strict won't be possible (because gcc will issue warnings where we use %V)
12:29.23starseekerright
12:29.25brlcadif attribut is off when warningsa is on, then nowarn+strict won't be possible (same issue)
12:30.33starseekernow you've lost me - if attribute is off, then why does nowarn+strict fail?
12:30.43starseekernowarn+strict doesn't include -Wall
12:31.08starseekerit does in autotools, but not in cmake
12:32.32brlcadmaybe that's the distinction, because there's two types of "no warn" in the autotools build
12:32.44starseekeroh, there are?
12:33.19brlcad--enable-warnings turns on "extra" warnings
12:34.13brlcadso let me understand this, the ATTR_FORMAT* defines -- you have them getting turned on/off when?
12:35.07starseekerOK - there are two compiler related options in CMake that impact this
12:35.28starseekerBRLCAD-ENABLE_COMPILER_WARNINGS and BRLCAD-ENABLE_STRICT, defined in misc/CMake/CompilerFlags.cmake
12:36.01starseekerCOMPILER_WARNINGS turns on Wall, Winline, etc. but does not include Werror
12:36.19starseekerso the compile will blather like crazy but not error out
12:36.51starseekerIf you set BRLCAD-ENABLE_STRICT, it will make sure BRLCAD-ENABLE_COMPILER_WARNINGS is set to ON and then add -Werror to the party
12:38.36brlcadsure, all sounds how I thought -- it's boils down to those attribute flags, when are they turned on/off?
12:39.07brlcadare they coupled to ENABLE_COMPILER_WARNINGS or ENABLE_STRICT ?
12:39.13brlcadpresumably the prior?
12:39.37brlcadand are they toggled on when ENABLE_COMPILER_WARNINGS is 'on' or 'off'?
12:41.16starseekerthe attribute flags are toggled on when ENABLE_COMPILER_WARNINGS is off (i.e. -Wall is not present)
12:41.22starseeker(sorry, network hickup
12:42.15starseekerif ENABLE_COMPILER_WARNINGS is on, we've got -Wall and we're going to get complaints about %V
12:42.23starseekerso we want the attribute flags off
12:43.06starseekerwhen ENABLE_STRICT is on, ENABLE_COMPILER_WARNINGS is also on, so they're off then too
12:45.51starseekerin bu.h, we're keying off the warning flags because they contain -Wall, but it has the same effect as keying off of STRICT because STRICT always turns on Warnings
12:46.27starseekerthe benfit to doing it this way is that when Warnings are on but STRICT is off, we still don't want the %V reports
12:46.45starseekerand this gets rid of them
12:47.57starseekerbrlcad: I didn't really change the behavior from autotools that much
12:48.31starseekerI'm just suppressing the %V error reporting in one additional case
12:52.06starseekerI suppose ideally the thing to do would be to check for -Wall or -Wformat in the compiler flags after configure and key off of that as to whether or not to enable/disable the ATTR_FORMAT* stuff
12:52.29brlcadbasically it sounds like it's suppressing ATTR_FORMAT* entirely then, yes?
12:52.40starseekeryes, except when warnings are off
12:53.24starseekerI was getting an unexpected behavior on the Mac of getting warnings without STRICT on that disappeared when I turned on STRICT
12:53.27brlcadthey're on when warnings are off, they off when warnings are on, so they have no effect
12:53.59starseekerthey're on when the additonal warnings we supply are on
12:54.12starseekerany warnings gcc or CMake's default flags put in there are still present
12:54.34starseekersorry - they're OFF when our additional warnings are ON
12:55.20starseekerif by off we mean the %V warnings are suppressed
12:56.11brlcadI think "STRICT always turns on Warnings" might be a key distinction, is that true or is strict only -Werror? :)
12:56.43starseekerRight now, STRICT will kick on the extra warnings
12:56.52starseekerit does not have to be that way
12:57.00brlcadwill turning off warnings turn off strict?
12:57.26starseekerHmm... I don't believe so
12:58.04starseekerbut turning off warnings with strict on won't work, because strict will catch it and turn them back on
12:58.32brlcadto be continued then.. the overarching issue is this:
12:58.50starseekerthe logic flow is in misc/CMake/CompilerFlags.cmake
13:00.31brlcadwe want the ATTR_FORMAT warnings to be reported for a bu_log calls, but we also want verbose warnings and strict all of the time (and by default) ... so there's a whole category of warnings that we can't enable when strict is on because our own code will trip them
13:00.58starseekerright
13:01.33*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
13:01.34brlcadif there's a way for the format warnings (on bu_log) to be issued whenever strict is off (ideally when warnings are on), then we should be fine
13:02.12starseekerOh... you DO want to see the %V warnings if strict is off?
13:02.20starseekerfound that a serious distraction
13:02.48brlcadonly because I fixed the 100's of other valid warnings that provided by adding it
13:03.20starseekerthen what about adding -Wno-format to STRICT?
13:03.30brlcadbecause we want Wformat for stdio calls
13:03.37starseekerhmm
13:04.17starseekervalid warnings in bu_log functions?
13:04.26brlcadyep, tons of them
13:04.42brlcadthere was just that one niche that couldn't be quelled
13:05.01brlcadso it's good to have reported otherwise they won't get fixed
13:05.09brlcadit just can't be a build stopper
13:05.23brlcadthat's why it only toggled off with strict
13:06.06starseekerwhat about adding -Wno-error=format
13:06.15starseekerto just the strict build
13:06.34starseekerthen strict and warning outputs will be consistent
13:06.41brlcadthat still turns off stdio format warnings being errors, and they're more problematic than our bu calls
13:06.52brlcadmight be fine
13:07.12starseekerwhat threw me was the warnings being more verbose on just warning than on strict
13:07.21starseekeri'd rather the warnings still be present in strict
13:07.52brlcadbut therein they fundamentally can't unless ATTR_ is always disabled
13:08.01brlcadit's either reporting for our bu funcs or it's not
13:08.24starseekerso the risk of Wno-error=format is that it won't hault on non-bu_log specific errors?
13:08.34starseekerand hence we ignore them
13:08.40brlcadright
13:09.24starseekerwe're paying a high price for %V - is it really that useful?
13:09.37brlcadI *really* just want some way to tell the compiler about %V :)
13:10.50brlcadI think it is -- that's a lot of bu_vls_addr() calls that make reading bu_log statements long and messy
13:11.09starseekerwhat about some kind of macro?
13:11.20brlcado.O
13:11.45brlcadcrap, late .. to be continued :)
13:11.55starseekerk, gotta get moving myself
13:12.02starseekerI'll put it back
13:13.45CIA-14BRL-CAD: 03starseeker * r43813 10/brlcad/trunk/ (4 files in 3 dirs): Sigh. %V is a pain, but we do want the warnings if -Werror isn't around.
13:16.05CIA-14BRL-CAD: 03starseeker * r43814 10/brlcad/trunk/src/librt/ (search.c search.h): yipe, stray librt/search code got sucked in by mistake
13:17.44starseekergah!
13:17.55starseekerwhat'd I do to search
13:20.53CIA-14BRL-CAD: 03starseeker * r43815 10/brlcad/trunk/src/librt/ (search.c search.h): Whoops, looks like I only committed the global variable removal to cmake branch. Silly me.
13:30.18CIA-14BRL-CAD: 03starseeker * r43816 10/brlcad/branches/cmake/ (8 files in 5 dirs): (log message trimmed)
13:30.19CIA-14BRL-CAD: MFC r43815, put STRICT_FLAGS back where it was - apparently the presence of %V
13:30.19CIA-14BRL-CAD: warnings only in non-strict builds is expected - we want to see other bu_log
13:30.19CIA-14BRL-CAD: related warnings that are valid, and cannot separate the wheat from the chaff
13:30.19CIA-14BRL-CAD: when it comes to the error reporting, so we have to make that tradeoff in order
13:30.19CIA-14BRL-CAD: to add -Werror. This is very unfortunate since it means a strict build isn't
13:30.20CIA-14BRL-CAD: sufficent to catch all valid warnings and a NON-strict build is also required
13:34.36*** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net)
13:52.31starseekerbrlcad: ok, so a macro probably isn't workable/useful
13:53.20starseekerwhat about having bu_log accept %s for a VLS and a normal string, and then checking which it is on the backend and doing the right thing?
13:57.58starseekercouldn't it check the vls_magic to identify whether the input was a vls or not?
14:06.39CIA-14BRL-CAD: 03starseeker * r43817 10/brlcad/branches/STABLE/ (565 files in 146 dirs): Sync STABLE to trunk r43816
14:06.52starseekerah, fairly painless - phew
14:07.02starseekerheads in
14:21.23brlcadawesome, thanks!
14:21.27brlcadtests
14:36.52*** join/#brlcad Stattrav (~Stattrav@117.192.137.140)
14:36.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:36.54*** join/#brlcad Stattrav_ (~Stattrav@117.192.137.140)
15:25.10dlomananyone else having issues with the cmake brlcad branch?
15:36.29*** join/#brlcad Nohla (~Nohla@64.76.19.227)
16:00.34CIA-14BRL-CAD: 03davidloman * r43818 10/geomcore/trunk/src/GS/GSCmdLineClient.cxx: Cmd line parsing is adding an extra element to the end of the std:list. Pop it off prior to passing list to cmd processor.
16:01.53CIA-14BRL-CAD: 03davidloman * r43819 10/geomcore/trunk/src/GS/GSCmdLineClient.cxx: Remove the debug printer
16:09.02brlcadstarseeker: 43814 reverted the removal of the librt global too
16:09.17brlcadahh, you caught, never mind :)
16:10.28CIA-14BRL-CAD: 03davidloman * r43820 10/geomcore/trunk/src/GS/GSCmdLineClient.cxx: Since the cmd was copied from the front of the stack, pop off the first element prior to passing to the cmd processor.
16:12.47dlomanlooks like thats the last of the qt ripout bugs....
16:22.15starseekerdloman: what's the issue with the cmake branch?
16:23.01dlomanduring config, it was failing when 'trycompile'-ing the base types like int and short and long
16:23.12starseekerO.o
16:23.17starseekerwhat platform?
16:23.26dlomani verified (via the brlcad trunk) that i actually had that support :)
16:23.30dlomanubuntu 10.10
16:23.36starseekeris this a new failure?
16:23.41dlomanlemme get the specific failure.
16:23.44dlomanyeah
16:23.55dlomanworked fine last time I compiled (...firday i think)
16:23.59dlomanerr friday
16:24.03starseekerprobably has something to do with the cflags rework, but that's a bit surprising
16:26.21dlomanstarseeker: http://pastebin.com/FsMdxkuP
16:26.31dlomanyeah, it was rather odd, imho
16:26.46dloman"Wait, I don't have an int anymore? WTF.."
16:27.25starseekerdloman: I can't see that - can you try  pastebin.mozilla.org?
16:27.59dlomansure thing.
16:28.12dlomanis there a 'paste bin of choice for BRLCAD-ers' ?
16:28.40starseekernot really - I think the bzflag one was taken down a while ago, so usually the lisp or the mozilla one get used
16:29.56dlomanhttp://pastebin.mozilla.org/1140041
16:31.09starseekerdloman: is that a clean build dir?
16:31.17starseekeri.e. a clean cmake run?
16:31.29dlomanyuppers!
16:31.41dlomanlemme svn up, nuke and redo one more time.... justincase
16:31.44starseekerwhat's you're cmake line?  
16:31.54starseekercmake ../brlcad-cmake or some such?
16:32.10starseekers/you're/your
16:32.40dlomaninteresting....
16:32.48dlomanon the SVN UP
16:33.03dlomanit told me it 'restored' src/other/zlib/zconf.h
16:33.08dlomanthat normal?
16:33.09starseekerthat's expected
16:33.13dlomankk
16:33.28starseekerzconf.h needs to not be present for CMake but must be present for autotools
16:33.29dloman...so something is altering the src tree?  isn't that naughty?
16:33.54starseekeruntil we're not building autotools anymore, it has to stay in the repository - so CMake gets rid of it for a cmake build
16:34.05dlomankk
16:34.20dlomanfyi the cmake line is:  cmake ../brlcad-cmake/
16:34.29starseekeryes, it's naughty - I don't like it, but as long as we need both autotools and cmake support there's not much I can do
16:34.35starseekerk
16:34.37dlomanjust did a clean checkout, clean build.  same error.
16:35.02starseekerhmm
16:35.14starseekerit wants TERMLIB...
16:35.22dlomanin classic Chris Farley:  "What'd you DO?!?!"
16:35.27dloman=P
16:36.51starseekerdloman: can you post... one sec...
16:37.24starseekerwell, for starters, can you post the full build log from cmake../brlcad-cmake to failure?
16:41.16dlomanconsole capture or is there a specific log file you want?
16:41.44starseekerconsole capture for starters
16:41.49starseekermay need something more specific
16:42.03dlomanhttp://pastebin.mozilla.org/1140086
16:42.40dlomannice. malloc failure.  turns out i really dont have 1.76TB of ram... hrm...
16:42.46dlomandebugs
16:43.57starseekerdloman: do you have a CMakeError.log file in CMakeFiles?
16:46.32dlomanlemme look
16:47.10dlomanyup. u want?
16:47.17starseekerplease
16:47.19CIA-14BRL-CAD: 03starseeker * r43821 10/geomcore/trunk/include/ (5 files): Don't think they're in the right places yet, but start putting some of the docs into doxygen comments.
16:47.33starseekerTERMLIB needs to be defined, and it isn't
16:48.24dlomanhttp://pastebin.mozilla.org/1140101
16:52.27starseekerummm.
16:52.30starseekerweird
17:23.25CIA-14BRL-CAD: 03starseeker * r43822 10/brlcad/branches/cmake/src/other/ (4 files in 4 dirs): Ah, that was where the extra m64s were coming from - don't use FORCE when setting CFLAGS. Tcl/Tk build logic needs a revisit
17:29.52starseekerdloman: by the way, geomcore should generate doxygen docs for you now with "make doxygen"
17:47.52CIA-14BRL-CAD: 03starseeker * r43823 10/geomcore/trunk/doc/URL_URI_URN: Add examples for url type requests
17:55.36*** join/#brlcad _psilva_ (~psilva@12.160.193.229)
18:01.09starseekerProgram received signal EXC_BAD_ACCESS, Could not access memory.
18:01.09starseekerReason: KERN_INVALID_ADDRESS at address: 0x746e6575
18:01.20starseeker0x0018572a in ControlledThread::start (this=0x6024e0) at geomcore/src/utility/ControlledThread.cxx:40
18:01.27starseeker40              bool preRetVal = this->preStartupHook();
18:07.42*** join/#brlcad _psilva (~psilva@static-96-255-52-7.washdc.fios.verizon.net)
18:34.51*** join/#brlcad ezzieyguywuf (~wolfie@unaffiliated/ezzieyguywuf)
18:53.44``Erikheh http://games.slashdot.org/story/11/03/09/1546225/Cloud-Gaming-With-Ray-Tracing
19:52.15*** join/#brlcad Ralith (~ralith@d142-058-095-082.wireless.sfu.ca)
19:59.40*** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
22:20.46*** join/#brlcad dli (~dli@132.205.216.62)
22:27.19*** join/#brlcad yukonbob (~bch@20-144.wireless.kamloops.net)
23:01.56CIA-14BRL-CAD: 03starseeker * r43824 10/brlcad/trunk/src/libged/red.c: Bah. Windows complicates our matching - need to allow for carriage returns as well as newlines. This exposes other problems, as apparently red was never able to successfully parse a Windows text file.
23:02.54starseekerthe regular expression matching is failing on Windows on the last item before the end of the file - it's almost as if it doesn't recognize that it needs to stop
23:03.20starseekerdunno if that's regex, the bu_mapped_file, or what
23:38.01starseekerit's suggestive that the debugger in windows didn't know how to print the last line cleanly but the one on Mac does print cleanly (i.e. no trailing garbage after the last comb tree entry)
23:45.04*** join/#brlcad Ralith (~ralith@d142-058-095-082.wireless.sfu.ca)
IRC log for #brlcad on 20110310

IRC log for #brlcad on 20110310

00:21.21starseekerprobably shouldn't need this but wants to read it anyway: http://www.amazon.com/Art-Debugging-GDB-DDD-Eclipse/dp/1593271743
00:47.36brlcadstarseeker: did the file have a trailing newline?
00:47.45brlcader, newline+cr
00:48.37brlcadAhh.. ddd ... the first debugger I ever used.
00:48.51brlcadthat was a neat debugger, pretty memory graphs
00:48.59Ralithoo, it has graphs?
00:49.01Ralithinstall
00:49.24brlcadyeah, if you had a linked list, you'd see your memory nodes and how they link together
00:49.59brlcadvery simple ones, but enough to get the idea of what the data is doing
00:50.36starseekerbrlcad: it did, but that shouldn't matter
00:50.40brlcadhttp://v3.sk/~lkundrak/grub2-gdb/ddd-ls.png
00:51.03brlcadstarseeker: so red is still busted on windows?
00:51.14starseekeryes - in fact it never worked
00:51.47starseekerwonders how many white hairs he has racked up due to red...
00:52.18brlcad'never' is a very long time with brl-cad, you sure? :)
00:52.59starseekerwell, the new regex based version never worked
00:53.08brlcadthat I'd believe :)
00:53.21CIA-14BRL-CAD: 03starseeker * r43825 10/brlcad/branches/cmake/src/libged/red.c: MFC r43824
00:53.28starseekerthe regex didn't account for the brain-dead windows approach to line endings, and once we got past that the EOF situation causes a crash
00:54.23brlcadthat's right, you are using some regex extension to match lines right?
00:54.36CIA-14BRL-CAD: 0386.163.157.31 07http://brlcad.org * r2482 10/wiki/Main_Page: /* Getting started */
00:54.37starseekermatch across multiple lines, yes
00:55.26starseekerit LOOKS like regexec is running right off the end of the bu_mapped_file buffer
00:55.32Ralithpretty
00:55.43Ralithand by pretty I mean useful
00:55.55CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2483 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/86.163.157.31|86.163.157.31]] ([[User talk:86.163.157.31|Talk]]); changed back to last version by [[User:Paulcs|Paulcs]]
00:56.01brlcadRalith: :)
00:56.16starseekerwonders if he can convince work to pick up a copy of that book...
00:56.29brlcadddd got its groove on back in the early 90's
00:56.36brlcadhasn't really ever changed unfortunately, lot of potential there
00:57.08brlcadstarseeker: it very well may be running off the end if it's looking for an EOF
00:57.19CIA-14BRL-CAD: 0386.163.157.31 07http://brlcad.org * r2484 10/wiki/Error_Messages: Initial stub
00:57.27Ralithsuddenly SLIME doesn't hold all the cards anymore
00:59.28starseekerterminating with \0 may work too... that's what OSX shows me after the mapped file, anyway...
01:00.03starseekerhad hoped the bu_mapped_file routines would have some kind of guarantee about sanity at the end of the buf, but maybe not
01:04.26brlcadit's just a buffer of data
01:06.13starseekerthen I'm gonna have to do something else with it
01:06.24starseekerbecause on every platform but Windows, regexec knows to stop
01:06.33brlcadnow what could be happening is that on windows, it doesn't have mmap() so bu_mapped_file() is falling back to simple write() calls
01:06.54brlcadand if it was off-by-one, it could leave off the trailing '\0'
01:08.10brlcadyou'd probably not even notice that on code that processed one line at a time
01:11.21starseekerlooks like it used read() to pull it in
01:13.23CIA-14BRL-CAD: 03brlcad * r43826 10/brlcad/trunk/src/libbu/mappedfile.c: make sure the buffers zero-terminate in case the files being mapped do not
01:14.09brlcaddon't know if that'll fix it, but easy enough to test
01:14.16starseekeris on it
01:16.19CIA-14BRL-CAD: 03starseeker * r43827 10/brlcad/branches/cmake/src/libbu/mappedfile.c: MFC r43826
01:18.28starseekeryep, that's got it
01:18.33starseekerbrlcad: thanks!!
01:18.59starseekerwill have to check for other cases were n isn't enough in regex expressions
01:20.42starseekerlooks like red may be the only case...
01:21.31brlcadyour regex doesn't look right
01:21.48brlcad[[:blank:]\r?\n]
01:22.08brlcadpresumably implying \r is optional, but that's not what ? means there
01:22.21brlcadit's a char class
01:22.30brlcad[[:blank:]\r\n]*
01:22.40brlcador [[:blank:]\r\n]+
01:22.56starseekerhmm... wonder why it worked
01:23.08brlcadbecause you're matching a literal '?
01:23.16brlcadexactly once
01:23.32brlcad? or space or \r or \n
01:24.14brlcadseveral places that pattern repeats
01:25.32starseekerah
01:25.41starseekerso I probably don't need the ? then
01:27.35CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
01:27.35CIA-14BRL-CAD: deleted "[[Error Messages]]": there needs to be more purpose than just itemizing
01:27.35CIA-14BRL-CAD: possible error messages coming from brl-cad tools. the one you listed isn't
01:27.35CIA-14BRL-CAD: even exactly an 'error' as it is an explanation why it skips _GLOBAL
01:30.54CIA-14BRL-CAD: 03starseeker * r43828 10/brlcad/trunk/src/libged/red.c: Tweak the regex expressions for carriage return correctness - hopefully that's closer
01:34.08starseekerhas to head out, will try new regex stuff tomorrow
01:34.27CIA-14BRL-CAD: 03starseeker * r43829 10/brlcad/branches/cmake/src/libged/red.c: MFC r43828
01:34.49CIA-14BRL-CAD: 03brlcad * r43830 10/brlcad/trunk/src/libged/red.c:
01:34.50CIA-14BRL-CAD: simplify with the [:space:] character class which already includes newline and
01:34.50CIA-14BRL-CAD: carriage return. [:blank:] is a gnu extension and won't necessarily be
01:34.50CIA-14BRL-CAD: supported for a given vendor regex library. also fix a missed character class
01:34.50CIA-14BRL-CAD: '?' inclusion with the [:space:] swappage.
01:38.45starseekersighs - someday I'll understand regex...
01:38.57CIA-14BRL-CAD: 03starseeker * r43831 10/brlcad/branches/cmake/src/libged/red.c: MFC r43830
01:42.29starseekerhuh - apparently Kitware has a free CDash service:  http://my.cdash.org/
01:43.39starseekerwow http://my.cdash.org/index.php?project=OpenStudio
01:43.41brlcadyep
01:43.49CIA-14BRL-CAD: 03brlcad * r43832 10/brlcad/trunk/src/libged/red.c: semper fi, er, simplify. let things fall through so there is only one copy of the cleanup code and a consolidated simplified return location.
01:44.24starseekerbrlcad: would that serve for a BRL-CAD reporting setup or would we want our own CDash server?
01:44.26brlcadman that looks like ass
01:44.43brlcadI *want* to love cdash .. but that ui is a bit of an eyesore :)
01:44.51starseekerhehe
01:45.06brlcadI'd think we'd still want our own, but still up to whomever does the work in my book
01:45.28starseekerwell, we could always rip off the CruiseControl generated html and teach CDash to output that instead...
01:45.28brlcadthat way we could hook scripting into the loop for custom actions
01:46.00brlcadit is just the reporting front-end, so you still have to have compilation nodes set up and sending in results
01:46.12starseekerright
01:46.18brlcadcruisecontrol is the other one I couldn't remember
01:46.23brlcadbuildbot the third
01:46.36starseekercruisecontrol had the GUI you liked?
01:47.06brlcadhttp://cruisecontrol.sourceforge.net/
01:47.18brlcadit's really easy to use
01:47.55brlcadfeatures neatly grouped together with simplified reporting, then options to dive into more detail or even raw build logs only when you ask for it
01:47.57CIA-14BRL-CAD: 03starseeker * r43833 10/brlcad/branches/cmake/src/libged/red.c: MFC r43832
01:48.19starseekerhmm... guess we could use their exec builder to fire off cmake
01:48.49CIA-14BRL-CAD: 03brlcad * r43834 10/brlcad/trunk/src/libged/red.c: ws cleanup
01:49.38brlcadyep
01:49.49brlcadthough again, strong emphasis on "no strong preference"
01:50.20brlcadif you or anyone else wanted to even just play with a small random pet-project CI system, I'd take no issue
01:50.40starseekeris wary of a tool brlcad doesn't like the looks of (*memories of font discussions and graphical layout issues*)
01:50.53brlcadit's much more important that we have continuous integration than we have "the best"
01:51.21brlcadI'd get used to any dashboard so long as it wasn't a maintenance burden or timesink
01:51.50starseekerwonder where we can run enough virtual machines to hit all the configs and not create a pool of molten metal...
01:51.59brlcadtheir whole purpose is to report failures simply and *quickly* so they get caught as early as possible, so they can get isolated and fixed as early/easily as possible
01:52.06starseekerpity sourceforge took down that server farm
01:52.45brlcadany desktop machine with a few corew would be sufficient enough to crank out a half-dozen builds an hour
01:53.24starseekerdynamic lib only and no docs, maybe...
01:54.07starseekerunless maybe virtual machine overhead is lower these days than I remember
01:55.04brlcadanything that can presently compile the package in less than 10 minutes should be sufficient
01:55.37starseekerwonder if we could prepare stripped down virtual box/qemu images set up to build BRL-CAD and report, then set them up as downloadable goodies for people who want to pile in and and automatically test... setiathome for BRL-CAD :-P
01:56.29brlcadat worse, you get another box or two or have different types of test builds -- quick fast simple reduced builds across everything on one box, then a more extensive slower build box that runs the full regression, docs, bench, etc at a slower rate
01:57.00brlcadheh, I'm not sure that'd be useful :)
01:57.16brlcadif it was a vm image, we'd get tons of reports testing the exact same thing
01:57.35starseekerwell, we wouldn't need hundereds of testers - but we could have a list of "images we need testing and need volunteers for"
01:58.06brlcadbetter would be a build target or even a shell script that took a given checkout or source tarball through all the paces, and reported back
01:58.35brlcadso we could basically get a report anytime someone tried to build
01:58.48starseekerthat'd be configuration explosion though
01:59.02brlcadsure, so? :)
01:59.07brlcadentries in a db is all
01:59.17brlcadwe hit up the most common failure reports
01:59.28brlcadtill there are none
01:59.32starseekerthat sounds a bit different than cruisecontrol/cdash...
01:59.44brlcadthey'd report to cc/cd
02:00.04starseekerI got the impression cc/cd didn't know the details about the machine/os/etc...
02:00.12starseekermaybe I didn't look close enough
02:00.48brlcaddoesn't really have to know, it just has to send in results -- we could easily put machine details into a log that is sent back
02:00.56brlcadbenchmark suite does exactly that now
02:01.05starseekernods
02:01.18brlcadspeaking of such
02:01.40brlcadwe're going to have to really kick in gear things into gear thursday if gsoc app is going to happen
02:01.58starseekerah, we're coming up on the deadline?  OK
02:02.10starseekerhunts for the wiki page with project ideas
02:02.16brlcaddeadline is friday mid-day
02:02.35brlcadit'll take me a couple hours to write up the application submission
02:02.50starseekerk - what do you need me to do firstist and mostist?
02:02.57brlcadfew hours for someone to work up a (VERY) detailed project ideas page
02:03.43brlcadthey gave feedback in '09 that our ideas page needed a lot more ideas and detail (but that they were going to accept us anyways)
02:03.48starseekerupdate http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas  or start over?
02:04.07starseekers/update/expand upon
02:04.18brlcadI'd start with http://brlcad.org/wiki/Google_Summer_of_Code/, update any references to dates/times/requirements
02:04.31brlcadadd new section for 2011 where there are dated sections
02:04.46starseekerright
02:05.22brlcadthe project ideas page for 2008 was moved to http://brlcad.org/wiki/Google_Summer_of_Code/2008/Project_Ideas
02:05.43brlcadso can do the same for 2009 and either start a new http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas or expand on it
02:06.30brlcadI think we should strongly de-emphasize projects that let devs code alone like we've had in the past
02:06.30starseekerthey wanted MORE ideas?? we've got quite a few here
02:06.38brlcadyeah, ironic, eh?
02:07.17starseekerso, no going off in the corner and working on iges or step?
02:07.33brlcadwe get compared against other big-boys, they expect more
02:07.36brlcade.g., http://www.freebsd.org/projects/summerofcode.html#ideas
02:07.54brlcadfreebsd's whole set of gsoc pages is arranged decently
02:08.06brlcadnotice how those idea links expand to something even more impressive
02:09.16brlcadyeah, ideally not things like iges/step unless they have some exceptional familiarity in that area
02:09.21starseekerbrlcad: they can code almost anything alone if they put their minds to it...
02:09.38brlcadsomething that will make them explore the code better, reuse, refactor, integrate
02:10.06brlcadthe only project that might be an exception would be continuation of new gui
02:11.06starseekernods... I'll do my best...
02:11.31starseekerwould continuation of the constraints work fall under the integrate category or the isolated category?
02:12.54starseekercrud - I've gotta get outta here
02:13.30brlcadstarseeker: better example of an "integrated" projects that would benefit us you can add/expand: ogre display manager, qt display manager, qt framebuffer, cross-platform adrt, libged transactions, .. maybe a quick scan down TODO for the bigger tasks
02:13.45brlcadconstraint continuation would be integrated
02:14.14brlcadgoal would have to be something precise like prep or parameters hooked into mged menus, etc
02:15.44brlcadalso need mentors to step up: dloman indianlarry ``Erik louipc yukonbob poolio  or anyone else
02:15.59brlcadsince I'll need your google id again
03:22.13starseekerbrlcad: oh - any opinion on using %s for both strings and vls in bu_log?
03:28.30CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/Project Ideas]] moved to [[Google Summer of Code/2009 Project Ideas]]: Moving old Project Ideas page to a date specific location - time for a new one.
03:38.01CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2487 10/wiki/Google_Summer_of_Code/Project_Ideas: Start layout setup for the new Project Ideas iteration
03:49.01brlcaderp, missing slash
03:51.00CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
03:51.00CIA-14BRL-CAD: deleted "[[Google Summer of Code/Project Ideas]]": content was: 'The list of
03:51.00CIA-14BRL-CAD: possible projects below should serve as a good starting point for new developers
03:51.00CIA-14BRL-CAD: that would like to get involved in working on BRL-CAD. Th...' (and the only
03:51.00CIA-14BRL-CAD: contributor was '[[Special:Contributions/Starseeker|Starseeker]]')
03:51.09CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Google Summer of Code/2009/Project Ideas]]": Deleted to make way for move
03:51.11CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/2009 Project Ideas]] moved to [[Google Summer of Code/2009/Project Ideas]]: consistency with 2008
03:51.42CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2490 10/wiki/Google_Summer_of_Code/2009: refere to old ideas page
03:52.40CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: restored "[[Google Summer of Code/Project Ideas]]": 2 revision(s) restored: hrm, looks like mw or I was confused with a bogus url
03:53.30CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2491 10/wiki/Google_Summer_of_Code/2009: historic ref
03:54.04CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2492 10/wiki/Google_Summer_of_Code/2009/Project_Ideas: historic ref
03:56.34CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2493 10/wiki/Google_Summer_of_Code/2009: past tense
04:00.25CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2494 10/wiki/Google_Summer_of_Code: reword for past tense
04:04.26CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2495 10/wiki/Google_Summer_of_Code: reword for more awesome
04:05.57brlcadstarseeker: my inclination is that would be bad (overloaded behavior, inconsistent, probably more confusing than warnings) and probably wouldn't even work since the compiler is supposed to validate that typeof() is a char* for %s, which it wouldn't be
04:10.17CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2496 10/wiki/Google_Summer_of_Code/2011: stub in for 2011
04:13.37CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2497 10/wiki/Google_Summer_of_Code/Checklist: numbered list
04:14.17CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2498 10/wiki/Google_Summer_of_Code/Checklist: retitle
04:15.28starseekergrowl... so we're permenantly stuck with the %V warnings then
04:16.23starseekerunless we get the gcc devs to add a new feature, and even then it'll only be in the newest gcc versions
04:16.53CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2499 10/wiki/Google_Summer_of_Code/Checklist: regroup for clarity
04:17.44CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2500 10/wiki/Google_Summer_of_Code/Checklist: subtasks don't need to be numbered
04:21.57CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2502 10/wiki/Google_Summer_of_Code: KISS
04:23.14brlcadwonders if dloman would be willing to work up this year's gsoc flyer
04:24.04brlcad( prior examples at http://brlcad.org/wiki/Google_Summer_of_Code#BRL-CAD_participation_in_GSoC )
04:31.58CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2503 10/wiki/Google_Summer_of_Code/Checklist: add deadline dates
04:33.11brlcadthat's about all I can push through for tonight
04:33.18brlcadneed to get back to release
04:33.20starseekernods
04:35.10brlcadthinks we need at least 30 fleshed out ideas, perhaps categorized similar to http://brlcad.org/wiki/Contributor_Quickies
04:35.29brlcad(EASY, MEDIUM, HARD)
04:36.06brlcador Web, C, C++, Tcl
04:36.15brlcadboth
04:36.36starseekerbrlcad: OK... I'm just tossing stuff up right now, I'll sort it once it's more fleshed out
04:36.42brlcadnods
04:37.11brlcadyou can probably utilize the entire 2009 list and just keep adding more, remove the one or two that are no longer relevant
04:38.03starseekeroh - I was starting with the whole "more interactive" thing and was gonna review the 2009 list to see what qualified...
04:39.26CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2504 10/wiki/Google_Summer_of_Code/Project_Ideas: More ideas - this isn't anything like final form, probably - just scratchpad
04:40.30brlcadtypo in the top title section
04:40.45brlcadsure, however you wanna do it :)
04:40.58starseekerthe "AN IDEA" one?
04:40.59brlcadaim for 50, hopefully we'll get to 40 :)
04:41.05brlcad"=."
04:41.17starseekeroh, good eye
04:41.41CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2505 10/wiki/Google_Summer_of_Code/Project_Ideas:
04:41.47starseekerkinda liked FreeBSD's grouping by larger scale topic
04:42.09starseekerI'll take a whack, then you can tell me why it's wrong :-P
04:42.26starseekerbrlcad: did you want to get those red changes into this release?
04:45.59*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
04:56.00*** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net)
04:57.26CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2506 10/wiki/Google_Summer_of_Code/Project_Ideas: list a few more things...
04:58.00CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2507 10/wiki/Google_Summer_of_Code/Project_Ideas: Constraint solver needs its own page
04:58.33CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2508 10/wiki/Geometric_Constraint_Solver: Put description on individual page
05:09.28starseekerbrlcad: do you happen to know whether or not its possible to recognize an arbitrary NURBS surface as being a component of (say) a sphere or a torus?
05:10.30Ralithstarseeker: is BRL-CAD doing SoC this year?
05:10.35CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2509 10/wiki/Google_Summer_of_Code/Project_Ideas: More tasks to flesh out...
05:10.43starseekerwe'll see :-)
05:11.24Ralithif so, will almost certainly submit a GPU accel proposal.
05:18.59CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2510 10/wiki/Google_Summer_of_Code/Project_Ideas: Couple more NURBS ideas...
05:26.26CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2511 10/wiki/Ayam_Editor_Feature_Integration: Toss a few notes into the Ayam/NURBS entry
05:53.25brlcadstarseeker: did someone report red?
05:53.31starseekerVictor
06:06.27CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2512 10/wiki/Google_Summer_of_Code/Project_Ideas: That's around 30 ideas... some work to do tomorrow
06:50.18brlcadRalith: one never knows until orgs are announced
06:51.02Ralithyeah, meant to ask "applying"
06:51.07Ralithand wiki confirms
06:51.44brlcadstarseeker: not definitively unless the surfaces are tagged with originating geometry
06:53.02brlcadRalith: yeah, it looks like we're probably applying if I can get a couple more mentors to sign on
06:53.10Ralithawesome
06:53.32Ralithwould be a great way to spend the summer
06:54.36brlcadRalith: I'd be cautious about a gpu accel project for the same aforementioned "prefer integrated code, minimal 'new code'" concerns -- it'd have to be very specific about how it'd be integrated and beneficial
06:55.35brlcadand from a former gsoc'er, you'll have to work twice as hard to convince
06:56.19Ralithhm, that's a shame
06:57.12brlcadnot really, it's only fair to the 3k other students :)
06:57.21Ralithhah
06:57.23Ralithyeah
06:58.23brlcadif someone had been more actively commiting over the past year and a half, it'd be a totally different story ;)
06:58.24Ralithmay play with it anyway, depending on what else I end up doing
06:58.27brlcadhell, even passively :)
06:59.29Ralithlooks slightly regretful
07:00.08brlcadthe point of gsoc is to get students engaged in open source, even if it's not brl-cad ... http://www.ohloh.net/p/brlcad/contributors/17162689320215 tells a sad story
07:00.45Ralithyes, it's quite true
07:00.51Raliththough I've been plenty active elsewhere
07:00.56Ralithnot sure why ohloh hasn't picked up on that
07:01.10brlcadnot intending to pick on you personally, just saying that puts you back into the boat with everyone else on level standing
07:01.18RalithI know
07:01.30brlcadyou can combine accounts
07:02.07RalithI think most of the projects simply aren't on ohloh
07:02.11Ralithwhich can be remedied, certainly
07:02.37Ralithbut anyway, not too relevant
07:03.24brlcadyeah, the project itself is more the issue, it'd have to be carefully spelled out
07:03.50Ralithnod
07:04.19brlcadfor example, most of the gpgpu research is on accellerating triangle raytracing -- that's just not very interesting any more, especially now that we have our new TIE library integrated with LIBRT
07:04.23Ralithmainly it strikes me as a good opportunity to learn more about raytracing and rt's internals in particular, as well as GPU frobbery
07:04.52Ralithhm.
07:05.03RalithI wasn't aware it was a research area per se
07:05.04brlcadso it'd have to be some other means to accellerate librt, which would be either in the spatial partitioning, the boolean weaving, the primitive evaluations, etc
07:05.14brlcadoh hell yeah, a huge one
07:05.40Ralithisn't raytracing embarassingly parallel across each ray?
07:05.55brlcadnvidia and intel fighting it out, both trying to push gpgpu raytracing into gaming, it's been five years+ in the making
07:06.02brlcadyes?
07:07.06Ralithperhaps I drastically misunderstand the problem, but wouldn't simply mapping rays across GPU compute units—with fairly straight port of the relevant rt code—be a huge gain?
07:07.39brlcadmapping rays to the gpu is trivial, days work
07:07.52brlcadyou have to evaluate and march those rays
07:07.57brlcadagainst geometry
07:08.06Ralithright, I meant mapping the entire process
07:08.48brlcadso how does one evaluate whether a ray intersects with a torus on the gpu?
07:09.00brlcadheck, even a simple sphere
07:09.27brlcadit's doable, but it's not a 1-1 mapping or a mere matter of "porting" anything
07:09.49brlcadyou generally have to completely rethink how data is packed and evaluated
07:10.46RalithI guess it should have been obvious that the hardware is ill-optimized for the subtleties of geometry more complex than triangles.
07:10.49brlcadthat's why most of the research is just with triangles -- only have to deal with one entity type that is very trivial to evaluate, has a fixed constant data size, etc
07:11.10Raliththat sounds a bit beyond what I can accomplish based on what I know, at least in a single summer.
07:11.22brlcadthe hardware isn't even really geared for triangles, but the calculations are so few
07:11.31Ralithwell
07:11.37Ralithsketchy understanding here
07:12.02brlcadyou actually *can* do spheres even easier if you apply the same techniques you apply for triangles, but then a beast like a torus becomes super problematic because it requires a root solver
07:12.03Ralithbut aren't GPUs pretty much all about vector ops, and triangles trivial to work with within those?
07:12.21brlcadyep, that's where fixed data size becomes a win
07:12.30brlcad*small* fixed data size
07:12.43Ralithand the math, surely?
07:12.58Ralithwell, I suppose you just said that
07:13.12Ralithalright, thanks for the explanation; sounds like this was ill-conceived.
07:14.03Ralithan interesting problem to be sure, but I don't have the background to do original work in that sort of thing.
07:14.45brlcadit's a great feature, a great research project, but very non-trivial to say the least -- you'd probably be able to publish in an journal or even siggraph if you got it working for general implicit geometry
07:15.21brlcadeasier attack vector would be accelerating our boolean weaving step
07:15.30Ralithhaven't a clue what that is O.o
07:15.36brlcadexactly :)
07:16.19Ralithah well.
07:16.23brlcadthat's where the "you'd have to work twice as hard to convince" came from
07:16.48brlcadbecause it could take a month just to get schooled up on the background knowledge needed
07:17.08Ralithknowing the scope of the problem, even that seems generous
07:17.18Ralithfor weak values of knowing even now
07:18.06brlcadthat's where if you were already familiar with even the basic mechanics of librt working on portions of the code consistently, that'd make for an easier case to dive into such a hard problem
07:19.30brlcadyou'd know the application structure's purpose, how hit callbacks work, when boolean evaluation is performed, what that means, how the implicits evaluate, types of CSG dag nodes, etc
07:20.22Ralithperhaps continuing jonored's work on a toolpather would be more realistic?
07:20.38brlcadfairly complex code, highly optimized, and critical code at that which would require 100% validation
07:20.49Raliththough I'm not certain of my ability to find a footing with the (as far as I can tell, currently buggy) math there either
07:21.11brlcadwhat toolpather?
07:21.20RalithI suppose he never posted it here
07:21.31Ralithyou recall a while back that he was working on a gcode generator?
07:21.34Ralithcouple years ago or so?
07:21.45brlcadnot specifically
07:21.50*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
07:21.58Ralithhe was, and it got abandoned in favor of his studies
07:22.09Ralithbut I got ahold of him a few months back and got him to send me a tarball of the git repo
07:22.28brlcadI do recall that discussion
07:22.44Ralithhe claims outline tracing is mostly working, though in my limited experiments I've not gotten correct output
07:22.51brlcadthat wasn't based on brl-cad iirc, though, no?
07:23.09Ralither, it uses librt to interrogate BRL-CAD databases
07:23.21brlcadhrm
07:23.22Ralithnot sure how much more 'based on' it gets
07:23.36Ralithwant a look at the tarball?
07:23.55brlcadnot at the moment, but it is interesting
07:23.59Ralithkk
07:24.12RalithI'll see if I can take a better look at it in the coming month and work out what state it's really in
07:26.20brlcadyeah, that was back in january we were talking about it
07:26.28brlcadyou were asking about curvature
07:28.31Ralithyeah, jonored mentioned that torus curvature was the standing bug; I had planned to dive in and fix that if I could get it to behave for simpler primitives
07:28.52Ralithhaven't managed that yet, though haven't put much time in it
07:37.13brlcadif it really is non-gui based (which an old post of his indicated), that would be a good one to get working and fully integrate
07:37.25brlcadbasically a "g-gcode" converter
07:45.21Ralithit is indeed commandline.
07:46.00Ralithin fact it even follows the naming scheme
07:46.01Ralithg2gcode
07:46.08Ralithbear in mind, though, that additive and subtractive toolpaths are differnet beasts
07:46.16Ralithdifferent*
07:57.27*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:58.53Ralithgah.
07:59.14Ralithjournal website lists this article as 'full text available,' but when I log in through my univ it's preview only :|
07:59.42Ralithgunna have to get a physical copy I guess.
08:08.57Ralith(trying to get ahold of Martin Held's "On the computational geometry of pocket machining")
08:21.55*** join/#brlcad Stattrav (~Stattrav@122.167.172.122)
08:21.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:38.38*** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net)
11:16.19d_rossbergi get fringes on ray-tracing cones
11:17.26d_rossberge.g. the havoc's tail (ae 300 0)
13:47.57CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2513 10/wiki/Google_Summer_of_Code/Project_Ideas: add subversion idea
13:55.10starseekerbrlcad: would search exec be a viable GSoC project?
14:45.37CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2514 10/wiki/Google_Summer_of_Code/Project_Ideas: /* BRL-CAD Core Library Enhancement */
14:57.37``Erikcdash is heavily css driven. if it's the look and not the structure, it should be easy to make it less ugly
15:20.32CIA-14BRL-CAD: 03erikgreenwald * r43835 10/geomcore/trunk/tests/utility/threadTest.cxx: programmatically test for functional threading instead of spewing junk to the screen for human analysis
15:21.46starseeker``Erik: you good to mentor?
15:23.06CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2515 10/wiki/Google_Summer_of_Code/Project_Ideas: Couple more line items - that's 38...
15:23.19``Erikyup, msg'd brlcad my id
15:24.34starseeker``Erik: can you scan that list and see if I left out any juicy items?  brlcad was talking about wanting 50...
15:24.55``Erikyeah, I looked over it t his morning, um
15:25.16*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
15:25.17``ErikI'll splat some stuff on and if someone doesn't like it, they can remove it O.o
15:25.25*** join/#brlcad Stattrav (~Stattrav@117.192.159.181)
15:25.25*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:31.44CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2516 10/wiki/Google_Summer_of_Code/Project_Ideas: /* BRL-CAD Core Library Enhancement */
15:32.33CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2517 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Tools */
15:36.03CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2518 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Tools */
15:36.47``Erikis [[NURBS Intersections]] an evaluation of a CSG of NURBS into a single one?
15:37.10starseekerno, that's just the surface/surface problem and related subproblems
15:37.40starseekerI doubt a summer of code student could get all the way to the final evaluated model
15:37.57CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2519 10/wiki/Google_Summer_of_Code/Project_Ideas: 'csg' makes more sense than 'boolean' here
15:38.58CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2520 10/wiki/Google_Summer_of_Code/Project_Ideas: /* BRL-CAD Core Library Enhancement */
15:39.25``Erikhm, can always harvest TODO and http://brlcad.org/~sean/ideas.html for some more
15:39.40starseekernods - I grabbed a few out of there
15:39.49starseekerwas trying to look for things that would be 'integrated'
15:39.53``Erikorange page, too?
15:39.59starseekernods
15:40.20starseekerfor example, I'd worry that a Blender plugin would kinda be off in its own little world...
15:41.01starseekernow if they want to snarf the Blender file import that game kit implemented and turn it into a BRL-CAD importer... :-)
15:41.24``Erika little bit, but it would need a fair amount of communication to figure out how to translate and what functionality
15:42.06starseekernods - well, we've probably got close to enough lined up there - now we need to start filling 'em in
15:42.11``Erikooh, they have one now? last I looked, their format was basically a swizzle of memory dumped to disk
15:42.37starseekeryeah, pretty much - apparently someone figured out how to do something intelligent with it...
15:42.41starseekerone sec...
15:42.55``Erikstarts writing a test for ControlledThread O.o
15:43.06starseekerhttp://code.google.com/p/gamekit/
15:45.15``Erikyeah, saw that before, hm
15:48.18CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2521 10/wiki/Google_Summer_of_Code/Project_Ideas:
16:21.27CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2522 10/wiki/OGRE_Display_Manager: Flesh out OGRE task (I think this is low difficulty?)
16:21.40*** join/#brlcad piksi (piksi@pi-xi.net)
16:45.24brlcadstarseeker: sure, search exec would be viable
16:47.28brlcadmost of the index card tasks are decent gsoc tasks
16:47.33brlcadshould do a quick scan
16:48.12brlcadsince they're < month for us, that easily scales up to 3 months for someone else including communication, reporting, testing, and documentation
17:11.35dlibrlcad, http://paste.pocoo.org/show/351409/
18:36.43CIA-14BRL-CAD: 03erikgreenwald * r43836 10/geomcore/trunk/tests/utility/threadTest.cxx: start stubbing in ControlledThread test
18:41.51CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2523 10/wiki/Qt_Display_Manager: Qt display manager
18:42.31CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2524 10/wiki/Qt_Display_Manager: Qt, not ogre
18:53.59CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2525 10/wiki/Qt_Framebuffer: Qt framebuffer
18:56.07CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2526 10/wiki/Qt_Framebuffer: Grr - framebuffer, not display manager
19:08.51CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2527 10/wiki/Other_Cross_Platform_Framebuffer: Cross Platform framebuffer
19:21.20CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2528 10/wiki/High_Dynamic_Range_Support: HDR output support
19:21.27starseeker``Erik: mind reviewing the HDR one if you have a sec?
19:21.57``Eriksure, um, and I just changed the css to mark the 'new' class as red, so'z you can tell which ones you've done
19:22.11starseekerthanks :-)
19:22.30``Erik(we can revert it once this exercise is over if brlcad wants, it's in RCS)
19:23.12``Erik"There is not fundamental reason" ... wow, right out of the gate :>
19:23.29starseekerheh, sorry - distracted
19:23.35starseeker(house is leaking again)
19:23.50``Erikother than the picasso grammar, looks decent...
19:28.10CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2529 10/wiki/High_Dynamic_Range_Support:
19:40.18CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2530 10/wiki/MGED_to_Archer_Command_Migration: Command migration
20:09.10CIA-14BRL-CAD: 03erikgreenwald * r43837 10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: indent
20:23.33CIA-14BRL-CAD: 03erikgreenwald * r43838 10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: purdee kulurz
21:01.24CIA-14BRL-CAD: 03Markhobley 07http://brlcad.org * r2531 10/wiki/Talk:Error_Messages: wikibook
21:27.22brlcaddli: oh snap
21:27.28brlcadaua he left
21:31.19brlcaddebates trying an application form this year
21:31.34starseekerfor GSoc you mean?
21:31.38brlcadyeah
21:31.49starseekerdoes seem kinda rushed
21:32.14brlcadmany of them just have no idea on how to pitch an idea, so there ends up being a lot of information we have to keep asking for
21:33.35brlcadit has helped in the past to separate out those who HAVE thought through their idea and have a lot to say, but many of those devs tend to have trouble integrating their thoughts with our codebase
21:33.50brlcador worse, the ones that can write great, but can't actually code
21:34.45starseekerhad thought about some basic "submit this code with your application" kinda things, but that takes time to define
21:35.22CIA-14BRL-CAD: 03erikgreenwald * r43839 10/geomcore/trunk/tests/GS/GeometryServiceTest.cxx: more indentation, staticizing, etc
21:35.26starseeker``Erik: what's your take?
21:35.55``Erik*shrug*
21:36.33``Erikwe tried "submit a patch" a couple years back, seems it was a bit of a pain
21:37.15starseeker``Erik: should we rush to get it "ready" or punt until next year?
21:37.47brlcadsubmit a patch worked pretty well I thought -- the strong patches ended up being the strong coders
21:38.09brlcadkept the application count down, but I think it worked
21:38.23``Erikthe weak patches were a depressing time sink, though :)
21:38.41brlcadso we be more agressive in reviewing them
21:39.03``Erikstarseeker: doesn't hurt to try, they're usually fairly easy going if minor tweaking is needed
21:39.04brlcadwe can point them to the quickies this year
21:39.22starseekerbrlcad: good idea
21:39.26brlcadno quickie should take more than a day or few
21:39.35starseekerwhoops, contractor is here
21:39.37brlcadwe can certainly expand that list
21:57.01CIA-14BRL-CAD: 03erikgreenwald * r43840 10/geomcore/trunk/ (59 files in 3 dirs): footer.sh
22:00.37``Erikdamnit, thought I broke that soon enough
22:33.17starseekerbrlcad: expand the projects list?  I've still got to get all those fleshed out
22:47.33*** join/#brlcad dli (~dli@dyn-216-212.wireless.concordia.ca)
23:56.42brlcadstarseeker: I meant the quickies list, no worries -- that'd be before they start applying, not before tomorrow
IRC log for #brlcad on 20110311

IRC log for #brlcad on 20110311

00:05.57dlibrlcad, my second try for rt_revolve_xfrom(): http://paste.pocoo.org/show/351409/
00:10.30starseekerGah, what happened to Project Ideas
00:11.10starseekeroh, that's the Code_In
00:11.13starseekernevermind, carry on
00:21.30CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2532 10/wiki/MGED_Sketch_Editor_Migration_and_Enhancement: Sketch editor
00:34.47CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2533 10/wiki/Ayam_Editor_Feature_Integration: Ayam editor integration
00:45.37CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2534 10/wiki/Analytical_Raytracing_Visualization: analytical raytracing GUI
00:59.07CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2535 10/wiki/Level_of_Detail_Wireframes: LOD wireframes
01:10.07CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2536 10/wiki/BoT_Editing: BoT editing
01:21.16*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
02:27.28*** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net)
02:33.12CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2537 10/wiki/NMG_Editing: NMG editing
02:48.30CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2538 10/wiki/Graph_layout_based_geometry_hierarchy_view: graph based viewing
02:49.33CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2539 10/wiki/Google_Summer_of_Code/Project_Ideas:
02:50.10starseekerWell, at this rate I'll be done in a few more days :-/
02:50.40*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
02:55.02CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2540 10/wiki/Geometric_Constraint_Solver:
02:57.00CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2541 10/wiki/Google_Summer_of_Code/Project_Ideas: move HDR entry
02:57.46KimKOn the brlcad.org homepage,what does it mean "...licensed at over 2,000 sites..."? Licensed how?
02:58.11starseekerKimK: I think that refers to the pre-open-source days
03:00.07KimKOK, thanks. I could only find BSD, GNU, and similar in the FAQs, Wiki, etc. , and I was confused.
03:00.37starseekerKimK: BRL-CAD being open source is a relatively recent thing (compared to its overall history)
03:01.25starseekerhttp://developers.slashdot.org/article.pl?sid=05/01/08/1823248
03:01.56KimKOK, very good what year did it open? I missed that part. So that text should perhaps read "...in use at over 2,000 sites..."? Oops, I'm typing too slow again, I'll bet you're ahead of me.
03:10.20CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2542 10/wiki/Analysis_Library: analysis library
03:21.04CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2543 10/wiki/Geometry_Conversion_Library: geometry conversion
03:24.16CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2544 10/wiki/Geometry_Conversion_Library:
03:24.51brlcaddli: I saw that, commented right after you left -- that's totally awesome
03:26.08brlcaddli: can you post that patch file to our patches tracker?
03:26.38brlcadhttps://sourceforge.net/tracker/?func=add&group_id=105292&atid=640804
03:40.07CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2545 10/wiki/GED_Transactions: GED transactions
04:04.59KimKI tried installing the BRL-CAD .deb (Ubuntu 10.04), Gdebi says I need libncurses5 (>= 5.7+20100313), I have what must be the latest, it is 5.7, but it's 20090803-2ub. Any advice?
04:10.50KimKGo plead my case to the Ubuntu libncurses5 maintainers, I guess? Please post any advice and I'll check back later. Thanks in advance.
04:11.41louipcyou sure the deb is appropriate for your distro?
04:13.05louipcas far as I understand debian and ubuntu are not quite interchangable anymore
04:13.53dlibrlcad, thanks, still testing it, need to get it work before posting to tracker
04:13.57louipcso you may need to alter some things if you want a debian package to work with ubuntu
04:14.14brlcaddli: ah, thought you already had it finished :)
04:15.20dlibrlcad, not yet. still have to test how it work. also, I'm still not sure I can simply keep the 2d vectors
04:15.21brlcadlouipc: are you interested in being a gsoc mentor?
04:16.41brlcad~seen jordisayol
04:16.42ibotbrlcad: i haven't seen 'jordisayol'
04:16.47louipcbrlcad: I would, but I don't have much free time unfortunately :(
04:18.02KimKlouipc: OK, thanks, I had not considered that I might not be able to use a .deb on Ubuntu anymore, I'll look into that.
04:18.17louipcbrlcad: Not really sure how I could mentor either since I'm not horribly active in the project :/
04:18.39louipcKimK: you can use .deb packages, but they should be packaged specifically for Ubuntu
04:19.38brlcadlouipc: anyone who has contributed enough to be trusted enough with commit access is eligible, participation is voluntary for everyone
04:20.16KimKlouipc: Do you know if there a BRL-CAD developer who packages for ubuntu? Maybe from his own web page or PPA?
04:20.28louipcI could mentor as in "It works" "it doesn't work, fix it" :D
04:20.41louipcKimK: not sure
04:21.03KimKlouipc: OK, thanks.
04:21.19brlcadKimK: jordi put together the recent .deb files
04:21.36brlcad~seen epileg
04:21.37ibotepileg <~epileg@unaffiliated/epileg> was last seen on IRC in channel #brlcad, 2d 13h 6m 39s ago, saying: 'here in spain, exactly same as ``Erik'.
04:21.45brlcadthat's him
04:23.34brlcadlouipc: good to know -- we have a decent number of "auditing" mentors this year, so just putting out feelers for folks in our community interested in taking on a student
04:23.43brlcadwhich is generally 10-20 hours a week
04:24.13louipcoh man that would be too much
04:26.08brlcadadd's up fast -- just an hour or two a day of discussion on IRC will add up to around that much
04:26.33brlcadbut no problem, figured worth asking -- let me know if you change your mind
04:26.58louipcis that like a 3mo gig?
04:27.20brlcadroughly
04:27.59brlcadhttp://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline
04:49.30starseekerbrlcad: If I can't get to 40, we may just have to live with it...
04:49.39starseekerI've got to sleep soon, been a long day here
04:49.45brlcadheh, that's great
04:50.07brlcadit's plenty, better to have 30 that are solid than 40 that are all half-arsed
04:50.36*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
04:51.22starseekerI'm at 16 now, and given I need to review them all once more... I'll work it tomorrow morning too, of course
04:51.49brlcadme too, started on the application a while ago
04:52.40starseekermoron former homeowners claimed they didn't need the sump pump, and we didn't have to worry about it
04:52.56starseekerWrong
04:53.20``Eriklame
04:53.29``Erikyou're not in a designated flood area, I imagine?
04:53.47starseekerno, but the front half of our home is partially underground
04:53.53``Erikso'z no flood insurance or anything...
04:54.01starseekernah, we'll have to eat it
04:54.06``Erik4 days of solid rain is weird for md
04:54.11brlcadyou also believed them :)
04:54.29starseekerbrlcad: Oh, I know - I'm not claiming any medals
04:54.47``ErikI'm glad mine is a slab, back yard turns to swamp, but no flooding :)
04:54.48brlcadany hole in the ground is subject to water pressure
04:55.25starseekerfigured if they had gotten away with it so long, must mean the local lay of the land was such that there wasn't significant water presence
04:55.37starseekerturns out they were just really friggin lucky
04:55.52brlcador they never went down there ;)
04:56.08starseeker<snort> yeah, that may be too
04:56.35starseekeralso, they only added the carpet in 2008 (we found out today) so perhaps they wouldn't have noticed earlier incidents
04:56.44brlcadI'm wanting to dig and install a french drain down mine, plenty of hydrostatic pressure here
04:57.04brlcadreally just wants an excuse to buy a jackhammer
04:57.05``ErikI'm sure you're well above the aquafer and have permeable soil, these last few days have been massive with the consistent rainfall, the soil is all saturating and there's nowhere for it to go...
04:57.10starseekerhehe
04:57.33starseeker``Erik: yeah, noticed that - grounds as wet as squishy as I can ever remember seeing it here
04:58.11starseekerwe may be "lucking out" and getting that right set of circumstances the former owners never happened to get
04:58.14``Erikum, I kinda got a bit stuck at work... in the grass/mud... with 4wd :D tore up a bit of grass this evening
04:58.25starseekerbut still, I should have known better - they didn't add the sump system for nothing
04:58.39starseekerit cost money to add, and lord knows nothing in this place cost more than it had to...
04:58.42``Erikstanding water all along the grass strip there
04:59.13starseekernods - when I had to park in grass this morning, I didn't even consider going in front first
04:59.48``Erikwas able to get out fine for lunch, it was after another few hours of rain that it just turned to mud
05:00.41starseekerbrlcad: you're getting as bad as Bob, considering the relative sizes of your properties - for you a jackhammer would take almost as much relative storage space as Bob's backhoe
05:00.56``Erikgonna have to wetvac one of the carpet bits, van drug in all sorts of mud O.o
05:01.09starseekerick
05:01.21brlcadnaw, they don't take that much space
05:01.32``Erikheh, jackhammer would fit down brlcad's suicide hole
05:01.47brlcadthat's exactly where I intend to start
05:02.16brlcadif i'm going to install a sauna down there, I want the hydrostatic pressure released
05:03.47``Erikgym has a sauna, make it a combo wine cellar/humidor :D
05:04.56brlcadit'll have a wine rack, shower, sauna, sink, and toilet; still debating on the hot tub
05:05.03``Erikor put a rack down there to hang your car
05:05.28brlcadoh I totally thought about installing an elevator to lower my car into "the pit"
05:05.34``Erikhas been wondering about putting in a slab under his deck to put a hot tub on
05:06.16brlcadkind of like these: http://dornob.com/secret-agent-style-stealth-lift-patio-car-elevator/
05:06.46brlcadah, right -- this one almost exactly: http://dornob.com/hydraulic-living-room-car-lift-rides-right-into-your-home/
05:07.29``Erikjust bolt a couple handles on the side and pick it up :D
05:12.23``Erikbrlcad: do you have the gsoc corrospondance concerning 'more detail' available for starseeker? is it volume, or information density?
05:13.02brlcadwhat?
05:13.05``Erik(or did everyone get the same 'guidance' to push the mentors?)
05:14.01brlcadoh that was a private conversation directly to me while they were reviewing our application in '09
05:14.48``Erikhm, so nothing to help steer starseeker with that olympian task
05:15.22brlcadit's not quite as bad as it sounds, it's not really volume or density, just sufficient variety to attract a wide range of students
05:16.03brlcadwhat was there for '09 is what we ended up with *after* I expanded the list in response to them saying we need more
05:16.13``Erikah, 'k
05:16.14brlcadso that's about par
05:16.17starseekerah, that's different
05:16.41``Erikclarification, w00t
05:17.24brlcadit should basically have at least that much detail, but more importantly be clear that there is a wide range of skills and it is easy for -randome_student- to figure out which topics might be of interest at a glance
05:18.43``Erikalso; starseeker has been breaking things down into a heirarchy with links to the meat, are the goog reviewers going to be cool with that, or do they want a single page view? it'd be fairly simple sql to generate a single "big honkin' page", I'd think
05:19.16brlcadthey're unlikely to dive deep
05:19.39brlcadthey have hundreds of these to go through, they're going to sweep through the site in all of 30 seconds
05:19.52starseekerwe can flatten it at the end, if we must - this is a better way for me to keep track of what is and isn't done yet
05:20.32brlcadhence the focus on clarity and organization, dumb simple clear that there's a lot of topics and possibilities
05:20.50brlcadmaybe a shallow hierarchy would be a good balance
05:21.15brlcadlike grouping each of the major categories all onto one page together
05:21.41``Erikthey already are, under === == = headers, but the task description is a link
05:21.41brlcadthen just have to consider what type of variety those top-level categories convey
05:22.35brlcadright but instead of kicking you off to a page with just one topic (which is kinda useful), it'd kick you over to a page for that category with the other dozen ideas in that topic area
05:23.02brlcadso even if they only click one level deep, they get to see that there are lots of project ideas
05:23.47brlcadI'd stick with the one per page and massive top index for now until they're mostly all fleshed out and named in non-brl-cad-technical terms
05:23.54CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2546 10/wiki/Geometry_Selection_Functionality: geometry selection
05:37.57brlcadan iges task would be good
05:38.42starseekerI'll see what I can do - convert iges to spit out openNURBS nurbs?
05:41.27CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2547 10/wiki/Libsvn_within_Geometry_Database_Format: libsvn in .g
05:42.32CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2548 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Tools */
05:50.03CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2549 10/wiki/IGES_import_improvements: IGES updates
05:50.31starseekerok, I gotta sleep now
05:51.21CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2550 10/wiki/Talk:Error_Messages:
06:15.39*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:12.18*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
09:43.21CIA-14BRL-CAD: 03davidloman * r43841 10/geomcore/trunk/src/libNet/Portal.cxx: Cleaned up a bit of messageLen checking logic. twas wrong.
09:46.28CIA-14BRL-CAD: 03davidloman * r43842 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (4 files in 2 dirs): Performing some java<->c/c++ bug troubleshooting. Added the ability to down sample 16bit character strings to 8bit character strings.
10:48.38dlihow do I disable -Werror?
10:54.57*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
11:07.18dlisrc/conv/patch/patch-g.c in 7.18.2 fails with -Werror
13:28.20dlomanmy prayers to all of you in or have family near the Pacific.....
13:35.08dlidloman, no wonder 'tsunami' is a japanese word. no news of tsunami losses out of japan yet
13:42.06starseekerdli: disable strict
13:44.12dlistarseeker, yes, I found out that, but someone may still have to fix patch-g.c
13:44.44dlior it's my compiler, patch-g.c looks alright to me
13:47.08starseeker7.18.4 should have a lot of strictness fixes
13:49.22dlistarseeker, the warning is about uninitilized variables, but it should not happen to me. I will try whether some reorganizing helps the compiler
13:50.22starseekerdli: I'd suggest checking out the lastest subversion trunk and trying that
13:50.46dlistarseeker, I will try that
13:57.18CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2551 10/wiki/Space_Partitioning_for_Tessellation: tessellation space paritioning
14:02.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:09.21CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2552 10/wiki/STEP_Libraries: STEP improvements
14:10.44CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2553 10/wiki/STEP_Libraries:
14:21.59CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2554 10/wiki/NURBS_Intersections: surface/surface
14:27.33dlomandli: death toll (worst guess i've read thus far) is at 60 and climbing.
14:27.50dlomanbased only on the video footage i've seen, that number's going to go waaay up.
14:28.27starseekerit's bad, but fortunately Japan is accustomed to dealing with earthquakes
14:28.53dlomanheh, the quake was nothing, its the tsunami that's destroying everything
14:29.03starseekernods
14:29.27starseekerif large waves hit less prepared areas of the world, the results could get a lot worse
14:30.02dlomanreuter's is reporting that country's oil refineries are on fire, most of their nuclear power plants have experienced an emergency shutdown, etc.
14:30.33dlomanrighto, that's what most people are saying.  the warning system has been greatly enhanced since the indonesia disaster in 2004
14:30.40starseekernods - 8.9 is a bad earthquake no matter how prepared you are
14:31.25dlomanwaiting on news from my cuson Josh.  he's station at the naval medical hospital in Okinawa
14:31.47dlomanheh s/cuson/cousin/
14:32.02starseekerI imagine he's probably OK
14:32.28starseekerprobably rather busy though
14:32.29dlomanhe is, i'm just wanting to hear it from him, not his Command :)
14:32.35starseekerah
14:32.50dlomanoh yeah, that slacker is going to finally earn his pay :)
14:38.00CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2555 10/wiki/NURBS_Tessellation: nurbs tessellatoin
14:40.12dlomanwow.... a whirlpool... http://www.cnn.com/video/#/video/world/2011/03/11/vo.whirlpool.earthquake.nhk?hpt=C2
14:41.59starseekergrr s/tessellatoin/tessellation
14:54.04CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2556 10/wiki/Generalized_abstracted_spacial_partitioning_capability: abstracted space partitioning
14:56.03CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2557 10/wiki/Google_Summer_of_Code/Project_Ideas:
15:03.39CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2558 10/wiki/Rework_of_libbu/libbn_to_not_require_Tcl: tcl scrubbing
15:13.05CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2559 10/wiki/Complete_bu_image/libicv_and_redo_all_pix_tools_to_use_it: libicv
15:14.23CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2560 10/wiki/Google_Summer_of_Code/Project_Ideas:
15:31.30CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2561 10/wiki/Add_exec_option_to_search: search exec
15:34.13CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2562 10/wiki/Add_exec_option_to_search:
15:34.54CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2563 10/wiki/Add_exec_option_to_search:
15:59.36brlcaddloman: so what would a tsunami feel like from inside a sub near the surface but not on the surface?  a can of beans?
16:00.27CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2564 10/wiki/SVG_renderer: vector line rendering
16:00.29dlomanprobably be a lot of rocking and rolling (angles n dangles) but no real biggy.
16:00.45dlomanwe were at 100ft under a cat 4 hurricane once
16:00.55dlomanwas lots of pitching, but thats it.
16:00.59brlcaddon't think you could get a barrel roll?
16:01.03dlomanheh
16:01.24dlomannuclear sub does a barrel roll and you'd have a pretty sizeable nuclear accident :)
16:02.04``Erikhttp://seemslegit.com/_images/61b896b4384935498227a03c54b85370/93%20-%20barrel-roll%20ship.jpg
16:03.32dlomannot loading for me :/
16:03.38dlomanbut I think i have seen that one before.
16:03.51``Erikcargo ship heeling at 80 or so?
16:03.59dlomanya
16:05.32dlomanbut on the note of nuclear accidents, seems Japan is going to have one of those too :/
16:05.54dlomanonce of their plants scrammed out and they can't get emergency cooling established to the core :(
16:06.18brlcad"shut it off! SHUT IT OFF!"
16:06.25dloman=D
16:06.27brlcadfuck, RUN!
16:06.48starseekerthat's Not Good
16:07.02dlomanYeah, they learned something from the chernobyl plants :)
16:07.13starseekerI thought modern plants were supposed to fail safe
16:07.19brlcaddli: curious, now have two impls that are nearly identical but with interesting differences
16:07.27dloman"Whats that big red light and that alarm for?"  "Nothing, just keep on with the test"
16:07.46dlomanit is 'safe' from a meltdown standpoint.
16:08.03dlomanpressurized water reactors shut themselves down on high temp
16:08.30starseekerso what's the accident part?  ruin all the core machinery?
16:08.42dlomanbut the byproducts of the fission process are always activated and have to shed their energy
16:08.54dlomanso even a shutdown core will generate heat for weeks.
16:09.16brlcadweenie roast party!
16:09.23dlomanrun a core at 100% for a few months then scram it and you will see about 7% heat generation for a few hours.
16:10.07dlomanthat 7% decays to 0% (aka heat gen is < than the losses to ambient) in usually about 15-21 days.
16:10.18dlomanthe entire time, however, you must provide heat removal
16:10.32dlomanwhich is the problem the Japanese plan is having.
16:10.50dlomanthe tsunami flooded a lot of their facilities and messed up a bunch of equipment
16:11.05dlomanso they are having trouble removing the decay heat.
16:11.54dlomanwhich, if let go unchecked, could reach a high enough temperature to start melting some of the cladding around the fuel rods, thus releasing activated fission products into the coolant.
16:12.00``Erikread that most of japan's nukes went emergency shutdown and oil refineries are on fire
16:12.07dlomanstill contained, but a naaaaaaaaaasty cleanup.
16:12.49dlomanhowever, if the tsunami has damaged any of the coolant piping, that nasty stuff could get out....
16:13.42dlomanBut, unles they build 'em stupid over there in Japan (not likely) there is usually a backup to the backup to the backup
16:14.11dlomanand if their emergency cooling system has failed, then they will prbably fallback on the emergency emergency cooling system :)
16:15.50dloman</AccidentialNukeTheoryClass>  ...sorry
16:16.36CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2565 10/wiki/NMG_Raytracing_Performance_Improvement: nmg raytrace performance
16:17.39starseekerhopes they get it handled, and not just for their sake - last thing the world needs is another reason to be skittish about nuclear power
16:18.40starseekercrap - sounds like that death toll from Japan is going to get a lot higher
16:18.50dlomanseen the videos on cnn ?
16:19.04CIA-14BRL-CAD: 03brlcad * r43843 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: apply an initial (reportedly non-working) version of rt_revolve_xform() from dli
16:19.11dlomani watched over 20 cars get swallowed by water.... its going to be really bad
16:21.08starseekergood god - what IS that whirlpool from?
16:21.24dlomandunno, but it stops toward the end.  really wierd.
16:21.48``Eriksmall fissure opening up? tsunami water draining strangely?
16:21.55dlomanhttp://www.myvisitingcard.com/2011/onagawa-fire-broke-out-declared-nuclear-power-emergency-situation.html
16:22.18starseekerwondered if it was some subterranian crack in the sea floor...
16:22.37dlomanDr evil's secret lair flooded?
16:22.42CIA-14BRL-CAD: 03brlcad * r43844 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: move up in order to compare patch
16:24.00starseekerdloman: what's a "nuclear emergency situation"?
16:24.10dlomanintentionally vauge
16:24.15dloman=D
16:24.19starseekerhumph
16:24.30dlomanthe article states that they 'cooling the reactor is not going as planned'
16:24.49dlomanwhich means they got th reactors safelt shutdown, but are having issues mantaining cooling to the core.
16:25.00dlomanto remove the above mentioned 'decay' heat
16:26.05dlomanpush comes to shove, the did just have a tsunami, so they have plenty of water to use for cooling. :/
16:35.07CIA-14BRL-CAD: 03brlcad * r43845 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c:
16:35.07CIA-14BRL-CAD: and then merge in his version that reportedly works with a couple changes. we
16:35.07CIA-14BRL-CAD: do need a copy of the bu_vls, so init and cat accordingly. skt was apparently a
16:35.07CIA-14BRL-CAD: typo and MAT4X3VEC instead of MAT4X3PNT is probably what got it working.
16:35.38dlomanah, looks like the waves have finally reached cali
16:38.22CIA-14BRL-CAD: 03brlcad * r43846 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: doxygen + ws
16:39.54CIA-14BRL-CAD: 03brlcad * r43847 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: eip/eop was specific to extrude. use rip/rop for revolve.
16:40.49CIA-14BRL-CAD: 03brlcad * r43848 10/brlcad/trunk/src/librt/primitives/table.c: dli implemented rt_revolve_xform and it compiles, so turn it on for testing
16:42.48CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2566 10/wiki/Plate_Mode_NURBS_raytracing: plate mode NURBS
16:44.00starseekerJust under 20 to go
16:45.23CIA-14BRL-CAD: 03brlcad * r43849 10/brlcad/trunk/ (AUTHORS NEWS): Dongxu Li implemented support for applying matrix transformations (scale, translate, rotate) to the revolve primitive. promote him up from the special thanks section to being recognized as a code contributor.
16:45.47brlcadkicks off a final release build while he works on the gsoc application
16:48.11brlcadreally curious to know whether the the libbu mmap bug affects other tools on windows
16:51.48CIA-14BRL-CAD: 03brlcad * r43850 10/brlcad/trunk/NEWS: (log message trimmed)
16:51.48CIA-14BRL-CAD: cliff and I apparently (hopefully) squished the 'red' command bug where it
16:51.48CIA-14BRL-CAD: wasn't working on windows. the problem was two-fold. the regex code wasn't
16:51.48CIA-14BRL-CAD: breaking on newlines and (apparently) libbu's mapped_file fallback support had
16:51.49CIA-14BRL-CAD: an off-by-one error where it wasn't terminating the mapped file with a zero
16:51.49CIA-14BRL-CAD: byte. that was causing regex to scan beyond the buffer extent. that issue very
16:51.49CIA-14BRL-CAD: likely affects other tools and interfaces that use our mapped file support on
16:51.55brlcadamazing, went from being a tiny patch release to looking more and more like a full minor update
16:55.46brlcad``Erik: you have any gimp skill?  need a small image to represent the TIE BoT enhancement (max 256x256)
16:57.34brlcadwas thinking maybe a two 128x128 images in opposite corners of the 256x256 space, one partially rendered 20%, the other at 100%, with text above/below each respectively saying old mesh rendering and new approach
16:58.11brlcador maybe a new validation image of the truck showing the pixdiff differences, scaled down
16:58.20brlcad(or rendered at that size even better)
17:10.15CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2567 10/wiki/CSG_to_NURBS_conversion: finish up CSG->Brep
18:01.24CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2568 10/wiki/Google_Summer_of_Code/Project_Ideas: Remove a few entries - getting down to the wire
18:26.06``Eriknope, no gimp skill at all, I can click on 'script-fu' and click 'scale', that's about it
18:26.18``Erikstarseeker: vic reports red is not working on mac
18:26.35``Erika very recent change broke it
18:54.27brlcadprobably the regexes
18:55.21brlcadwill look after the application is done
19:27.03``Erikhm, too late for new ideas for gsoc?
19:28.18``Erik"voxelize", like facetize, to spew out a big honkin' union of arb8's, mebbe using the marching cubes grid stuff... to feed cfd's and stuff
19:31.09starseeker``Erik: not too late if you want to add it
19:31.43starseekerhad to take down some stuff in his house - I'll try to get a couple more done..
19:32.15starseekerstill got work going on - drywall out everywhere...
19:33.20dlomanever find that leak?
19:33.39starseekerdloman: it was the friggin sump pump (or rather, lack thereof)
19:33.48dlomanbroke or missing?
19:33.54starseekerprevious homeowners assured us they'd never needed it (they took it out)
19:34.02starseekerwe though "well, OK..."
19:34.06starseekeroops
19:34.11dlomanoh man.....
19:34.20starseekerone of my more expensive mistakes
19:34.24dlomani thought it was regulation to have one?
19:34.31starseeker?
19:34.33starseekerdunno
19:34.52dlomanlooking to build my next house, so i have a reg book at home.  I'll check :)
19:34.57dlomanSUE THEM!!!!
19:34.59dlomanj/k
19:35.19dlomanis the piping/wiring to a sump pump still in place?
19:35.38starseeker<snort> I doubt it's "on the books" - we asked about it durning the home buying process, and one of the pros would have said something if it was actually required...
19:36.06starseekerdloman: sure - there's a sump, an outside pipe and an outlet.  They just took out the indoor pipe and pump and turned it into a closet
19:36.45starseekernow that I've got the mirror wall off the staircase, there's a much bigger mold spot
19:37.01starseekertoo high for recent activity, so looks like the pipe to the faucet outside may be having issues
19:37.11dlomanoh hell.... mold... im so sorry man :(
19:40.26starseekerthey cut out like four feet of drywall and sprayed some stuff, so the mold is gone, but we look like a home rennovation show down there
19:42.21CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2569 10/wiki/Google_Summer_of_Code/Project_Ideas: /* BRL-CAD Core Library Enhancement */
19:45.47``Erikwhat was the name of that thing mike did? uh, qubit or something?
19:45.58starseekercubit
19:46.22starseekerhttp://cubit.sandia.gov/
19:46.41starseekerwas never much interested in it, as it's not open source
19:47.00starseeker(at least, the interesting parts related to mesh generation don't seem to be)
19:47.30brlcad``Erik: I need your link_id not your google id this year
19:48.06brlcaddloman: did you see my message about a poster? :)
19:48.20dlomanmessage?
19:48.22dlomannegative
19:49.18brlcadwe're going to need another gsoc poster this year, it's a chance to take some creative artistic liberty and make a neat page enticing students to apply
19:49.37CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2570 10/wiki/Material_and_Shader_Objects: material and shader objects
19:49.38brlcadyou'd be perfect for that, as shown by other graphics you've worked on of late ;)
19:49.41CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2571 10/wiki/Voxelize: New page: Voxel data sets are commonly used in computational fluid dynamic simulations. The current technique for creating voxels from BRL-CAD geometry is to use the proprietary cubit framework. Th...
19:49.42dlomanwhere was the message? Or was that it?
19:49.47starseekerand you don't want me doing it :-P (see archer icons)
19:50.09dlomanyeah, starseeker MS paint isnt that great of an editor :P
19:50.25brlcadyou can see the previous two years posters by me and cliff at http://brlcad.org/wiki/Google_Summer_of_Code#BRL-CAD_participation_in_GSoC
19:50.49starseeker<snort> Gimp + inkscape + http://www.openclipart.org/ baby
19:51.17brlcadcool, the initial submission is DONE
19:51.22brlcadnow to tweak
19:51.24starseekerawesome
19:52.41starseeker``Erik: any of the existing ones you want to fill in?  (shader enhancements might be a good one, you have more knowledge about 'em than I do)
19:52.47``Erikhuzzah, a menu items appear, it is effective!
19:53.47``Eriknah, starseeker, I'm good :D (not sure what the shader thing is about)
19:58.12CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2572 10/wiki/GUI_Animation_editor/creator: New page: Creating animations using BRL-CAD is currently a very manual and tricky process. A GUI editor to create Bezier splines for moving objects, lights and the camera and generating rt scripts a...
19:58.39starseeker``Erik: I was thinking investigate Open Shader Language and how we can benefit from it
19:58.46starseekermaybe too vague for a gsoc project though
19:58.51CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2573 10/wiki/GUI_Animation_editor/creator:
19:59.08``ErikI dunno the open shader language... similiar to renderman?
19:59.16starseekeryeah...
19:59.18starseeker<PROTECTED>
19:59.33starseekerhttp://opensource.imageworks.com/?p=osl
19:59.40starseekerwas a big thing at siggraph
19:59.57brlcadmm, shader objects
20:00.21starseekerbrlcad: did I miff that one?
20:00.27starseekermay be typing too fast here...
20:00.41brlcadI haven't read any of them yet, delegation my dear watson
20:00.45brlcadtaking a lot of time just to prep the app
20:00.49starseekernods
20:01.00brlcadit's in, but I still have at least an hour of editing and re-reviewing to go
20:01.04starseekergot it
20:01.18brlcadleaving it all on you guys :)
20:01.23starseekerwell, if it gets buy gsoc review we can polish it later
20:01.27CIA-14BRL-CAD: 03jordisayol * r43851 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): modify deb/rpm building packages dependencies
20:06.03dlomanbrlcad: when u need the poster by?
20:06.46brlcadwhenever it's ready really
20:06.53``Erikyesterday morning
20:06.59CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2574 10/wiki/Shader_Enhancements: New page: Shaders for the ray-tracer are currently coded in C and explicitly added to the active shader list. A shader to bridge the RT shader system to the BSD licensed implementation of OSL ( [htt...
20:07.18brlcadif you want to make sure you don't waste time, then as soon as org applications are approved
20:07.29starseeker``Erik: heh, beat me too it - thanks!
20:07.39brlcadsince ours has a high chance of acceptance, then anytime really
20:07.40``Erikprobably needs cleanup/editing anyways
20:07.58``ErikI'm just spewing out rough draft quality stuff here... :D
20:08.22starseekerchecks...
20:08.28starseeker``Erik: you think I'm not?
20:08.35starseekerI tend to ramble in the best of times
20:08.40starseekerwriting fast makes it worse
20:10.14CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2575 10/wiki/General_Tree_Walker: New page: There are currently several slightly different functions to recursively walk the CSG tree. This task would be to implement a new tree walking function capable of replacing them all and alt...
20:12.22CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2576 10/wiki/Shader_Enhancements: Tweak shader enhancements entry
20:13.19starseekerhits blender-g
20:16.09brlcadshould probably be blend-g ;)
20:16.17starseekerer, right
20:16.35starseekerheh - blender-g, toaster-g, eggbeater-g...
20:16.35brlcadremember to try and avoid brl-cad specific conventions at least in the project titles and initial sentance descriptions
20:16.54CIA-14BRL-CAD: 03Erik 07http://brlcad.org * r2577 10/wiki/Converter_completion_so_all_current_formats_have_both_import_and_export: New page: BRL-CAD implements numerous importers and exporters for a wide variety for formats, but not every format has both an importer and an exporter. An old list is available in the repository [h...
20:17.05brlcadit should be worded as if BRL-CAD did not exist  (e.g., "Blender geometry importer")
20:17.15starseekerbrlcad: I'll try to make a pass and eliminate as much of that as I can...
20:17.22brlcadthen can go into detail on the specific page
20:17.27``Eriknext time I make a disposable geometry format, I am so calling it spatula.
20:17.57brlcadreally liked avoCADo :)
20:18.17brlcad(dead for 3 years now)
20:18.36starseekeris it on sourceforge?  we could try a takeover :-P
20:18.37brlcadthere's some nurbs code you could look into snarfing starseeker
20:18.44starseekerwhat license?
20:18.55brlcadsourceforge project name sucks -- "avocado-cad"
20:19.21brlcadah right, gpl
20:19.26brlcadbleh
20:19.46starseekerthere are least two other nurbs libs I'm aware of that are will remaing GPL
20:19.49starseekervery frustrating
20:19.56starseeker(especially SISL...)
20:21.10brlcaddloman: the only stipulation is that the poster should be predominantly made with brl-cad imagery  ;)
20:21.17brlcadwhich shouldn't be hard for you of all people
20:25.04CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2578 10/wiki/Blender-g_importer: blend-g
20:28.11CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[SVG renderer]] moved to [[Vector output from raytracing]]: retitle
20:29.28CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Blender-g importer]] moved to [[Blender file format converter]]: retitle
20:29.38CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2583 10/wiki/Google_Summer_of_Code/Project_Ideas:
20:30.24CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2584 10/wiki/General_Tree_Walker:
20:37.42*** join/#brlcad Stattrav (~Stattrav@117.192.148.157)
20:37.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:49.05CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2585 10/wiki/Overlap_tool: overlap tool
20:52.23CIA-14BRL-CAD: 03jordisayol * r43852 10/brlcad/trunk/ (misc/debian/rules sh/make_deb.sh sh/make_rpm.sh): update "make" simultaneous jobs, during deb/rpm building process
20:52.29``Erikpics http://www.theatlantic.com/infocus/2011/03/earthquake-in-japan/100022/
20:53.10CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2586 10/wiki/Automated_exploded_view_tool: exploded view
20:53.46brlcadi guess it did happen
20:58.49CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2587 10/wiki/Automated_cutaway_view_tool: cutaway view
20:59.52starseekerpants - thanks ``Erik for the assist
20:59.56CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2588 10/wiki/Google_Summer_of_Code/Project_Ideas: remove stray links
21:01.36starseekerjust before 4pm EST
21:02.13starseekernow has to head in - ``Erik if you want to flatten the page in some way shape or form you're welcome
21:02.45brlcadthanks starseeker, tis great rogress
21:05.23starseekerbrlcad: your welcome, my pleasure - we'll hope it's enough
21:11.20``Erikhttp://www.youtube.com/watch?v=vs2l38DoqsQ
22:41.30brlcaddloman: do you have a link_id?
22:45.34CIA-14BRL-CAD: 03128.63.32.5 07http://brlcad.org * r2589 10/wiki/Google_Summer_of_Code/Project_Ideas: stray text
22:57.18starseekerhmm:  http://www.nasa.gov/open/source/
23:00.08brlcadadds the final finishing touches
23:03.31CIA-14BRL-CAD: 03starseeker * r43853 10/brlcad/branches/cmake/ (8 files in 6 dirs): MFC r43852
23:03.44starseekerwonders if he can attend a two day virtual conference...
23:06.56brlcadthat's probably the best-worded GSoC application to date
23:07.20brlcadinvariably reorganize every time, clean up the organization and writeup structure
23:07.29starseekercool :-)
23:09.18starseekeryeow, what the heck...
23:09.29brlcad430 orgs applied
23:09.34starseekerrebuilds clean - hopefully this is just a messed up build...
23:09.44starseekerbrlcad: is that more than last year?
23:09.54brlcadyeah
23:10.04brlcadbut then org acceptance has increased every year too
23:10.19starseekerhow long typically before we find out?
23:12.01brlcadhttp://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline
23:12.19starseekerah, right
23:12.33brlcad~gsoc
23:12.33ibotgsoc is probably the Google Summer of Code, a program run annually by Google to provide (paid for) jobs to students to code on open source projects over summer.  See http://code.google.com/soc/ for details.
23:12.46brlcad~timeline
23:13.15brlcad~timeline is the GSoC 2011 timeline is at http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2011/timeline
23:13.15ibotokay, brlcad
23:20.43starseekerinteresting... red works on my Mac
23:20.53starseekerlet's try with system regex
23:21.26brlcadthat is interesting
23:21.39brlcadhe wouldn't have likely compiled with system regex on mac
23:21.44brlcadbecause of system tcl/tk
23:21.54brlcadunless he specifically turned on system regex
23:22.25starseekerthat's cmake build... suppose I should try autotools
23:22.58brlcadat least, auto doesn't work on 10.6 because system tcl IS a compatible .6, but mged/libdm crashes trying to make X11 calls
23:24.35starseekerah... in principle, the CMake FindTCL should spot that system Tcl/Tk isn't X11 - will have to try that out
23:28.03starseekermay have to ask him more specifically what failed
23:28.24brlcadtechnically, configure is checking correctly
23:28.27brlcadour code is wrong
23:30.08brlcadhopes for an ogre/qt dm project
23:30.35starseekerThat'd be awesome
23:31.43starseekerno, system regex worked too
23:32.02starseekerwonder if his build got into a weird state - I had to flush my cmake build and redo
23:32.28starseekerwill check with him on Monday, assuming he doesn't have to be home for more contractor fun
23:52.51dlistarseeker, how big is the whole svn repository? it has been downloading for two hours
23:52.58starseekeruh oh
23:53.09starseekerdli: you don't want the whole thing
23:53.31starseekertry svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad-svn
23:55.21dlistarseeker, oh, I only put https://brlcad.svn.sf.net/svnroot/brlcad/ there :( my bad
23:55.33starseekerouch
23:55.48starseekeryeah, that'll pull all tags, all branches, all of everything
23:56.46starseekerI'll generally use the svn browse functionality to check the structure of a repository prior to downloading
23:59.59dlistarseeker, I'm putting this together for a gentoo ebuild:(
IRC log for #brlcad on 20110312

IRC log for #brlcad on 20110312

00:00.36starseekerI thought there was a gentoo ebuild?
00:00.42brlcaddli: hehehe, yeah... you definitely don't want the whole thing
00:01.13dlistarseeker, I think I had been updating the one on gentoo bugs for years :(
00:01.23starseekerah
00:01.30brlcaddli: you've seen http://packages.gentoo.org/package/sci-misc/brlcad yes?
00:01.45brlcadbicatali is looking for a maintainer
00:02.10dlibrlcad, 7.16.8, I should submit an updated copy to gentoo BTS
00:02.25brlcadyou should become a gentoo dev ;)
00:02.30brlcadthen just update it yourself
00:02.39brlcadprocess isn't too complex
00:02.44dlibrlcad, but I switched to archlinux long ago :(
00:02.52brlcadah, heh
00:03.25dlibrlcad, just still got a gentoo leftover in house, a thinkpad with broken video card. so I playing the ebuild there
00:05.20dlibrlcad, still I will try to maintain brlcad on gentoo :( helping brlcad on archlinux as well
00:06.37brlcadI used to notify an archlinux maintainer, but after a couple years of failing to update, I removed them from our notification list
00:07.20brlcadhm, hadn't seen this  http://aur.archlinux.org/packages.php?ID=8320
00:08.04brlcadlooks like it's not too far out of date any longer, or perhaps I'm thinking of a different distro
00:08.35dlibrlcad, yes, they got 7.18.0, and the PKGBUILD works for 7.18.2, which I'm using
00:09.03brlcadstarseeker: http://download.rhino3d.com/openNURBS/5.0/release/download/
00:09.12brlcadlouipc hangs out here
00:10.35CIA-14BRL-CAD: 03brlcad * r43854 10/brlcad/trunk/TODO: update to openNURBS 5.0
00:13.13starseekerbrlcad: I know - haven't had the time to merge and test in BRL-CAD yet
00:14.22starseekerthink I got most of the changes that still need applying sorted in the libnurbs project, but not completely sure yet and didn't want to bugger anything up
00:50.31starseeker``Erik: hmm
00:50.34starseekerProgram received signal EXC_BAD_ACCESS, Could not access memory.
00:50.34starseekerReason: KERN_PROTECTION_FAILURE at address: 0x00006f28
00:50.37starseeker0x00186010 in Logger::instance ()
00:50.45starseeker(running gsTest on a mac)
00:55.27brlcadnods -- I recalled you mentioning it, I was just reminded when I got their newsletter update
00:55.47starseekerah, cool
00:57.57CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2590 10/wiki/Google_Summer_of_Code: emphasize checklist
00:57.57dlistarseeker, so it says more than 'segfault' on mac?
00:58.32starseekerhmm? what does?
00:58.45starseekeroh - that's the gdb message
00:58.53dlistarseeker, I see
00:58.58louipcbrlcad: Hah I haven't been that negligent. You must be thinking of another distro
00:59.17brlcadlouipc: yeah, probably
00:59.23louipcI couldn't get 7.18.2 to build last time I tried, so I haven't updated the archlinux build
00:59.24dlilouipc, so, you do archlinux?
00:59.30louipcyep
00:59.33brlcadreally?  that's odd
00:59.34starseekeraaaaa, poop. the openmoko on ebay (with developer board and accessories, mind you) went for $74
00:59.44brlcadlouipc: I suspect you need --disable-strict
00:59.46louipcdidn't have a chance to investigate
00:59.50starseekergot distracted by house
00:59.54dlilouipc, I just copied 7.18.0 PKGBUILD, and it builds for me with 7.18.2
01:00.14louipcbrlcad: yeah that's probably what it is, it was also failing in svn for a little while after release
01:01.04dlilouipc, http://paste.pocoo.org/show/352245/
01:01.34starseekerhttp://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=110656800112
01:01.36louipcdli: ah yeah disable strict
01:02.08louipcwill there be a new release soon?
01:11.39CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2591 10/wiki/Google_Summer_of_Code: simplify, move application details to the guidelines page
01:19.26CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2592 10/wiki/Google_Summer_of_Code/Application_Guidelines: move info from main intro page to here for applicants
01:21.21CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2593 10/wiki/Google_Summer_of_Code: /* Preparing an application */
01:29.23CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2594 10/wiki/Google_Summer_of_Code: gsoc is not a job
01:30.11CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2595 10/wiki/Google_Summer_of_Code: retitle
01:31.36CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2596 10/wiki/Google_Summer_of_Code: sublisted
01:31.47brlcadlouipc: yeah, we just passed all tests -- tarball possible later tonight
01:32.52starseeker``Erik: hmm, traditionally our build system is BSD licensed, not LGPL - looks like I need to fix geomcore headers for CMakeLists.txt files
01:33.23starseekerthings we should also have a simple Geometry Service client that is BSD licensed to make it easier for people to build clients...
01:33.30starseekers/things/thinks
01:33.56CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2597 10/wiki/Google_Summer_of_Code/Checklist: link back to parent
01:34.46brlcadhttp://brlcad.org/d/node/85
01:35.31*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 under way (20110311) || BRL-CAD applying to participate in GSoC 2011! http://brlcad.org/d/node/85
01:41.42*** join/#brlcad waprat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
01:43.52louipcwoo!
02:20.53CIA-14BRL-CAD: 03starseeker * r43855 10/geomcore/trunk/ (7 files in 3 dirs):
02:20.53CIA-14BRL-CAD: Set up the support structure for a basic GS client that is independent from the
02:20.53CIA-14BRL-CAD: rest of geomcore, but still built as part of the geomcore build. In essence,
02:20.53CIA-14BRL-CAD: it's a src/other style build but with our own code. No functionality yet.
02:22.33starseekerwell, now that I'm set up to build a tool that knows nothing but the GS protocol docs I guess I'd better figure out how to write it
02:22.47starseekerforsees a busy week
04:28.24*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
04:39.37CIA-14BRL-CAD: 03Starseeker 07http://brlcad.org * r2598 10/wiki/Contributor_Quickies: Sean stomped the strict compiler warnings
06:06.27*** join/#brlcad Stattrav (~Stattrav@122.172.156.61)
06:06.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:25.15brlcadinteresting rant by bryan bishop on the openmanufacturing group
06:25.25brlcadstarts packing
06:27.33*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
06:27.51brlcadhowdy kink
06:27.54brlcader, kimk
06:28.05KimKHi
06:28.41KimKI haven't done anything about installing brlcad yet, but still hope to
06:29.02brlcadnods
06:30.10KimKI'm hoping to gently request that the Ubuntu maintainer of (whatever it was) update his 2009 install.
06:30.42KimKBecause that would be the easiest thing from *my* point of view, lol!
06:31.01brlcadusually can't hurt
06:32.05KimKHa, I feel bad about that: (1) I have a problem (2) somebody else fixes problem (3) No problem!
06:32.39KimKOh, well.
06:33.26KimKAnyway, hope you don't mind if I hang around. I'm not usually this noisy.
07:04.43*** join/#brlcad Stattrav (~Stattrav@122.172.156.61)
07:04.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:17.31*** join/#brlcad merzo (~merzo@193.254.217.44)
13:08.24*** join/#brlcad Stattrav (~Stattrav@117.192.156.73)
13:08.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:23.43starseekerHuh - the CIA bot came from picogui originally?
15:17.19brlcadnot really
15:17.22brlcadbut the same author
15:17.28starseekercool
15:17.54brlcadKimK: you can hang around any time, that's not noisy ;)
15:18.07starseekerbrlcad: thanks for mentioning that Bryan Bishop posting
15:18.53brlcadhe's not been in here in a while
15:19.11brlcadbut I certainly liked the sound of capable dev interest ;)
15:19.17starseekerdangled a lure to see if he can interest them in working to enhance openNURBS instead of doing Yet Another Small Cad Kernel...
15:20.00brlcadsuspects nurbs is but a tiny part of what they care about
15:20.17starseekeroh, probably, but worst case they ignore me :-)
15:23.17starseekerhis post mentioned specifically "a need for more mathematical geometry work
15:23.20starseekerbefore all standard NURBS manipulation routines are finished"
16:39.37*** join/#brlcad Stattrav (~Stattrav@117.202.19.158)
16:39.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:46.15*** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net)
19:33.58*** join/#brlcad piksi (~piksi@pi-xi.net)
IRC log for #brlcad on 20110313

IRC log for #brlcad on 20110313

00:49.48*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
03:47.15starseekerhah - SISL modernized their build with CMake
03:47.24starseekerand doxygen
03:47.27starseekercool
03:49.47starseekerstill GPL though
03:51.08dlistarseeker, I try to clean up the strict-build problems, seems to be caused by tcl
03:51.34starseekerdli: uh... we shouldn't be trying to build Tcl with strict flags
03:52.18dlistarseeker, or, should we clean up the code, and let tcl to handle the 32bit/64bit problem
03:53.09starseekerdli: you can try making patches to Tcl/Tk if you're finding problems and send them back to them...
03:53.21starseekeror try the 8.6 branch of the code
03:54.24dlistarseeker, I need tcl-8.6 first then
03:54.58dlistarseeker, 8.5.9 is what in gentoo
03:55.04starseekerright
03:55.19dlistarseeker, the same 8.5.9 in archlinux
03:55.39starseekeryeah, 8.6 is still in development - has been for quite a while
03:55.49starseekerhas to run...
03:56.28dli:)
04:49.49*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
06:40.48*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
08:03.17*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
10:45.20*** join/#brlcad piksi (~piksi@pi-xi.net)
14:46.55*** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net)
16:17.30*** join/#brlcad Stattrav (~Stattrav@117.192.137.236)
16:17.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:26.36*** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net)
16:27.32dlifrom trunk: I got ditsplitc.c:(.text+0x301): undefined reference to `sincos'
16:27.37dli-lm ?
16:36.39dliMakefile:LIBM =
16:36.42dlithat's why
16:54.51*** join/#brlcad Stattrav_ (~Stattrav@117.192.140.54)
19:07.39CIA-14BRL-CAD: 03starseeker * r43856 10/geomcore/trunk/src/GS/testclient/ (CMakeLists.txt gstestclient.c): It's a bit confusing. Trying to send the simplest thing possible to the server, and it's getting SOMETHING, but doesn't recognize it.
20:19.08*** join/#brlcad Stattrav (~Stattrav@117.192.140.54)
20:19.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:31.57CIA-14BRL-CAD: 03starseeker * r43857 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Ah, progress - need to pack the message using pkg_pshort
20:32.34starseekerwhy do I need to supply the port as the first element of pkg_send??
20:43.33dlistarseeker, my first try to get strict build: basically, try to use intptr_t instead of int. but I don't understand tcl/tk enough to be sure I'm not break anything
20:43.37dlistarseeker, http://paste.pocoo.org/show/353112/
20:43.52dlistarseeker, it compiles at least
20:44.16starseekerdli: I'm still not clear, why are you trying to build Tcl/Tk strict?
20:44.44dlistarseeker, no, just want to enable -Werror generally
20:45.09dlistarseeker, the problem seems to be within tkTable part
20:45.28starseekerdli: src/other shouldn't be built with -Werror on
20:45.32starseekerit is expected that it would fail
20:46.30dlistarseeker, then, better to set that in autotools/cmake, so, users don't have to be worried
20:46.52starseekerCMake build should work correctly - it does in my testing here
20:47.03starseekerIf autotools is feeding -Werror to src/other it's a bug
20:47.50starseekerdli: you can try the CMake branch, if you like:  svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/branches/cmake brlcad-cmake
20:48.18dlistarseeker, just noticed the archlinux maintainer failed to update package version, because of -Werror
20:49.15dlistarseeker, I can submit a cmake ebuild to gentoo for brlcad-svn
20:49.23starseekerdli: what are you trying to do -  enable -Werror or disable it?
20:49.59dlistarseeker, I want users never get the -Werror trouble :(
20:50.06starseekersupplying --disable-strict to the autotools build should do that
20:50.13starseeker./configure --disable-strict
20:50.43dlistarseeker, I knew the solution, because I had to investigate and find out.
20:52.12starseekerthat should be documented in the INSTALL file
20:53.00dlistarseeker, also, I feel if -Werror should be enabled by correcting the code itself, if possible
20:54.58starseekerfor src/other that's a VERY large task
20:55.18starseekerwe don't maintain those codebases (with a couple exceptions) so you'd have to get the patches accepted upstream
20:56.06dlistarseeker, if so, probably, upstream will address the problem, just have to wait
20:56.15starseekerthe BRL-CAD code itself is very clean (thanks mostly to brlcad) but the src/other code is another story
20:56.40starseekerdli: it's pretty rare, in my experience, to have code bases that build well using strict flags
20:57.38starseekeradmittedly things are slowly getting better, both in the compiler world and overall open source community, but it takes time - if it works, it's usually not a high priority to clean up all those pesky warnings
20:58.30dlistarseeker, the tktable part keeps casting int to a pointer, it may be undefined behavior eventually :(
20:58.49starseekeryeah, tktable code I remember as being a tad noisy
20:59.04starseekerthey're actively developed though, IIRC - you might try talking to them direct
20:59.10dlistarseeker, as far as the pointer has to go beyond 32bit
20:59.38starseekeryeah, I think this is it:  http://tktable.sourceforge.net/
21:00.05starseekerhttp://sourceforge.net/projects/tktable/
21:00.41*** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net)
21:01.31starseekerif they don't want to take patches that are genuine bug fixes, we can patch our tree - but better to try upstream first
21:02.07dlistarseeker, I will try cmake tree first
21:02.34starseekerdli: that doesn't have any different code in src/other
21:02.49starseekerit quiets the warnings, but the code that prompted them is still there
21:03.21dlistarseeker, as far as the -Werror trouble is shielded from users, it's good enough for me
21:04.12starseekerfeedng disable-strict to configure will also achieve that goal
21:04.25starseekerand not require using an experimental branch ;-)
21:05.44dlistarseeker, it works, but if I still don't like to see it in building scripts, even better, user can even enable strict build, but -Werror will be auto off for src/other/
21:07.53starseekerwell, you can give the CMake branch a whirl and see if it does what you want, but remember it's an experimental development branch
21:09.38dlistarseeker, I want to work on something of relevant openNURBS, to help me understand the code base, so I can get to the intersection part
21:10.18dlistarseeker, any suggestion within an area relevant to oN for me to work on?
21:10.26louipcis disable-strict for the top configure script really needed anymore?
21:10.38louipcI thought all the warnings were cleaned up recently
21:10.50dlilouipc, needed:(
21:11.17dlilouipc, but it works for 7.18.2 and -svn
21:11.35dlilouipc, I mean --disable-strict-build works
21:12.02starseekerlouipc: from what dli is saying, it sounds like -Werror is leaking down into src/other somehow
21:12.14louipchmm ok
21:12.27starseekerdli: do you want to start coding right away?
21:12.42dlistarseeker, I thought I already started :(
21:12.54starseekerI mean, writing openNURBS related C code
21:12.58louipc:D
21:13.10dlistarseeker, yes
21:14.07dlistarseeker, have been reading oN wiki, still need more exercises to understand more
21:15.10starseekerdli: brlcad is the better one to ask - I'm a little biased when it comes to openNURBS.  I'm trying to make a standalone NURBS library based on it with the intersection and tessellation functionality added on
21:15.22louipcstarseeker++
21:15.35louipcfork opennurbs?
21:15.52starseekernot really a fork, except insofar as is necessary to cleanly add functionality
21:15.52dlistarseeker, forking oN sounds too much :(
21:15.55starseekermore like build on
21:16.06louipcah
21:16.28starseekerdli: For BRL-CAD, I'd suggest looking into taking a NURBS surface and generating BoTs from it
21:16.45starseekerdli: that would be a relatively straightforward, high impact task
21:17.17louipcdli: the problem I find with opennurbs is that the development actually seems quite closed
21:17.45dlistarseeker, I will try that first, then
21:18.17starseekerdli: we can generate surface trees from NURBS already (we need that for raytracing) so they may help you
21:18.26starseekerwhere's that tessellation paper...
21:18.54starseekerhttp://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.142.3042
21:20.10starseekerI'd suggest not trying for closed volumes in the first attempt - just get a non-closed BoT representation of a brep primitive by generating triangles from all of its surfaces
21:20.29starseekerif you do that, that's enough for basic shaded display
21:21.00dlistarseeker, I will try :)
21:21.03starseekerlouipc: the openNURBS model for development is indeed closed - they aren't really running an open source project in the classic sense
21:21.23starseekerthey're just making it (much) easier for people to deal with 3dm files
21:23.19starseekerlouipc: if you're curious, my preliminary efforts are here:  http://libnurbs.git.sourceforge.net/git/gitweb.cgi?p=libnurbs/libnurbs;a=summary
21:24.33louipcoh nice
21:25.10starseekerthat's just a "starseeker's experimental project" thing, not related to BRL-CAD
21:25.35starseekerhopefully it'll someday be good enough to replace src/other/openNURBS, but we'll see :-)
21:27.06starseekerlouipc: I summarized the overall goals in this post:
21:27.09starseekerhttp://groups.google.com/group/openmanufacturing/browse_thread/thread/1895cc2eb4d98b6f/a2f3d29238dbcb08#a2f3d29238dbcb08
22:58.57starseekergrr
22:59.18starseekeranybody know anything about libpkg?  how does a client get a message back from a server?
23:00.56starseekeris dubious that the geometry service can successfully talk over pkg... there's some test code that throws stuff from a client to a server, but I see no printout of responses FROM the server and the test works only with its own internal server setup
23:13.37*** join/#brlcad cjdevlin (~devlin@d118-75-252-178.try.wideopenwest.com)
IRC log for #brlcad on 20110314

IRC log for #brlcad on 20110314

01:13.33*** join/#brlcad dli_ (~dli@dsl-69-171-148-245.acanac.net)
01:57.41*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
02:22.30``Erikum, tpkg.c is a trivial libpkg client/server thingiemajigger
05:33.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:43.04*** join/#brlcad Stattrav (~Stattrav@122.172.156.61)
05:43.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:00.49*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
06:00.49*** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
08:44.25*** join/#brlcad dli_ (~dli@dsl-69-171-148-245.acanac.net)
11:57.05*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:57.43dlomanMernin all
12:01.54starseeker``Erik: looked at that - but it appears to be a "the client talks, the server listens" setup
12:02.21starseekerdloman: did we ever get the geometry service to the point where the client and server communicate back and forth over the network?
12:03.10dlomanstarseeker: oh ya, one second
12:03.17starseekerbased on what I've seen so far, the client and server will each have to run both a server instance, with the client sending its info to the server in order for the server to communicate back
12:03.41starseeker(to the client'
12:03.45starseekers server)
12:04.07dloman....um, no :)
12:04.25starseekerno?
12:04.30starseekerno what? :-P
12:05.02dlomanone second, psudo afk
12:05.08starseekerk
12:05.49starseekerI've got to return some fans anyhow - if you can post how to get geomclient and geomserv to communicate meaningfully it would be a big help
12:06.05starseekerthe C++ code is hard to follow
12:07.13dlomanboth use libNet.
12:08.38starseekerdloman: I'm trying to write a client that doesn't use libnet
12:09.01dlomanalready got one in progress.
12:09.07starseekerI can send stuff to the server, but I can't figure out how to get responses back
12:09.37dlomanif you want, I can run u thru the code tomorrow
12:09.44starseekerthat'd be great
12:10.35starseekeryou're not in today, I take it?
12:11.29dlomannot, telework
12:11.59dlomanokay, sorry
12:12.10dlomanwas moving the laptops upstairs, hooking up, etc.
12:12.18starseekerthat's OK
12:13.29dlomanOkay, I am doing the java inteface thingy for ``Erik / guys upstairs
12:13.35dlomanand am using that as a protocol validation
12:13.44starseekernods
12:13.45dlomani have a minimal client already going in there.
12:13.52dlomanthat doesnt use libNet
12:14.03starseekerthe bit I'm interested in right now is how you're getting responses back from the server
12:14.21starseekerpkg_send I figured out finally, but it seems to be a one way street so far
12:20.10starseekerI send the "RUALIVE" thing, but where do I look in the pkg setup for the response?
12:20.43dloman...granted its a similar incarnation, java style.
12:20.50dlomanone second.
12:21.00dlomanlost mt Mt Dew, had to find it.  Priorities ya know
12:21.05starseekerhehe
12:21.13starseekerof course - cars don't run without fuel
12:21.33dlomanheh, well getting my 2 cyls going dunt take much :)
12:21.46dlomanokay,
12:21.47dlomanso
12:21.53dlomanon the geomserv
12:22.21dlomanwe will assume that a connection has already been established and that the server side has a valid Portal to communicate thru
12:23.04dlomanthe server also will have a PortalManager that will do all the selecting on all sockets (FDs)
12:23.16dlomanthe PM has a FD<->Portal mapping.
12:23.49dlomanwhen select returns a FD that is ready for read
12:24.01dlomana lookup on the mentioned map occurs
12:24.11dlomanand the Portal::read() fn is called.
12:24.33dlomanPortal::read() is simply a set of PKG calls
12:24.46dlomanprocess(), suckin(), process()
12:25.15dlomannow, the process() call will make pkg attempt to form a complete PKG msg
12:25.39dlomandue to C++ limitations in the arena of function pointers, I had to short circuit the PKG's callback functionality
12:26.15dlomannormally, when a pkg_conn is instantiated, it is fed a routing table
12:26.44dlomanpkg then routes incoming pkg msgs according to the 16bit pkg_type and this routing table
12:27.48dlomanin libNet, that routing table consists of a single type, and thus ALL pkg msgs are routed to Portal::callbackSpringboard
12:27.53dloman..which is static
12:28.59dlomanat this point, the bytes from the pkg data load are putinto a ByteArray object and the GS type is read
12:29.14dlomanGS type is the first 16 bits of the pkg data load.
12:29.18starseekerok, I think I'm with you
12:29.43starseekerit then deserializes the message and figures out what it's dealing with
12:29.58dlomanthe GSType is used in the NetMsg Factory to figure out which NetMsg deserial cstr to call.
12:30.03dlomanexactly.
12:30.24dlomanafter a successful deserial, the NetMsg Factory hands the completed message over to the NetMsgRouter
12:30.49dlomanNetMsgRouter is (right now) a simple subscriber/publisher setup
12:31.56dlomanso if there is no routing data for a GS NetMsg, then it's discarded
12:32.12dlomanlooking at GeometryService::registerMsgRoutes,
12:32.17starseekerok... where would it get routing data?
12:32.33dlomani see there is no mapping (currently) for RUALIVE
12:32.59CIA-14BRL-CAD: 03starseeker * r43858 10/geomcore/trunk/src/GS/CMakeLists.txt: Whoops, copy paste typo
12:33.35dlomanhrm, there are two netmsg types that are supposed to be handled by the Portal object, RemNodeNameSet and RUALIVE
12:33.46dlomani wonder why its not working...
12:34.03dlomani am debugging the gs with all the changes still, might be something there.
12:34.09starseekerk
12:34.18starseekerwas going insane on Sunday
12:34.36dlomanbut to answer your 'where does it get routing data from ' question: its all configurable.
12:34.56dlomanthe geomserve does it in GeometryService.cxx line 58
12:35.21starseekerdloman: as an aside, it sounds like we're paying a fairly high complexity price for being able to use C++
12:35.52dlomaneh, kinda.
12:36.09starseekernot a criticism, just curious - how come C++ instead of C?
12:36.14dlomanthe pkg complexity has been minimized (with lots of hairpulling and pain)
12:36.28starseekerright, but why not just do it the libpkg way in C?
12:36.34dlomanfrom what I understand, its from a few differnt sources.
12:37.02dlomandesire to have a C++ interface for the general public
12:37.22dlomanC++ lends itself to a plugin-able style app arch better than C
12:37.27dlomanand a few others i've forgotten.
12:37.31starseekerurm.  For the GS, that's kinda moot - the interface is the network protocol
12:37.44dlomanping brlcad, im sure he remembers all the reasons :)
12:37.55dlomannot really.
12:38.14dlomanthe design for the GS is to have modules of functionality that can be 'plugged in'
12:38.27dlomanaka, the STEPConverter plugin
12:38.32starseekeruh... that's on the backend
12:38.46dlomanyeah
12:39.35starseekerdloman: ok, well I've got to get those fans back - if you can debug why RUALIVE isn't doing anything I'd appreciate it :-)
12:39.44dlomankk
12:39.50starseekerthanks, bbl
12:47.19*** join/#brlcad Stattrav (~Stattrav@122.172.156.61)
12:47.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:33.57``Erikhm, the build stuff I added was just copying another file and updating it... BSD license is dandy with me *shrug* (I think that technically, my contributions are considered public domain)
13:44.23dloman``Erik: segfaulting in your magic endian converter in geomcore
13:45.10dlomanthe whole dat[0] ^= data[7] ^= data[0] ^= data[7] block
13:47.48dlomanneed a little help there since i verified the data its manipulating is not NULL, but all those bitwise ops are beyond me :/
13:48.21``Erikhmmmm
14:07.06CIA-14BRL-CAD: 03erikgreenwald * r43859 10/geomcore/trunk/src/libNet/netMsg/GenericEightBytesMsg.cxx: use ntohll instead of the xor hack
14:12.50dlomanexcellent, thanks!
14:13.02``Erikthat fixed it? O.o
14:13.30dlomanwell, i had to put the htohll call down in the _serialize() fn too, but yeah, it seems to be working
14:13.36dlomanwell, it doesnt segfault anymore
14:13.47dlomanim going to validate the values in a second
14:13.56``Erikcool
14:14.24``Erikhttp://www.cnn.com/2011/POLITICS/03/13/crowley.stepping.down/index.html?hpt=T2
14:54.37starseekerdloman: is there a client/server setup anywhere (test app, whatever) that I can start up a server and client, type "ping" in the client and have the *client* (not the server) print out the server's *PONG* response?
14:55.10starseekeri.e. not a log message being generated by the server, but a command line report in the client of what the server's response was?
14:57.49dlomanyes, Im debugging that very thing atm
14:58.32starseekercool, thanks
14:59.04starseekerfeels another hair turn grey...
14:59.29dlomanhows the basement dewatering going?
14:59.57starseekerwe're pretty much dried out - the test now is to see what will happen with the pump actually in place
15:00.16dlomandid you do an op test of the pump?
15:00.40starseekerheh - that's what finally stopped the flooding from getting worse Thursday
15:00.47starseekerpump was working for a while to clear the backlog
15:01.04dlomanwell, nothing like a burn in :)
15:01.11dlomangood to hear you are all dried out.
15:01.27dlomansucky thing to be happening in a 'new' home :/
15:01.46starseekerno kidding - we're probably looking a this, roof and gutters this spring
15:11.06dlomanhe he, neat.  somehow, my PING messages are all originating from the same time... a long time ago, resulting in roundtrip times in the 3 million seconds range, lol
16:03.00dlomanis htonll a libbu thing?
16:03.13starseekerI don't believe so
16:03.47dlomani cant find info on htonll.... htonl, sure but not the ll version
16:03.59starseekerhttp://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.commtechref/doc/commtrf2/htonll.htm
16:04.35dlomanbah, bloody google was replacing text for me :/
16:04.55starseekeralso, see bu.h line 661 or thereabouts
16:04.56dlomanthanks :)
16:05.06starseekernot all platforms have it
16:05.11starseeker(apparently)
17:21.21CIA-14BRL-CAD: 03davidloman * r43860 10/geomcore/trunk/src/GS/GSClient.cxx: Clean up PING and PONG logging.
17:22.34CIA-14BRL-CAD: 03davidloman * r43861 10/geomcore/trunk/src/GS/GeometryService.cxx: Clean up PING and PONG logging on server side also.
17:25.22CIA-14BRL-CAD: 03davidloman * r43862 10/geomcore/trunk/src/libNet/netMsg/GenericEightBytesMsg.cxx: Fix a network/host ordering issue.
17:38.00*** join/#brlcad Stattrav (~Stattrav@117.192.138.246)
17:38.00*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:55.28starseekergets back to basics: http://beej.us/guide/bgnet/output/html/multipage/index.html
20:15.22``Erikhttp://bravenewclimate.com/2011/03/13/fukushima-simple-explanation/
20:38.03``Erikstarseeker: ISC license (like the new BSD), specifically for the mdoc macro package, http://mdocml.bsd.lv/
20:47.54starseekerawesome
20:49.45*** part/#brlcad willdye (~willdye@fern.dsndata.com)
21:01.08*** join/#brlcad willdye (~willdye@fern.dsndata.com)
22:01.23Ralithwhy do we need a new BSD?
22:02.07starseekerRalith: new BSD license (a.k.a Modified BSD license) - no advertising clause
22:02.39Ralithoh, so the "new BSD", not the new "BSD"
22:04.41starseekerright
IRC log for #brlcad on 20110315

IRC log for #brlcad on 20110315

01:40.16KimKHi, I can't install the 7.18.2 .deb in Ubuntu 10.04 due to dependency issues (my libncurses5 is too old, it's current). Would it be a reasonable project to compile BLR-CAD from source on my machine, or would I hit the same libncuses5 wall anyway?
01:40.52KimKs/libncuses5/libncurses5/
01:41.38KimKs/BLR-CAD/BRL-CAD/
01:42.26KimKis sure glad he caught those mispellings before that went out, whew!
02:19.33starseekermight be able to get his hands on a neo1973 phone...
04:02.21*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
04:23.18dli_KimK, still couldn't get 7.18.2?
05:35.40KimKdli_: Hi, I have the .deb of course, but gDebi says my libncurses5 is too old, I have 5.7+2009xxxx and it wants 5.7+2010xxxx or something. So I thought I might be able to persuade a dev to freshen the Ubuntu 10.04 libncurses5, but I haven't managed that yet either. I think even the Debian libncurses5 is too old. So then I thought, maybe compile from source on my machine? Anyway, no, BRL-CAD still not installed here.
05:39.57KimKdli_: And I have the source tarball, but I'm trying to learn git and brlcad is on Sourceforge with SVN. So I've been fiddling with git-svn to load the development source, I have done that several times, lol. Maybe Sourceforge's SVN doesn't play nice with git-svn? I haven't got that sorted out yet.
05:43.16KimKdli_: Thanks for checking on me. Any and all comments and advice appreciated. Again, I would like to install BRL-CAD on Ubuntu 10.04 LTS by any method. No hurry, I just wanted to try it and see what all the fuss is about, lol!
05:49.59KimKdli_: Pursuing this problem from another angle, I wonder if you could help me find out what OS the BRL-CAD developers are using, where they got this new libncurses5? I have virtualbox, and I'm getting the new Debian 6.0 DVD (slowly). If I installed Debian 6.0 in VBox, would I be able to install BRL-CAD there? Just thinking about other ways to skin the cat.
05:54.15Raliththere's fuss?
06:16.08KimKHaha, sure! Powerful and free/open, if perhaps not easy to learn and use? Such are the reports I hear, anyway.
06:21.54KimKIf it's in the same class as SolidWorks, and is free/open and Linux-friendly, I'd certainly like to have a look at it.
06:50.15*** join/#brlcad Stattrav (~Stattrav@122.172.156.61)
06:50.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:20.39*** join/#brlcad Stattrav (~Stattrav@122.172.156.61)
09:20.39*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:33.51*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
11:01.59dli_KimK, you may try to rebuild it. First make sure you have deb-src lines in your sources.list, then: apt-get build-dep brlcad; apt-get -b source brlcad
11:25.11CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2599 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Non-Uniform Rational B-Splines */
11:29.02CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2600 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Display Managers / Framebuffers */
11:35.11CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2601 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Graphical Interface Enhancements */
11:40.50CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2602 10/wiki/Google_Summer_of_Code/Project_Ideas:
11:49.36CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2604 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Project Ideas */
11:50.38CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2605 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Graphical User Interface Infrastructure Projects */
11:50.52CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2606 10/wiki/Google_Summer_of_Code/Project_Ideas: /* User Interface Enhancement Projects */
11:54.19CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2607 10/wiki/Google_Summer_of_Code/Project_Ideas: separate into two categories
11:56.57CIA-14BRL-CAD: 03Sean 07http://brlcad.org * r2608 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Tool Projects */
12:32.14``Erikit should build fine from source on any reasonably recent *nix... the developers use mac, freebsd, rhel and gentoo for the most part
12:53.49cjdevlinKimK: i have installed on 10.04 several times from source. i had no issues.
13:17.13*** join/#brlcad Stattrav (~Stattrav@122.172.156.61)
13:17.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:19.11cjdevlini just did a wget on this link: http://sourceforge.net/projects/brlcad/files/BRL-CAD%20Source/7.18.2/brlcad-7.18.2.tar.gz/download  
13:19.11cjdevlinand the tarball i got was 7.18.0?
13:31.54KimKdli_ , cjdevlin: OK, I will try building from source. I did try installing Debian 6.0 in Vbox and then installing BRL-CAD there, that seemed to work, but I'd prefer to have BRL-CAD on my main screen. So this MGED is the main app screen? Are there tutorials on the Wiki? I looked at the wiki and downloaded a bunch of manuals, but I'm starting from zero here, and this doesn't look like any other CAD program I've ever run across. Anything on YouTub
13:31.54KimKe? Where do you recommend newbies begin?
13:31.57KimKOpps
13:32.01KimKOops
13:32.37cjdevlinthere is a tutorial on the wiki. before you try to build run: sh autogen.sh
13:33.25cjdevlinthe tutorial is still *pretty* close, but there are some inconsistencies.
13:33.36cjdevlindid you ask about this in the ubuntu forums a week or so ago?
13:33.41cjdevlinubuntu irc*
13:36.29KimKOK, thanks, I will. That's not in the wiki? I may have asked about updating libncurses5, were you there? I didn't really get anywhere with that though. Where does everybody put the tarball if they might want to have SVN later too? I presume SVN (devel) is broken once in awhile?
13:37.50KimKOr do I have to pick one or the other and use only ~/brlcad/ ?
13:38.26cjdevlinthe tutorial is available . . . let me see if i can find it. i kind of remember something like that when i first tried to build. autogen took care of it. you can use checkinstall to install programs as a 'package'
13:40.43cjdevlinhttp://brlcad.org/wiki/Documentation
13:41.13cjdevlinthe introduction to mged is a complete tutorial. you can be up and running in a few hours if you can sit that long :-)
13:41.59cjdevlinand the code is hosted on sourceforge: http://sourceforge.net/projects/brlcad/files/BRL-CAD%20Source/
13:42.13cjdevlinsourceforge went down a few weeks ago, but that is very uncommon
13:42.22KimKOK, thanks for looking. I was just thinking that it would be nice to have both the tarball source for the latest release version and the SVN source for the devel version, even if broken sometimes, but I don't want to do anything that's non-standard. Who knows, maybe I can even help later on.
13:43.41cjdevlini am not a developer. i am relatively new myself. the guys that really know what they are doing read the logs, so if you stay logged on long enough you will definitely get the help you need/want
13:44.24cjdevlinare you building now?
13:44.25KimKYes, I was wondering about sourceforge. I'm a git fan and I tried to download with git-svn, which I've done before other places. But it didn't seem to work, it started, then stalled out. If I use SVN, it works fine.
13:44.56cjdevlinfor sourceforge i usually just do a wget
13:45.23KimKThat doesn't work for SVN, does it?
13:45.27*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:47.25cjdevlinnot sure. i have never tried it. i have just stuck with the stable releases so far.
13:48.49KimKHa, thanks for the tip about staying logged on. I'll add this channel to my auto sign-on. A friend of mine has access to 1 seat of SolidWorks, but that may turn out to be temporary, who knows? So it would be good if I could learn BRL-CAD as an alternate. But I'm more in favor of it becasue of the free/open thing. SW may be nice, but I don't own it. I can own BRL-CAD.
13:50.20cjdevlini know a windows version is in the works and they are converting from autotools to cmake for cross platform-ability </madeupword>
13:50.49cjdevlinare you trying to build now?
13:53.08KimKNo, I haven't tried yet. I was still wondering about whether the tarball/scripts/automake/etc will be happy if I put them someplace besides ~/brlcad/ ? Can I put it anywhere?
13:54.46cjdevlinyes.
13:54.58KimKHow about ~/brlcad7182/ ? Would that be OK?
13:55.18cjdevlini download all of the files i build into ~/source/<nameofprog>
13:56.05cjdevlinwhen you extract it, it will create a directory in a format of: brlcad-7.18.2
13:56.21KimKOK, I'll try that. I usually use git, so I haven't done a tarball for anything yet. But that sounds OK.
13:56.53cjdevlinit's just a compressed version.
14:00.29KimKThe wiki mentions ./autogen.sh is that what you meant when you wrote  sh autogen.sh  ?
14:01.37cjdevlinyes, that does the same thing
14:02.06KimKOK. I hadn't seen that sh before, just the ./
14:03.06cjdevlin./ runs executables, sh invokes the shell directly. *.sh is the shell file type, so ./ will call the shell anyways
14:03.19dlomanMernin all.
14:03.32KimKWait, before I do that, wasn't there some brlcad-build-essentials or something? Let me scroll back...
14:03.59cjdevlinregular build-essentials
14:04.41KimKbrlcad-dev maybe? I thought there was something. No?
14:05.09KimKI should already have build-essentials
14:05.32KimKOK, I'll try it and see if it warns me
14:05.36dlomanI know i'm jumping in the middle of this and havent read the backlog yet, but are you trying to get brlcad built from source?
14:05.46KimKYes, I am.
14:05.54KimKHI, thanks for asking
14:06.02cjdevlinthere are no ubuntu brl-cad dev packages.
14:06.14KimKOK, thanks.
14:06.29dlomanKimK: having problems then?
14:09.10KimKWell, had some other problems before, but just starting to build from source right now. OK, it says it's prepared and to run ./configure and then make. I'll start it.
14:09.49dlomanyou have multicore machine?
14:12.07dlomanMy oh my, things are looking grim at the Dai-Ichi plant in Japan....
14:13.27KimKNo, one core. And I run 32-bit Ubuntu even though it's an AMD64 (small, cheap one though) because I stick with the EMC2 folks and 64-bit real-time isn't quite soup yet.
14:14.05dlomanokay then, you're in for a bit of a wait.  brl-cad takes a while to build.
14:15.39KimKI saw one medium-sized warning about >>>>>>>>>>>>>Floating Point May not be Compatible>>>>>>>>>>>> or something. And a couple of small warnings. But it didn't stop, it completed. It said type make, so I did.
14:15.50dlomanright on.
14:16.11dlomanif configure succeeded, then you are probably good to go.
14:16.20dlomanthe make will take some time, though.
14:16.58cjdevlinKimK: i had the same issue w/ the libncurses i think. running autogen.sh took care of it for me. i had the same floating point warning, but haven't run into an issue yet.
14:17.42cjdevlinjust built on a sempron: Elapsed compilation time: 1 hour, 5 minutes, 24 seconds
14:17.42cjdevlinElapsed time since configuration: 1 hour, 7 minutes, 30 seconds
14:17.46cjdevlinnot too crazy :)
14:20.28KimKOK, no problem. cjdevlin , dloman , thanks very much for your help. Ha, I was just going to ask if it would be about an hour or more. I have a recent but unremarkable motherboard, 4G of ram (well, 3.7after the on-board-graphics robbery), and a cheap proc.
14:21.22dlomanas long as you can afford the time, then 1+ hrs is no biggie :)
14:22.04cjdevlinKimK: the machine i built on is a fossil of sorts. it shouldn't take you quite that long.
14:22.28cjdevlinbut if you are planning on upgrading/working on release code often, i would recommend using checkinstall
14:22.33KimKDon't feel like you guys have to stick around. If you've got someplace to go, go. Thanks for your help. I might let it run and come back later myself. Should I follow the wiki "build from SVN" (skipping the SVN part) to finish the install? I saw some stuff about adding symbolic links and so forth.
14:23.23dlomanoh I work here, so I'll be here all day =D
14:23.34KimKHa, OK, thanks.
14:26.20*** join/#brlcad PrezKennedy (MK@2607:f0d0:3001:68::2)
14:28.57dlomansimply put, after the 'make' is finished, you can 'make install' to install the compiled binaries to your machine.
14:29.11dlomanthen just run any of them from the command line.
14:29.24dlomanits likely you are looking for the graphical editor: mged
14:31.00KimKHa, you're ahead of me, but I had already started typing: OK, so (reading from wiki) when make is done, make test, make benchmark, make install, bunch of symbolic links, fis the path, benchmark, mged. Does that sound about right?
14:31.21KimKs/fis/fix/
14:31.27dlomancould even be easier than that.
14:31.29dli_KimK, I still suggest you run the debian/rules script to build, better than checkinstall
14:32.11dlomanif you are installing to a dir that is already on your PATH, (and you have perms to do so) then it should be as simple as 'make install' then, once finished, 'mged'
14:33.27KimKdli_: OK, how do I do that? What do you suggest? dloman: Shall I fix the path first, when make is done?
14:33.49dlomanwhat os are you running anyways?
14:34.01dli_KimK, apt-get build-dep brlcad
14:34.14dli_KimK, apt-get -b source brlcad
14:34.26KimKUbuntu 10.04 LTS 32-bit with EMC2 special-patched RTAI real-time kernel.  
14:35.30dlomanKimK: at the end of the ./configure run, did you happen to see where it said it was set to install to?
14:35.39KimKdli_: OK, can I do that while make is running?
14:36.29dli_KimK, oh, I didn't realize brlcad is not in ubuntu :(
14:36.35KimKdloman: No I didn't think to check, and I'm pretty sure it's scrolled off now. But I had deleted my ~/brlcad/ dir, so if it's back, it created it.
14:36.47dlomandli_: if KimK is already configured and compiling, why try getting packages via apt?
14:37.01dlomannm
14:37.30dlomanKimK: do you have sudo perms on this machine?
14:38.11dli_dloman, make install is basically bypassing apt, checkinstall should be avoided, whenever possible
14:39.00cjdevlindli_: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289632
14:39.21dlomanwhat are the detremental effects of compiling and installing manually?  Its never cause me a problem.....
14:40.08KimKdloman: Yes, my machine. I'm the owner. Hey, I really appreciate the help you guys. You probably all have a lot of experience with BRL-CAD now, but think back to when you first started with it. How long did it take before you could make simple cubes and cones and sort of have a clue what's going on with it?
14:40.21cjdevlindli_: why do you recommend avoiding checkinstall (just curious - as i have said, i'm pretty new)?
14:40.55cjdevlinKimK: if you work through that tutorial you can make a simple radio in the first 1/2 hour
14:41.57*** join/#brlcad piksi (piksi@pi-xi.net)
14:41.58dli_cjdevlin, if you have the debian/ script folder in source
14:42.02KimKcjdevlin: OK, I'll find it. I downloaded about any PDF I ran across.
14:43.40cjdevlindli_: i would think just running checkinstall would be easier for someone new that is just trying it out over dpkg-buildpackage or debuild?
14:44.55dli_cjdevlin, we need a debian/ubuntu repository, so user can do: apt-get build-dep, and apt-get -b source
14:46.55cjdevlindli_: i don't disagree with that, but at this point, afaik, that isn't an option?
14:47.09KimKdli_: I did apt-get --dry-run on those packages. It was as you guys suspected, they were both "E: Unable to find a source package for brlcad"
14:47.34dli_cjdevlin, I have no idea, I thought there must be a repository for brlcad already:(
14:47.53dli_couldn't believe it, gentoo seems to be the only one has brlcad in main tree
14:48.05KimK(And I've got something like 109 repos cranked in!)
14:48.19cjdevlinthere is not, the previous link i posted is the 'request for packaging' in debian (which will then make it into ubuntu)
14:48.57cjdevlinif the group would be so kind as to help me out, i wouldn't mind building/maintaining a ppa for brl-cad on launchpad
14:49.50CIA-14BRL-CAD: 03davidloman * r43863 10/geomcore/trunk/tests/utility/uuidTest.cxx: Minor print verbage change. Removed WS.
14:50.29KimKOh, BTW, make is done. Probably for a few minutes now. (Put your money into more RAM, every time, lol!)
14:51.28KimKcjdevlin: That would be great, ppa's are always a great convenience.
15:00.30CIA-14BRL-CAD: 03davidloman * r43864 10/geomcore/trunk/src/utility/Config.cxx: WS and Formatting.
15:00.40dli_cjdevlin, KimK just want to double check before 'checkinstall', what is your prefix during ./configure
15:01.30*** join/#brlcad PrezKennedy (MK@2607:f0d0:3001:68::2)
15:01.51cjdevlinafter make, just do: sudo checkinstall
15:02.06cjdevlinfor checkinstall you shouldn't have to do anything different
15:03.36cjdevlin(outside of making sure checkinstall is there: sudo apt-get install checkinstall)
15:12.31KimKOh, sorry guys, I was following the wiki. So far I've done make test and make benchmark. And I skipped ahead to fix the paths because I haven't quite figured out what to do with that bunch of symbolic links yet. Different versions installed at the same time? dli_ OK, how can I check the prefix? The directory I was building in was ~/source/brlcad-7.18.2  I have no knowledge of checkinstall, but I'll check up on it. OK, I have checkinstall now. I
15:12.31KimK<PROTECTED>
15:15.24dli_KimK, better to check config.log
15:17.02dli_KimK, if your prefix is /usr it mean mess up the whole system, better in /opt/brlcad, or /usr/brlcad
15:18.28KimKThere's a bunch of stuff in config.log, I'm not sure what you're asking for.
15:19.12dlomancan easily just run ./config again, and note the install paths at the end
15:19.44KimKWould you like me to pastebin the config.log file?
15:21.09KimKEspecially, how can I tell if this "mess up the whole system" thing has occurred?
15:21.31dlomanKimK: did you do a 'make install' ?
15:25.07CIA-14BRL-CAD: 03davidloman * r43865 10/geomcore/trunk/ (include/Config.h src/utility/Config.cxx): Added int and short getter to Config. Simplify via code consolidation
15:25.43dli_KimK, you can pastebin config.log
15:26.10KimKdloman: No, I haven't. I did the autogen thing, configure, make, make test, make benchmark, passed on make install, took a pass on the symbolic links, skipped ahead to fix the paths and wait for more advice, haven't got to benchmark and mged yet.
15:27.19dlomanThe sym links are an optional setup for having multiple versions of the brlcad libraries installed.  (its just standard ops for any libraries installed that require olderversions to remain on the system)
15:27.36dlomanso from this point on, if all you are trying to do is get mged up and running:
15:28.17dloman1) Verify your installation path by: either runing ./config again or check the config.log to see where the PREFIX path is set to.
15:28.28dloman2) 'mged'
15:28.33dlomanand you should be good to go.
15:28.57dli_dloman, what's the default prefix? /usr/loca/?
15:29.20KimKApparently that file is too big for pastebin. Do you guys have a place you like to post that file?
15:29.27dlomanI believe so.
15:30.09dlomanim on RHEL, but I'll check the default prefix here.
15:30.21KimKOK, running ./config again
15:30.36dli_KimK, only beginning part, like: head -100 config.log|wgetpaste
15:31.05dlomanlooks like /usr/brlcad/ is default for RHEL.. and likely ubuntu also.
15:31.53cjdevlinit is
15:32.16dli_ac_default_prefix=/usr/local
15:32.23KimKprefix: /usr/brlcad  Does that sound right?
15:32.32dlomanso as long as you have perms to install to /usr/brlcad, you should be gtg.
15:32.37dlomansure does.
15:32.40dli_AC_PREFIX_DEFAULT([/usr/brlcad])
15:32.50KimKThere are some subs below that too
15:33.06dlomanright.  standard stuff: lib, include, share.....
15:33.38KimKStill need the short pastebin?
15:33.55cjdevlinin the directory where you ran the config and make scripts, if brl-cad is something you sure you want, you can just do: sudo make install
15:34.13cjdevlinif you aren't sure (it's something you might want to remove) then you can look into using checkinstall
15:34.57dli_cjdevlin, always use checkinstall instead of 'make install', whenever possible
15:35.12dlomaneven if someone does a 'make install' and want to uninstall it later.... its as simple as rm -fr /usr/brlcad
15:35.18dlomanor even 'make uninstall'
15:35.25KimKI want it, but I might at some point want to upgrade to the next newer tarball. How would that affect things?
15:36.06dli_KimK, do checkinstall and let apt to handle it :(
15:36.20cjdevlinagrees with dli_
15:36.43KimKOh, OK. So just delete the dir ~/source/brlcad-7.18.2 and install new in ~/source/brlcad-7.18.4 (or whatever?)
15:37.18KimKOK, so use the checkinstall?
15:37.34KimKSorry, I'm a slow typer. Or I type to long.
15:37.44cjdevlinKimK: yes, use checkinstall
15:37.49KimKs/to long/too long/
15:37.55cjdevlinsudo apt-get install checkinstall
15:38.36cjdevlinthen in the directory where you did the config and make do: sudo checkinstall (and then just go w/ the defaults and a simple package desc. i.e. 'brl-cad')
15:38.38KimKI have checkinstall now. And abandon the make install that I never did?
15:39.04KimKAnd abandon the symbolic link business?
15:39.16dlomannot to argue, because checkinstall certainly is a good tool, but brlcad has its own uninstall rule plus it installs to its own directory, so its non-intrusive.  *shrug*
15:39.38dlomani use make install and make uninstall on my ubuntu 10.10 machine all the time.  never had an issue.
15:39.39cjdevlinKimK: checkinstall will essentially do the make install for you, but it will treat the install as if you had installed it via synaptic/apt
15:39.58KimKI don't mind running out of a directory. The EMC folks call that running-in-place.
15:40.03dlomanKimK: Yes, the sym link stuff is optional.
15:40.28cjdevlindloman: i agree with you also, but it's nice to have it come up when you do dpkg -l (esp when newer people need other help that this may affect)
15:41.00KimKThe EMC folks use run-in-place to have assorted versions of their programs all installed at once.
15:41.34KimKMaybe some call it compiled-in-place?
15:44.01KimKLet me ask you this. Assuming in the future there might be a release of brlcad-7.18.4 (as above), then I could have both .2 and .4 installed at once if I leave apt-get out of it? But if I use checkinstall twice, then apt-get will want to remove the older version, even though it's in a separate directory, is that right?
15:45.01cjdevlinKimK: both options allow for multiple installs. at this point it is up to you to determine which method is easiest for you.
15:45.13KimKSorry, I'm not really familiar with checkinstall, I'm just trying to get a handle on all this.
15:45.36cjdevlinbut either way it is very possible to have multiple versions of brl-cad installed concurrently
15:45.57cjdevlinand neither choice is really the *wrong* one.
15:48.54KimKWell, I don't mind whether I type 20 characters or 30 characters on the command line, but what I do know is that I'm pretty new at BRL-CAD, and I expect to install it again on other PCs, and there's a written procedure on the wiki that I can refer to again, however imperfect it might be. So I think I'd like to refer to the wiki just because it's written on the wall there, if you guys don't mind.
15:50.01cjdevlinit is your computing machine :-) and people will be here to help either way.
15:50.56KimKAnd this should not be taken as any type of criticism of you guys, I appreciate your help very much and am just trying to stumble my way through the jungle here.
15:51.03dlomandownload->autogen.sh->configure->make->make install
15:51.22dlomanif everything goes well, it should be that easy
15:51.52dlomanif some of the libs that brlcad needs are not present on the machine, then './config --enable-all'
15:52.04dlomanand brlcad will build everything it needs to run
15:53.37KimKOK, easy is good, lol! And until there's a PPA or a repo or something better, installing by tarballs in ~/source/brlcad_revision_number/  seems like an OK thing to do?
15:53.53dlomanyuppers.
15:54.10dlomanif you have any Winderz machines, the binaries are precompiled.  == even easier
15:54.54dli_looks like Nishchay is working on brlcad in debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289632
15:55.41KimKOK. So now to tidy up the loose ends here, I should just have to say make install? Then benchmark and mged?
15:56.04dli_KimK, checkinstall
15:56.18cjdevlinKimK: sudo make install
15:56.24cjdevlinthat will install it
15:56.43KimKcheckinstall? sudo make install?
15:57.06cjdevlinif you are trying to stick to the wiki, just do: sudo make install
16:03.24KimKI finally got around to the short pastebin, I just grabbed the first several hundred lines and pasted them. http://pastebin.com/WpBLDK6T
16:10.11KimKI looked at the bugs.debian link above, there was a git repo of BRL-CAD at Debian, at least in Aug 2010? Nice! It would be nice to think it's still there.
16:10.35dli_--prefix=/usr
16:18.00KimKdli_: What's that?
16:19.31dli_KimK, redo it :(
16:20.50dli_./configure --prefix=/opt/brlcad --with-opengl=/usr/lib --with-tcl=/usr/lib --disable-strict-build
16:21.04dli_KimK, this is what I use for archlinux
16:28.44dli_KimK, ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/brlcad/lib64 --prefix=/usr/brlcad --enable-strict-build --datadir=/usr/brlcad/share --mandir=/usr/brlcad/man --disable-almost-everything --disable-regex-build --disable-png-build --disable-zlib-build --disable-urt-build --disable-tcl-b
16:28.44dli_uild --disable-tk-build --disable-itcl-build --disable-tkimg-build --disable-jove-build --disable-tnt-install --disable-iwidgets-install --enable-opennurbs-build --with-ldflags=-L/usr/lib64/itcl3.4 -L/usr/lib64/itk3.4 --with-x --with-x11 --disable-debug --disable-optimization --disable-runtime-debug --disable-verbose --disable-warnings --disable-progress --disable-documentation --enable-models-install --enable-parallel --with-ogl --with-jdk=/opt/
16:28.45dli_sun-jdk-1.6.0.24
16:29.42dlomanwow, thats a heck of a config line... why you need all that?
16:31.54KimKOK, it ran the benchmarks in 9:23 and mged gives me a big black screen and a smaller white screen. Of course, I have no clue what to do with either of them, lol! But I think it's working. And I do thank all you guys for your help, I really appreciate it. I'll keep hanging around here, but first I've got a lot of intro manuals and tutorials to look at. Thanks!
16:32.44dli_dloman, not sure, it's autogenerated from gentoo ebuild
16:49.37KimKI have to go now, but I'll leave this window open in case you guys think of any advice for me while I'm gone. Thanks again.
16:52.27dli_Benchmark results indicate an approximate VGR performance metric of 4859
18:16.42*** join/#brlcad Stattrav (~Stattrav@117.192.138.203)
18:16.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:27.13starseekerdloman: as long as I'm asking dumb questions, is this of any interest to us?  http://s11n.net/
18:30.37dlomanmaybe, i had looked at generalized object serialization, but thre are some limitations associated with it.  Not to mention that we really dont need to send an entire object across the net, usually just specific pieces fo data.
19:23.31CIA-14BRL-CAD: 03starseeker * r43866 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Nothing useful yet with testclient - just a note that raw msg types down the socket isn't going to cut it for any msg type, even simple cases.
21:26.59CIA-14BRL-CAD: 03starseeker * r43867 10/geomcore/trunk/src/GS/testclient/ (CMakeLists.txt gstestclient.c tpl.c tpl.h): OK, start over with testclient. First job is to put together a valid GSNet Msg to send. Have a look at tpl and see if it can be of any help for this.
21:53.41CIA-14BRL-CAD: 03starseeker * r43868 10/geomcore/trunk/src/GS/testclient/gstestclient.c: get as far as getting what's expected into a struct.
22:04.06CIA-14BRL-CAD: 03starseeker * r43869 10/geomcore/trunk/tests/CMakeLists.txt: Don't want the value in the cache - just set it locally so only the tests directory gets it.
22:46.39starseekerO.o http://automagically.de/g3dviewer/
23:34.55*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
IRC log for #brlcad on 20110316

IRC log for #brlcad on 20110316

00:05.42*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
07:19.39*** join/#brlcad Moonies (~Bongle@unaffiliated/moonies)
07:33.43*** join/#brlcad Stattrav (~Stattrav@122.172.6.40)
07:33.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:07.08*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
09:43.44*** join/#brlcad Moonies (~Bongle@unaffiliated/moonies)
10:35.55dlomanMernin all
10:46.36dlomanlol, awesome: http://www.myfoxboston.com/dpp/news/boy-body-slams-bully-20110315#
11:07.39*** join/#brlcad Stattrav (~Stattrav@122.172.6.40)
11:07.39*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:18.30brlcadsends greetings from Scotland
11:18.40dlomanhey there slick!  Vacation?
11:19.02brlcadyep
11:19.17dlomanawesome!  Whereabouts in Scotland are ya?
11:19.36brlcadwestern highlands, argyll by tarbert
11:20.13brlcad*really* close to Islay .. going to take the ferry and check out the Morrison distillery tomorrow :)
11:20.28dlomantee hee.  awesome stuff man.
11:20.31dlomanenjoy!
11:21.12dlomanI never made it up to the western side.  I stuck near Edinbough and north
11:21.19dloman..well, and Glasgow
11:21.48dlomanbut there was a Football riot in the streets at the time and police wouldnt let us 'obvious americans' out of the train station :)
11:22.30dlomanwhats the itinerary?
11:38.12*** join/#brlcad Elrohir (~kvirc@p5B14A350.dip.t-dialin.net)
11:51.36*** join/#brlcad merzo (~merzo@193.254.217.44)
12:01.05*** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net)
12:18.59*** join/#brlcad juan_man (~quassel@201.255.35.237)
12:19.06*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
12:25.31*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ)
12:26.13*** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ)
13:38.19*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:44.16*** join/#brlcad Stattrav_ (~Stattrav@122.172.6.40)
13:56.06dlomanstarseeker: so that whole IDE issue i was having yesterday is due to the most recent java 'upgrade'  ...grrrr.
14:48.31dlomanstarseeker: two compile errors in geomcore:
14:48.37dlomanCMakeFiles/gstestclient.dir/gstestclient.o: In function `create_new_msg':
14:48.38dloman/home/dloman/devel/geomcore/trunk/src/GS/testclient/gstestclient.c:61: undefined reference to `uuid_generate'
14:48.41dloman/home/dloman/devel/geomcore/trunk/src/GS/testclient/gstestclient.c:63: undefined reference to `uuid_unparse'
14:58.49CIA-14BRL-CAD: 03davidloman * r43870 10/brlcad/trunk/: Add some IDE (Eclipse) config files to svn:ignore. They are personal prefs and don't belong in the repo... ever.
15:06.22CIA-14BRL-CAD: 03starseeker * r43871 10/geomcore/trunk/src/GS/testclient/CMakeLists.txt: Look for a UUID library
16:14.53dlomanneat, visual SVN commit history: http://www.youtube.com/watch?v=rh7uo2gxLdA&feature=player_embedded#at=41
16:55.44CIA-14BRL-CAD: 03starseeker * r43872 10/geomcore/trunk/src/GS/testclient/ (tpl.c tpl.h): Hmm forgot to remove the executable bit from these
16:57.08CIA-14BRL-CAD: 03starseeker * r43873 10/geomcore/trunk/src/GS/testclient/ (tpl.c tpl.h): Re-add without exe flag set
17:33.16CIA-14BRL-CAD: 03starseeker * r43874 10/geomcore/trunk/src/GS/testclient/CMakeLists.txt: Hrm. Probably can't use tpl unless both client and server use it
17:33.43CIA-14BRL-CAD: 03starseeker * r43875 10/geomcore/trunk/src/GS/testclient/ (tpl.c tpl.h): remove files too
18:05.21*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
18:08.11CIA-14BRL-CAD: 03starseeker * r43876 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Remove tpl.h include
18:14.09*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
18:19.10*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
18:23.47CIA-14BRL-CAD: 03bob1961 * r43877 10/brlcad/trunk/src/libged/rt.c: Fixed a Windows related bug in _ged_run_rt (i.e. no longer using a fixed size char array to hold the command for CreateProcess.
19:26.25CIA-14BRL-CAD: 03starseeker * r43878 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Sigh. give libpkg another try in the interests of time. This is still not the way to form the correct buffer for geomserv - serialization needs to work correctly for anything to happen.
19:33.50*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
19:44.13*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
21:43.51*** join/#brlcad dli (~dli@dyn-216-212.wireless.concordia.ca)
22:46.33*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
23:01.39*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
IRC log for #brlcad on 20110317

IRC log for #brlcad on 20110317

03:30.37*** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net)
03:40.54*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
03:53.04*** join/#brlcad Nohla (~Nohla@64.76.19.227)
08:40.55*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
10:25.29*** join/#brlcad Stattrav (~Stattrav@122.172.6.40)
10:25.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:02.54*** join/#brlcad dnk-88 (dnk-88@79.170.106.89)
12:12.41*** join/#brlcad Stattrav (~Stattrav@122.172.6.40)
12:12.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:46.41starseekerdloman: around?
13:50.21CIA-14BRL-CAD: 03starseeker * r43879 10/brlcad/trunk/src/other/tcl/ (3 files in 2 dirs): Try and work around http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44981 for Tcl
14:39.45CIA-14BRL-CAD: 03starseeker * r43880 10/brlcad/trunk/src/other/tcl/unix/configure.in: This flag apparently isn't supported by some versions of gcc on OSX...
14:41.53CIA-14BRL-CAD: 03starseeker * r43881 10/brlcad/trunk/TODO: need to fix dem-g...
14:45.21*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
14:46.03CIA-14BRL-CAD: 03starseeker * r43882 10/brlcad/trunk/src/other/tk/unix/configure.in: Remove this flag from tk too.
15:07.03CIA-14BRL-CAD: 03starseeker * r43883 10/brlcad/trunk/src/libdm/focus.c: Hmm - looks like we need the workaround in focus.c too
15:07.29starseekerconfound it, that may not work after all... not getting redefined, must have been hidden by -w in src/other/tcl
15:25.05starseekerauugh, autotools is annoying...
15:36.29CIA-14BRL-CAD: 03starseeker * r43884 10/brlcad/branches/cmake/ (9 files in 6 dirs): MFC r43883
17:30.43*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
17:39.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:42.35*** join/#brlcad dnk-88 (~dnk-88@79.170.106.89)
18:22.45*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
18:34.47*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
18:42.51*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
18:48.21*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
18:53.22*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
18:59.57*** join/#brlcad PrezKennedy (MK@whitecalf.net)
19:05.07*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
20:10.37*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
21:30.15CIA-14BRL-CAD: 03starseeker * r43885 10/geomcore/trunk/src/GS/testclient/gstestclient.c: This all needs to go in as one buffer...
21:35.54*** join/#brlcad dli (~dli@dyn-216-243.wireless.concordia.ca)
21:56.40CIA-14BRL-CAD: 03starseeker * r43886 10/brlcad/trunk/src/other/iwidgets/generic/scrolledwidget.itk: Use ttk scrollbars in iwidgets
22:06.29*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
22:12.21*** join/#brlcad dli (~dli@dyn-216-243.wireless.concordia.ca)
22:36.24*** join/#brlcad micges (~ddd@bxq170.neoplus.adsl.tpnet.pl)
22:40.44*** part/#brlcad micges (~ddd@bxq170.neoplus.adsl.tpnet.pl)
23:13.38brlcadthe food here is so awesome
23:13.56brlcadburps and awol for a lil while longer
IRC log for #brlcad on 20110318

IRC log for #brlcad on 20110318

02:45.26*** join/#brlcad dli (~dli@dsl-69-171-148-245.acanac.net)
03:22.24*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
09:44.57*** join/#brlcad merzo (~merzo@193.254.217.44)
10:31.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:30.00*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
15:18.58CIA-14BRL-CAD: 03starseeker * r43887 10/brlcad/branches/cmake/src/other/iwidgets/generic/scrolledwidget.itk: MFC r43886
15:21.38CIA-14BRL-CAD: 03starseeker * r43888 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Enable 'q' for quit in Archer
16:13.12CIA-14BRL-CAD: 03starseeker * r43889 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Another failed attempt at packing and sending a gsnet msg
18:44.23*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
19:52.00*** join/#brlcad flyanarchy (~chatzilla@46.112.188.170)
19:52.55*** part/#brlcad flyanarchy (~chatzilla@46.112.188.170)
20:29.06yukonbob_yay BRL-CAD!!1!
20:29.19yukonbob_congratulations on Yet Another GSoC :)
20:29.28starseekerhmm?
20:29.32starseekerdid they announce something?
20:29.41yukonbob_http://www.google-melange.com/gsoc/program/accepted_orgs/google/gsoc2011
20:30.58starseekerhmm - cant' get it to load
20:31.05starseekeryukonbob_: thanks for the news!
20:31.27starseekerwoo-hoo!
20:31.33yukonbob_of course :)
20:31.50starseekerapparently I wrote fast enough last week :-P
20:32.08yukonbob_now to find out how many positions are allotted...
20:34.11starseekerwe'll have to wait til brlcad sobers up :-P
20:35.40starseekerhehe - Google Open Source Programs Office is listed as an organization
20:35.49starseekernow THAT's an "inside track" :-P
20:36.49starseekerhmm - CGAL is accepted too
20:37.06starseekerthere'll be some competition for the geometry-aware students
20:37.18dligood job
20:37.41dlisupport for how many students?
20:37.46starseekerAha - Isabelle is listed.  Wonder if that's the theorem prover
20:37.53starseekerdli: don't know yet
20:38.11starseekersweet - hugin is back
20:38.40starseekerLibreOffice too - wonder what ideas they're pitching for students.  
20:40.06dliTheoretical Biophysics @ Humboldt University , this one is weird
20:40.13dligoogle supporting university directly
20:40.26starseekerdli: Google's been pretty good about supporting scientific stuff in the past
20:40.40starseekerah, here we go:  http://wiki.documentfoundation.org/Development/Gsoc/Ideas
20:41.04starseekerR Stastical program is good to see there - that's a nice tool
20:41.58starseekerAh, OGRE too - wonder if some student will volunteer to replace FreeImage...
20:42.32starseekerRockbox!  sweet
20:48.07Ralithrockbox is still alive, huh?
22:28.19starseekerruns rockbox on his ipod
23:12.20willdyeCongrats on making the Google Summer of Code.
23:52.12Ralithran it on his old iriver
23:52.17Ralithwas awesome but slightly unstable
23:52.23Ralithplaying doom on it was hilarious, though
IRC log for #brlcad on 20110319

IRC log for #brlcad on 20110319

01:13.03*** join/#brlcad niels_horn (~niels@189.106.85.17)
01:14.32niels_hornHi. I'm having an issue building brlcad 7.18.2 on Slackware (I'm the package maintainer of brlcad on Slackware)
01:16.16niels_hornit complains in /src/conv/patch/patch-g.c when buildind
01:16.28niels_horn*building
01:17.35niels_hornThe message is [xxx] "may be used uninitialized in this function"
01:18.46niels_hornin line 1936, where [xxx] = abi, aci or adi
01:19.56niels_hornI "solved" it with a sed command in the SlackBuild script (=build script)
01:20.33niels_hornsed -i "/patch_g_CFLAGS/s|\${STRICT_FLAGS}||" src/conv/Makefile.in
01:21.11niels_hornessentially removing the "${STRICT_FLAGS}" for patch-g.c
01:21.37niels_horn(sorry for the flood...) Any comments or suggestions?
01:28.26dliniels_horn, it's a known issue. do ./configure --disable-strict-build
01:33.51niels_horndli: great, will try that...
01:34.20niels_hornis there a forum or any place to find the "known issues"? :)
01:35.03dliniels_horn, I don't know. just come here. people are quite supportive for end users
01:35.38niels_horndli: ok, np... I hang out on freenode for the other channels anyway... Thanks!
04:10.43*** part/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
04:20.20*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
05:56.20*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
07:22.25*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
07:51.55*** join/#brlcad Stattrav (~Stattrav@122.172.6.40)
07:51.55*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:29.00*** join/#brlcad CIA-52 (~CIA@208.69.182.149)
14:00.45*** join/#brlcad Stattrav (~Stattrav@117.192.138.188)
14:00.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:23.12``Erikswank, we're back in gsoc
15:26.17``Erikniels_horn: I maintain the fbsd port with a reasonable amount of vigor, http://www.freebsd.org/cgi/cvsweb.cgi/ports/cad/brlcad/ for hints, and if you have any questions/concerns/issues, make some noise and we'll respond, usually within a few hours :)
15:28.55*** join/#brlcad Stattrav (~Stattrav@117.192.138.188)
15:28.55*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:37.58niels_horn``Erik: OK, thanks. I'll take a look there later!
15:38.50``Eriksure, and I read all the backlog, so just be patient waiting for a response :)
15:39.16niels_hornOK, np... :)
18:24.26*** join/#brlcad Stattrav (~Stattrav@117.192.138.188)
18:24.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:47.23*** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no)
20:40.48*** join/#brlcad Jesselnz (~jesse@ool-435573a5.dyn.optonline.net)
22:07.19*** join/#brlcad jarray52 (~bigbear@c-98-228-150-135.hsd1.in.comcast.net)
22:27.32*** part/#brlcad jarray52 (~bigbear@c-98-228-150-135.hsd1.in.comcast.net)
IRC log for #brlcad on 20110320

IRC log for #brlcad on 20110320

00:21.07*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
05:53.56*** join/#brlcad Stattrav (~Stattrav@117.192.147.2)
05:53.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:25.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:42.10*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
08:20.48*** join/#brlcad merzo (~merzo@237-129-133-95.pool.ukrtel.net)
09:04.47*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
14:40.07*** join/#brlcad Stattrav (~Stattrav@117.192.147.2)
14:40.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:46.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:10.11*** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
17:53.27*** join/#brlcad Stattrav (~Stattrav@117.192.147.2)
17:53.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:07.27*** join/#brlcad Stattrav (~Stattrav@117.192.147.2)
18:07.28*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:17.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:31.21*** join/#brlcad Stattrav (~Stattrav@117.192.147.2)
18:31.21*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:42.11*** join/#brlcad Stattrav (~Stattrav@117.192.147.2)
18:42.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:50.21*** join/#brlcad piksi (piksi@pi-xi.net)
20:31.51*** join/#brlcad Jesselnz (~jesse@ool-435573a5.dyn.optonline.net)
20:33.52JesselnzI'm hoping to participate in Google Summer of Code, and my idea is to implement a DWG importer based on LibreDWG. I'd appreciate some feedback on how valuable such a tool would be, and whether or not this could viably get accepted as a GSoC project.
20:43.30brlcadhello Jesselnz
20:43.40JesselnzHi
20:43.57brlcadthe idea sounds interesting, but the approach using libredwg is a problem (for us)
20:44.08JesselnzWhy is that?
20:44.09brlcadlicense is no good for integration
20:45.20brlcadthat library is GPL, so any tool developed against it would also need to be GPL or go through obtuse release integration steps making it practically infeasible
20:45.48brlcadthere are plenty of other, more interesting, converters needed -- is that your only interest?
20:46.17JesselnzDoesn't BRL-CAD have different components released under the GPL and BSD licenses?
20:46.25JesselnzAt least, that's the impression I was under.
20:47.27JesselnzWhat other converters are needed?
20:47.35brlcadJesselnz: the majority of source code is LGPL, build system and data files are BSD
20:48.53brlcadthe main ones desired is a step exporter, improving our step importer, and updating our existing iges importer/exporter
20:49.33JesselnzAlright, thanks.  I'll look into those.
20:50.01brlcadothers are listed here: http://brlcad.org/~sean/ideas.html
20:51.43brlcadJesselnz: if you're inspired, we're REALLY interested in code refactoring/cleanup projects -- one of which is establishing a code conversion library
20:52.31brlcadnuts and bolts infrastructure
20:53.20brlcade.g., turning our 20+ existing converters into library API with 100% clean common code reuse instead of self-contained binaries like they are now
20:53.53JesselnzSure, that sounds like an interesting project.
20:54.51brlcadif it's done perfectly, you wouldn't necessarily end up with an end-user visible change other than maybe some subtle consistency cleanup across converters
20:55.36brlcadmore details at http://brlcad.org/wiki/Geometry_Conversion_Library from our Project Ideas page
20:58.51*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110321 || BRL-CAD is participating in the 2011 Google Summer of Code! Students: speak up, ask quesions! :)
20:58.57JesselnzI'll definitely look into it.  Thanks for the suggestion.
20:59.02brlcadno problem
21:00.11brlcadstarseeker: CGAL has been participating for the past 2-3 years goo, not direct competition usually due to their funky license problems
21:00.45brlcadwilldye: thanks
21:11.30brlcadmmm, so I see nobody sync'd to trunk and posted the release!
21:21.35brlcadhah, gource uses ftgl
23:23.48starseekerhates global variables... grr...
23:24.27brlcadkill them!
23:26.45starseekeris trying, but it's not in our codebase
23:26.57brlcadthis is freaking awesome
23:27.07brlcadpulling up a visualization of brl-cad source history
23:27.13starseekercool!
23:27.28starseekerbrlcad: back I take it?  how was it?
23:27.38brlcadawesome
23:27.57starseekerhehe - welcome back to the letdown that is american food
23:28.53starseekerwhat's the visualization?
23:31.16starseekerscowls at sqlite... don't tell me...
23:34.52starseekerhrm.  No wonder they were using a global, that commit_hook doesn't pass any info...
23:35.41starseekerah, wait
23:35.56starseekerpCommitArg... what's that...
23:38.32starseekerbingo
IRC log for #brlcad on 20110321

IRC log for #brlcad on 20110321

01:04.12*** join/#brlcad Nohla (~Nohla@64.76.19.227)
04:16.11starseekerO.o https://github.com/pyb/zen
04:16.26starseekertoo bad it's GPL, but that's still nifty
06:57.52Ralithoo, neat
06:58.08Ralithmightn't it be better to target that X replacement canonical is backing though?
07:37.49*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:42.48*** join/#brlcad merzo (~merzo@193.254.217.44)
09:07.45*** join/#brlcad Stattrav (~Stattrav@122.172.6.40)
09:07.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:03.06*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
11:10.21*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:32.13dlomanMernin
11:36.54dlomanbrlcad: gource is a fun little tool =D
11:37.20dlomanbrlcad: did you do all of the brlcad commit history?  If, so, I'd love to see the visualization!
12:30.18brlcaddloman: yeah, the whole thing -- had to modify the source to get it to behave, but it works reasonably well
12:31.29brlcadthe physics unfortunately goes nuts with the whole tree causing the graph to get stuck
12:37.22dlomanso did it turn out at all?
12:37.54brlcadoh yeah, it works great "most" of the time
12:38.27brlcadit might work if it's allowed to incrementally build up from scratch
12:38.52brlcadit'll rebuild the tree from any point on the timeline, which is how you skip forward/backward .. and those tend to get stuck
12:39.01brlcadtrying to rebuild the massive tree after massive edits
12:39.18dlomancool, drop something on youtube if/when you get a chance :)
12:39.31brlcadhaven't found a good way to capture to video yet
12:40.21brlcadplus, even sped up to about 4days per sec, it's still like a half-hour video :)
12:40.38brlcadany faster and it's just a ton of whizzing about
12:41.00dlomantee hee
12:43.55starseekerhah, that is cool
12:44.12starseekerlike how it uses the little figures to indicate who's changing what
12:45.20starseekerbrlcad: if you could capture video(s), that'd be a really cool briefing tool
12:45.32starseekerdloman: you in today?
12:46.08brlcadstarseeker: I'm working on getting video .. I have one video screencast tool working, but it's shareware and watermarks the video
12:46.31brlcadthe tool itself will output ppm that would be a hell of a lot of frame data
12:46.44starseekerbrlcad: ah.  I think I stumbled on one or two tools that do opengl video specifically
12:47.18starseekerhttp://taksi.sourceforge.net/
12:47.31brlcadjust found that :)
12:48.24brlcadthe question du jour is whether it'll run .... bah, looks like it's windows only?
12:48.47brlcaddloman: so we're good to go needing a poster ;)
12:49.08brlcadone page of awesome
12:49.10dlomanstarseeker: not today no, tomorrow.  Whats up?
12:49.16starseekeryukon might be an option:  https://devel.neopsis.com/projects/yukon/
12:49.38starseekerdloman: I'm wondering how close we are to having commands in geomclient that could retrieve and send .g files
12:49.47dlomanbrlcad: I can work on it *after* march 31 =D
12:49.51dlomanclose.
12:50.03brlcadoh, that's way too late :(
12:50.07dlomancan't promise COB today, but def by COB tomrrrow
12:50.39Ralithlooks like gource can output a ppm stream itself
12:50.46Ralithwhich could then be encoded
12:50.47starseekeris trying to remember if yukon is how he made the videos of g3d...
12:51.07brlcadRalith: 08:46 < brlcad> the tool itself will output ppm that would be a hell of a lot of frame data
12:51.27brlcadmissing a 'but' in there
12:51.47dlomanbrlcad: sorry, but RL has kicked me square in the nuts and I have had to take a lot of time off... so i am behind with the GS.
12:54.21brlcadsomeone else will have to come up with something then, hopefully
12:54.22Raliththat's what I get for not keeping up.
12:54.24brlcadstudents are submitting applications by the 28th, so that's just way too late
12:54.31Ralithstill, too much data?
12:55.24starseekerbrlcad: ah - https://devel.neopsis.com/projects/yukon/wiki/RewriteBranch
12:55.36brlcadlooks
12:56.51brlcadstarseeker: looks like that only works with x11 glx contexts?
12:57.36starseekerpossibly
12:57.56brlcadI'd hate to go through all the steps again, but I might be able to crunch the frames out on a remote linux box with tons of disk, and convert to video there
12:58.53brlcadit was just a bit of a time sink to compile with all its deps, paying some lil shareware dev becomes appealing :)
12:58.55starseekernods - surprisingly, there just aren't a whole lot of good solutions (that I know of, anyway)
13:01.25starseekerdloman: do you think you could spare a little time from the java side to get the .g files moving back and forth?
13:04.25dlomanthat's what Im doing ;)
13:04.36starseekerdloman: cool, thanks :-)
13:05.06starseekergot his butt kicked by a bunch of topics he knows disturbingly little about last week - sorry for not being of more concrete assistance
13:05.21dlomanno worries
13:05.33dlomani havent exactly been productive recently
13:06.04starseekerdloman: that's not up to you - hope everything is going a little bette
13:06.07starseekerbetter even
13:07.54dlomanheh, its when things start going better that i get scared.  Murphey and his laws are having a field day ;)
13:09.07dlistarseeker, like undo/redo?
13:09.25starseekerdli: how's that?
13:09.53dlistarseeker, when you mentioned 'moving back and forth'
13:10.31starseekerdli: the most basic function of any client/server system is to communicate between client and server
13:10.53dlomanbrlcad: is there a quick way to print a bu_vlb to console or string as HEX ?
13:11.01starseekerdli: we have that (thanks to dloman) but we need to be able to send geometry back and forth
13:11.29starseekerdli: once we can communicate geometry files, we can think about how to store revisions of them
13:12.15starseekerdli: the next stage beyond that is to communicate just specific changes to parts of the .g files, and be able to retrieve specific versions of geometry from the server
13:12.27starseekerdli: the latter means revision control and is not easy
13:13.31starseekerdloman: yeah, if I ever run into Murphy I'm gonna have a word with him...
13:13.51dlistarseeker, not easy with .g format :( maybe, easier as database entries
13:14.31starseekerdli: basically what's needed is to customize version control software for our specific purposes
13:16.41starseekergathers up his stuff and heads in - first stop gym...
13:25.09``Erikunsigned char *p = bu_vlb_addr(myvlb); for(i=0;i<bu_vlb_buflen(myvlb);i++){ printf("%02x ",*p); p++; }
13:28.07dloman``Erik: thanks
13:30.37``Erik(there're tricks to make that shorter, but starseeker starts sobbing when I do those)
13:36.08CIA-52BRL-CAD: 03brlcad * r43890 10/brlcad/trunk/src/libbu/bitv.c: don't try to cat the str/title if it is null
13:38.37CIA-52BRL-CAD: 03brlcad * r43891 10/brlcad/trunk/ (include/bu.h src/libbu/vlb.c):
13:38.37CIA-52BRL-CAD: add a new bu_pr_vlb() routine for printing out diagnostic information for vlb
13:38.37CIA-52BRL-CAD: structures. optionally prefixed with a title, this prints out each byte as a
13:38.37CIA-52BRL-CAD: space-separated hex value. could probably use some pretty printing to group
13:38.38CIA-52BRL-CAD: together for readability, but go simple for starters.
13:38.55brlcaddloman: turned erik's one-liner into a new bu routine, bu_pr_vlb(), see if that's suitable
13:40.43dlomankk will try
13:40.44brlcaddli: unless I missed part of the conversation, it's not specific to .g data
13:41.34brlcadthe service allows transactional edits with history preserved, so it's just a matter of how to encode the transactions as commits
13:42.55brlcadthe simple way is to commit the honking .g file after each change, but that's not really efficient since it's an opaque entity to revision control systems - it's not easy to extract the semantic differences between two changes
13:47.42dlibrlcad, does it make sense to use a database backend, so, database queries can be logged (reverted), efficiency problem left to the database side
13:48.26brlcadthat's basically what's being done with the revision control system -- it uses a database backend
13:49.23dlibrlcad, oh, didn't realize that :(
13:49.37brlcadwe could implement revision tracking on top of some existing rdbms, but then that would basically amount to reimplementing a version control system (like git, svn, whatever)
13:50.09brlcadand even then, you'd still have the problem of storing/retrieving *semantic* information from the commit
14:00.13CIA-52BRL-CAD: 03davidloman * r43892 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (GSConnection.java msg/AbstractNetMsg.java): Move message serialization entirely over to AbstractNetMsg. Consolidates serialization logic.
14:16.44*** join/#brlcad Nohla (~Nohla@64.76.19.227)
14:26.42CIA-52BRL-CAD: 03davidloman * r43893 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/AbstractNetMsg.java: Forgot to serialize type. Ooops.
14:27.22CIA-52BRL-CAD: 03davidloman * r43894 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Remove debug printing. Kills performance when trying to print large bytebuffers.
14:27.54brlcadcould maybe add a size parameter
14:28.30dlomanit was a t-shooting debug print statement anyways :)
14:28.48dlomanturns out, printing a 1 meg byte array to console is slow.  who knew?!
14:32.23brlcadprobably someone ;)
14:32.33dlomanmost likely everyone :)
14:54.58``Erika lot faster if you dump it in a screen and swap, or pipe through less O.o the effort to display a linux kernel build in an xterm was a significant slowdown on my old 120mhz cyrix, went way faster when I put it in a screen and dropped it :)
14:56.41dlomannow that's a new one.  localhost just resolved to 127.0.1.1
14:57.07``Erikneat
16:02.17dlomanoh bloody hell.  the silly null character at the end of the string has the UUID parsing all bent out of shape :/
16:06.35CIA-52BRL-CAD: 03davidloman * r43895 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferReader.java: Validate parsed string is == 36 characters long to allow for proper UUID generation. The UUID 'standard' for the GSNet Proto needs to be standardized.
16:09.50CIA-52BRL-CAD: 03davidloman * r43896 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java: Fill out the NetMsgFactory's switching table so that NetMsg's can actually be deserialized
17:13.07CIA-52BRL-CAD: 03starseeker * r43897 10/brlcad/trunk/BUGS: Need to do some testing and confirm this, but have a report that keep is changing units to unknown on output files and dbconcating a file with unknown units wipes out the units in the parent .g
17:34.55*** join/#brlcad Stattrav (~Stattrav@117.192.135.62)
17:34.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:02.45*** join/#brlcad chinu (~chinu@27.97.161.172)
19:11.32*** join/#brlcad Stattrav_ (~Stattrav@117.192.134.3)
19:26.47*** join/#brlcad chinu (~chinu@27.97.124.40)
19:28.15*** join/#brlcad sofichinu (~sofichinu@27.97.124.40)
19:46.10sofichinuhii all, can anyone help me out for gsoc 2011 project  idea - Qt Display Manager
19:47.13starseekersofichinu: you've seen the posting on the website?
19:48.27starseekerhttp://brlcad.org/wiki/Qt_Display_Manager
19:51.12sofichinuyes i have gone through that link, and it says to review current display manager code. From where do i get to access that code?
19:51.36starseekerBRL-CAD's subversion repository:  http://sf.net/projects/brlcad
19:51.48starseekerspecifically, the trunk branch:
19:52.01starseekersvn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad
19:52.42starseekeralso a good idea to get BRL-CAD (specifically MGED) compiled and running to see what a display manager does
19:52.46sofichinuthnx :)
19:52.58starseekerno problem
19:56.01sofichinudo one has to use any ide for compiling the code, because I usually use g++ compiler in ubuntu for coding in c++
19:56.23starseekernope - most of use go with command line gcc
19:57.10sofichinuok
19:57.48starseekersofichinu: you have Qt experience?
19:59.11sofichinunopes, I started using it only after getting to know about it via gsoc
19:59.33starseekernods. Just curious - what appealed to you about that project?
20:01.08sofichinuto be honest , requirement skills for the project is C++ and I am good at this only :P
20:01.46sofichinuthis all made me interested in this
20:02.00starseekerfyi, OGRE is also C++
20:03.17sofichinuyes, many other organizations are, and I am trying to go deep into project ideas to find out which one is best for me.
20:03.35starseekerI was thinking more about the other display manager task - the OGRE display manager :-P
20:04.10sofichinuoh i am sorry,
20:04.19sofichinuI had started using Qt
20:04.29starseekerthe openNURBS library is also C++, if you're into mathematical stuff
20:04.33starseekersofichinu: Qt is fine too
20:04.34sofichinubefore and heard about OGRE now only
20:04.48starseekerwe're interested in both - if you're more comfortable with Qt that's great
20:05.28starseekeropenNURBS would pertain to the NURBS tasks on that list
20:06.24sofichinuwhich one gives more chance for getting into gsoc ?
20:06.38starseekerdepends on your proposal and the other proposals
20:07.02starseekerQt vs. OGRE won't be a make-or-break
20:07.09sofichinuhm...
20:08.30sofichinudo i need to make out some patch like usually many organizations demand that?
20:08.31starseekersofichinu: I'd suggest taking a quick look at both and see which one looks more managable to you
20:09.18starseekersee step 9:  http://brlcad.org/wiki/Google_Summer_of_Code/Checklist
20:10.21starseekersofichinu: what's your background/interest?
20:11.07sofichinuI am a student of 2nd year in Computer Science and Engineering
20:13.20starseekerwell, my advice would be to take a very quick look at Qt and OGRE - get a basic window up and draw a line, say, in both - just to get a feel which one you would prefer working with
20:14.55sofichinuok
20:15.39starseekerOGRE is an accelerated 3D context, and Qt is unaccelerated but runs (or should run) pretty much anywhere without requiring any fancy hardware
20:16.09starseekersort of the difference between our dm-ogl and dm-X
20:16.44starseeker(which is why OpenGL embedded in Qt is ruled out - the point of a Qt display manager would be "it always works")
20:17.03sofichinusorry but i did not get the difference still.
20:17.55starseekerOpenGL provides an accelerated graphics context - when you see objects rotating around in real time in 3D, it's usually OpenGL based (unless you're on Windows, which tends to use DirectX more these days)
20:18.15starseekertypically, the graphics card in the computer is assisting with the drawing when OpenGL is used
20:18.42starseekerRaw X11 (dm-X) does NOT use any specialized acceleration hardware - it uses only the X calls themselves
20:19.41starseekerwhich means the CPU has to do a lot of work instead of offloading it to the graphics card, but ALSO means if the graphics card (or drivers) aren't working you can still bring up the display
20:20.29sofichinuso can we say that Qt is better
20:21.12starseekerQt will work under more conditions
20:21.40starseekerbut it also won't be able to do things like shaded display and take advantage of graphics hardware when displaying really large models
20:21.52starseekerit's a tradeoff - that's why we're interested in both
20:22.13starseekerIdeally, you do accelerated when it's available and fall back to unaccelerated when it's not
20:23.10sofichinuhmm....
20:23.43starseekerso Qt would be using the 2D graphics stack:  http://cworth.org/talks/lca_2009/html/lca-2009-006.html
20:23.57starseekerand OGRE would be using the 3D http://cworth.org/talks/lca_2009/html/lca-2009-007.html
20:24.23starseeker(OK so those are Linux specific, but the general idea is the same)
20:25.40sofichinuand what about in windows terms
20:27.12starseekerThe Windows stacks look similar, just with different components at the various stages
20:27.14starseeker(e.g. DirectX instead of OpenGL)
20:27.24starseekerOGRE and Qt should abstract all that for us
20:27.38sofichinuok
20:28.29sofichinucant we implement the similar thing for OpenGL too?
20:28.35starseekersofichinu: I'd try playing with QtCanvas and see how it behaves - for example, can you get it to draw and update 2D lines quickly?
20:29.01starseekersofichinu: we can (in fact, we do - that's dm-ogl and dm-wgl) but OpenGL itself is not a fully cross platform API
20:29.36starseekerthat's why we have one for wgl (Windows), one for GLX (Linux), and we would need one for Mac if we wanted to get the native Aqua interface running
20:30.33sofichinuoh, I am actually downloading Qt, for sum reasons, I lost it
20:31.14starseekerIdeally, we would replace all of the platform specific display managers with one accelerated (OGRE) and one unaccelerated (Qt) display manager - between those two, we should get broad coverage of machine configurations and operating systems for minimal code
20:32.34starseekerMy guess would be that the main challenge with Qt will be figuring out how to do "fast enough" 2D drawing without relying on OpenGL
20:33.22dlior ogre simply figure out how to run without no 3d support underneath
20:33.54starseekerdli: that's a bit like saying you're going to figure out how to drive without a car :-P
20:34.22dlistarseeker, yes, because a bike is always available
20:34.54starseekerthe main point and benefit of OGRE is that it does take advantage of 3D acceleration
20:35.57starseekerif someone wants to propose an alternative toolkit for either the unaccelerated or the accelerated display manager that's fine, but they'll need to make a very good case for it
20:37.40starseekerissues to consider there are license compatibility, portability, how well maintained and widely used the toolkit is, etc.
20:38.34starseekerwe don't want to take over maintainance for a cross platform graphical toolkit - we want to use one that is already in good shape
20:39.02starseekerOGRE and Qt have a lot of momentum behind them and are licensed in a way we can use them
20:39.51sofichinuIts just like making a best deal from both of them.
20:46.57starseekersofichinu: this may be of interest:  http://labs.qt.nokia.com/2009/12/16/qt-graphics-and-performance-an-overview/
20:52.30*** join/#brlcad niels_horn (~niels@187.14.62.166)
22:32.38*** join/#brlcad ibot (~ibot@rikers.org)
22:32.38*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110321 || BRL-CAD is participating in the 2011 Google Summer of Code! Students: speak up, ask quesions! :)
23:23.12brlcadthinks we're good with a simple socket connection for the forseeable next couple years
23:23.54brlcadlocal port performance is going to be the main customer at first, not even over tcp, for the beginning (e.g., mged use)
23:24.57brlcadgetting beyond that and I'd want to start considering more advanced network services like automatic replication and persistance .... but only long after the protocol is established for simple net
IRC log for #brlcad on 20110322

IRC log for #brlcad on 20110322

00:24.54CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2609 10/wiki/Google_Summer_of_Code: /* [[Google_Summer_of_Code/2009|GSoC 2011]] */
00:25.09CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2610 10/wiki/Google_Summer_of_Code: accepted
00:29.33brlcadin theory, you should be able to get an accelerated and non-accelerated context from both Qt and OGRE -- it's really just what toolkit does someone want to use and which one will integrate best (be easiest to maintain)
00:30.21*** join/#brlcad Ralith (~ralith@d142-058-172-039.wireless.sfu.ca)
00:30.42brlcade.g., qt with an ogl context could be accelerated or it could be a pure raster context; ogre might be harder to get unaccelerated, but there's always software render ogl :)
00:32.41starseekerah, ok - I had assumed we would want to go with something like OGRE for accelerated in order to support more advanced work to come
00:37.59CIA-52BRL-CAD: 03starseeker * r43898 10/geomcore/branches/fossil/: Add a branch for some experiments
00:38.43brlcadogl for the dm definitely makes the most sense
00:38.55brlcadsomething that has scenegraph management
00:38.58starseekerplain opengl?
00:39.18brlcadplain ogl with custom scenegraph management is a bitch
00:39.33brlcadthat's where ogre becomes a big win over qt for the dm side
00:39.41brlcadfor the fb side, either would be a win
00:39.48brlcadfossil scm?
00:39.48starseekeroh, you mean OGRE for the dm?
00:39.54starseekeryes
00:39.59brlcadheh, neat
00:40.06starseekerBSD licensed as of mid last year
00:40.16brlcadnods
00:40.22starseekerI didn't notice at the time - would have hopped on it quicker
00:40.35brlcadyou know it's almost entirely built on sqlite?
00:40.37starseekeryep
00:41.30starseekerwasn't so worried about its backend storage mechanism as long as it doesn't cause us some kind of significant trouble
00:42.06starseekermore annoying is his fondness for global variables
00:42.12starseekerthat's what I was grousing about earlier
00:47.40CIA-52BRL-CAD: 03starseeker * r43899 10/geomcore/branches/fossil/ (17 files in 6 dirs): For now, clear other contents - keep the build logic simple during early phases.
00:53.22CIA-52BRL-CAD: 03starseeker * r43900 10/geomcore/branches/fossil/ (48 files in 8 dirs):
00:53.22CIA-52BRL-CAD: Add what work has been done so far - the first goal is to get db.c and
00:53.22CIA-52BRL-CAD: everything it needs compiling without warnings about implicit definitions. No
00:53.22CIA-52BRL-CAD: global 'g' structure with settings either - pass it properly, even if it does
00:53.22CIA-52BRL-CAD: mean updating all the functions to do it.
01:08.11CIA-52BRL-CAD: 03starseeker * r43901 10/geomcore/branches/fossil/ (CMakeLists.txt src/CMakeLists.txt): comment out dirs not active yet
01:15.41CIA-52BRL-CAD: 03starseeker * r43902 10/geomcore/branches/fossil/ (3 files in 2 dirs): add a content.h header to manifest and diff, fix accordingly.
01:56.57brlcadah, yeah
01:57.20brlcadit's endemic of fast but lazy coding
01:57.54brlcadgreat for getting things done, but crazy maintainability for new developers
01:58.32starseekermy favorite bit is he generates the headers based on what the .c files need
01:59.40starseekerbrlcad: is sqlite a concern?
02:00.02brlcadnope
02:00.25starseekerbreaths a sigh of relief
02:00.31brlcadimplementation detail that might affect scalability, but not a problem until it's a problem
02:01.16brlcadhave trouble seeing it scale to multiGB databases, but maybe
02:01.33starseekeryeah, huge meshes could be a problem
02:01.50brlcadsingle models could be a problem
02:02.06brlcadnot to even consider hundreds or thousands
02:02.45starseekerwell, ``Erik has some wicked test cases we can toss in
02:03.06starseekerbrlcad: I was kind of thinking one sqlite file per .g namespace...
02:04.23starseekerunder the hood, of course
02:04.31brlcadsingle db by itself is probably fine, thinking db with full revision history, hundreds of edits like you'd have if you start from scratch - that's where it'd get big
02:04.39brlcadyeah, possibly
02:04.48brlcadthat'd definitely be better than one honking db
02:05.14brlcadbut then merging/branching and linking across namespaces becomes really nasty, no?
02:05.23starseekerah, yeah - was thinking a few rotates and translates at the toplevel plus lots of xpushing for edit testing
02:05.26brlcadwith svn it was just across files using path convention
02:05.36brlcadall still within the revision system
02:06.09brlcadeither way, interesting test
02:06.09starseekerbrlcad: not sure how nasty it would be - I've been thinking about it, but nothing concrete to toss on the whiteboard yet
02:06.48brlcadget stuck with svn libs?
02:07.04brlcador looking for better performance?
02:07.14brlcador just having fun? :)
02:07.37starseekerheh - combination of the latter two
02:08.42starseekerI was hoping a "speak .g language" approach to the revision control would let us avoid the region breakout and still have reasonable performance, but looking at that level of subversion/apr just got downright scary
02:09.22starseekerfossil appealed because it's smaller, distributed and for a bonus has that web server stuff integrated
02:09.50starseekerthought it might be more practical to get it commiting individual geometry objects as binary blobs and checking out into .g files
02:10.45starseekerhowever screwed up its "yay global variables" approach is, once straightened out it should build portably and without fun like the apr libs
02:12.49brlcadbe sure to consider the big picture management advantages/disadvantages too then, user management isn't nearly as well integrated, generic properties, proven stability across massive dbs, repository mirroring, efficient binary management, .. ;)
02:14.06starseekeractually it does seem to have some user management abilities, although I haven't looked hard at that
02:14.30starseekerI'm assuming it's got to be fairly good at mirroring, being a dvcs...
02:14.31brlcadif performance were the only consideration, that new libgit toy would be a viable candidate
02:14.38brlcadit has user management
02:14.41starseeker<snort> I took a look at that
02:14.45brlcadit's not just nearly as well integrated
02:14.46starseekerdoesn't have the feature set yet
02:14.56brlcadsvn's is pretty extensive
02:15.19brlcadthere's a whole lib dedicated to it that can be coupled to the various remote connection mechanisms
02:15.55starseekerbrlcad: is user management a big deal at the revision control level?  I thought user management stuff was gonna live higher up the food chain, but maybe I was wrong
02:16.13brlcadinitial stab was a complete punt, just let svn do what it does
02:16.32brlcadanything we do higher up is just going to suck
02:16.38starseekerah
02:16.52brlcadthat's trickty to get right, even stupid username+password management
02:17.14starseekerfossil does have at least some capability for username+password
02:17.20brlcadit has to :)
02:17.39brlcadit's an unintegrated home-grown solution iirc
02:18.12starseekeryeah, it's self-containment is one of its selling points
02:18.23brlcadyep
02:18.30brlcadit's a plus and a negative tradeoff
02:18.42brlcadsuper limited, but super simple
02:19.42brlcadto me spells "super inadequate" for long-term without hacking a completely separate user management layer on top, but that's not a concern for a while
02:20.00brlcadit's worth testing regardless
02:20.33brlcadanything we implement shouldn't be so tightly integrated that we cannot switch out to a different versioning engine without a couple weeks effort
02:21.48starseekermy plan was to get it refactored/reworked to the point where I could directly pass it librt's db byte arrays as objects, and check them out into a .g file instead of files
02:22.05starseekerthen see what performance was like
02:32.48CIA-52BRL-CAD: 03starseeker * r43903 10/geomcore/branches/fossil/src/libgeomvcs/ (CMakeLists.txt checkin.c): Still problems with this file, but can't continue tonight - check in what I've got.
02:33.50brlcadstarseeker: the scrolledwidget ttk fix .. is that from upstream?
02:34.07brlcadworth pushing to upstream?
03:50.22starseekerbrlcad: if you can call it a "fix" - just going for uniform ttk usage when possible
05:28.52*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
06:53.06*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:53.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:21.59*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
08:14.11*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
08:14.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:38.49*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
10:22.03*** join/#brlcad merzo (~merzo@193.254.217.44)
10:37.15dlomanMernin all.
10:50.16brlcadso approximately 92 seconds of that 30min animation took up about 5GB of disk in image frames... think I'm going to need a bigger disk
10:51.16brlcador I'm going to need to make a smaller animation (was aiming for 720p)
10:52.23dlomanyikes.
10:52.31dlomanthat's totally raw image data i take it?
10:53.12brlcadbasically, it's a ppm stream
10:53.20dlomanat 5GB per 92 seconds, you're looking at about 100GB for the 30 min stretch.
10:53.42dlomanI've got a 2TB external you can borrow if ya need :)
10:54.18brlcadyeah, which by itself isn't too shabby, except it's not exactly something I can upload to vimeo :)
10:54.40brlcadi'll figure something out
10:56.22dlomanI have Adobe Premere elements and I *think* it can encode a ppm stream to something like mp4, avi, wmv, etc.
10:56.26dlomanif ya need.
10:57.33brlcadthat part I'm actually not worried about at all, plenty of ways to encode from the stream
10:57.51brlcadmore the processing size and size of end result video
10:58.33dlomanwell, its not ideal, but you can always hack it into parts if its too big for upload.
10:58.40brlcadthis should work.. just need to make some room :)
10:59.14dlomanhehehe.
10:59.45dlomanon that note: I am seriously considering picking up a pair of 2TB internals... time for some upgrading of the data server!
11:00.28dloman<Tangent> brlcad: Have you neard of a group called Improv Everywhere?
11:06.49*** join/#brlcad sofichinu (~sofichinu@115.69.147.65)
11:15.10dlomanhttp://www.youtube.com/watch?v=lYJ9zOyzI4w&feature=player_embedded
11:15.18dlomanThat's the kinda stuff IE does :)
11:15.25dlomanbasically, hilarious stuff :)
12:04.09CIA-52BRL-CAD: 03Tbrowder 07http://brlcad.org * r2611 10/wiki/Google_Summer_of_Code/Project_Ideas:
12:15.06CIA-52BRL-CAD: 03Rossberg 07http://brlcad.org * r2612 10/wiki/Google_Summer_of_Code: probable a copy-and-paste error
12:21.21CIA-52BRL-CAD: 03davidloman * r43904 10/geomcore/trunk/ (include/Config.h src/utility/Config.cxx): Added some zero length string checks for the UInt and UShort helper functions in Config class to keep from attempting to parse an empty string. Added a hasConfigValue() for performing simple mapping checks.
12:27.14CIA-52BRL-CAD: 03davidloman * r43905 10/geomcore/trunk/src/utility/Config.cxx: Made getConfigValue() perform a check to see if the internal config map actually has the key prior to attempting to return the value.
12:29.08CIA-52BRL-CAD: 03davidloman * r43906 10/geomcore/trunk/src/GS/geomserv.cxx: Simplify startup of geomserv by making Config do all the data conversions for the 'port' parameter.
12:29.15starseekerbrlcad: I'll try and sync to stable today
12:41.10CIA-52BRL-CAD: 03davidloman * r43907 10/geomcore/trunk/ (3 files in 3 dirs): Reordered GemetryService args to be more intuitive. Removed GeometryService's need to store a localnodename as it was redundant (it was being stored as the thread name anyways)
12:43.54CIA-52BRL-CAD: 03davidloman * r43908 10/geomcore/trunk/src/GS/geomserv.cxx: Geomserv now correctly parses config file for listenAddy and listenPort. If not present, use defaults.
13:12.40starseekerhere's a quick stab at a poster - I don't expect it'll pass muster but maybe it'll prod somebody:
13:12.44starseekerhttp://bzflag.bz/~starseeker/poster_2011_1st_draft.png
13:13.16dlomanIm instantly grooving on the TRON font =D
13:13.41``Erikyeah, int he lower right, that's cool
13:14.04``Erikbut the drop shadows? ortho view of a ginormous screenshot? (not saying I could do better, just being the peanut gallery)
13:14.16starseekerthat's the GSoC logo - I'm not sure how to do that font
13:14.32starseeker``Erik: that's why it's to prod, not proposed as a final
13:15.10``Erikhm, matt wanted to do german today, you should call him up and go, bring up the poster, he or nikki might be interested in chattering about it, if not helping :)
13:15.23starseeker``Erik: heh
13:15.34starseekerunfortunately, I doubt I'll be up there in time
13:15.39``Erikwe're programmers, not artists :D
13:15.41``Erikah, bummer
13:15.44starseekeramen
13:15.59``Erik(or, rather, our art is code and math, not visual)
13:16.06starseekerthe drop shadow effect was a stand in until someone figures out how to do that google font thing
13:16.36``Eriklooks like the tron font done in gimp with the glow and outline script-fu smacked on it?
13:16.48starseekershrugs - maybe
13:16.56``Erikscript-fu is neat, it used to all be scheme, d'no if they've "fixed" that
13:16.59starseekerdoesn't have strong script-fu
13:17.21starseeker``Erik: if you want to hack around with it I can send you the xcf
13:17.38``Eriknah, getting ready to shower and head down to union memorial
13:17.52starseekera good visual for this might be a nice full-screen isst view of something cool
13:18.55``Erikhm, what about a handful of keen images (archer, isst, stryker/rise, a few rt's) canted at like ~20 degrees in the z (so they're all parallelograms in outline)
13:19.18starseekercool - can you do that?
13:19.21``Eriksemi-randomly placed
13:19.23``Erikum, no? :D
13:19.30``Erikjust throwing ideas, dude
13:19.32dlomanstarseeker: you in today?
13:19.37starseekerlater today, yes
13:19.39dlomankk
13:19.40starseekerdloman: what's up?
13:20.09dlomanwell brlcad is here already, so i figure the three of us + Photoshop CS5 can get hte job done relatively quickly.
13:20.24starseekerdloman: you don't need me for that
13:20.31starseekeryou and brlcad can handle it fine
13:20.36dlomancollective input
13:20.47dlomanis stupid busy.
13:21.04starseekernods - I won't speed up the process much, trust me
13:21.36``Erikphoto shop? that's the windows imitation of gimp, rgiht? :>
13:21.56dlomanlol
13:22.04dlomani use both pretty extensively
13:22.21dlomanand, this is the one area where the Commercial package spanks the FOSS version.
13:22.46starseeker``Erik: I know - we could use a snapshot from brlcad's gource visualization :-P  should be guaranteed to scare off the weak
13:25.21``Erikhm, don't hvae gimp on my laptop, compiling it and it's chain would take too long, and sketchup looks wrong for what I want to say, damn
13:25.36starseekerinkscape?
13:25.52starseekeror xfig? :-P
13:26.13dloman``Erik: you run a gui of any sorts?
13:26.35``Erikdlo: mac.
13:26.50dloman..theres no precompiled GIMP binaries?
13:26.54``Erikprobably are
13:27.00dlomankk
13:27.09``Erikhttp://www.gimp.org/macintosh/ heh
13:27.21CIA-52BRL-CAD: 03starseeker * r43909 10/brlcad/branches/STABLE/ (27 files in 17 dirs): Sync STABLE to trunk r43908
13:27.31starseekerthere we go
13:27.36starseekergets moving
13:27.47starseekerlots to do, too few hours...
13:30.37``Erikmebbe brlcad will go to prost and talk to matt about critiquing what we do or hints on how to not suck?
13:31.20``Erikhits the rainlocker and heads off, hasta
13:43.29*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
13:54.38CIA-52BRL-CAD: 03davidloman * r43910 10/geomcore/trunk/ (4 files in 2 dirs): Rework DataSource interface to better represent current repo design initiative. (plus cascading changes.)
14:05.54CIA-52BRL-CAD: 03davidloman * r43911 10/geomcore/trunk/ (3 files in 2 dirs): Stub in SvnDataSource class
14:06.55``Erik10:06AM  up 313 days, 16:43, 2 users, load averages: 0.05, 0.11, 0.14
14:07.18``Erikdoh, wrong machine :D
14:07.21dlomanthats good to know ``Erik , thanks!
14:07.22``Erik10:06AM  up 414 days,  4:55, 17 users, load averages: 1.91, 2.03, 2.02
14:07.44``Erikstarting to get heavy again, might break the old record
14:08.25dloman``Erik: whats your FB post about?
14:08.56``Erikjust everything all happening at once, crazy couple of months
14:09.03dlomanah, got ya.
14:09.35``ErikI mean, that whole area is lighting up like ww3 is about to start, natural disasters of unprecidented scale elsewhere, ...
14:10.33dlomanmaybe, just maybe, there will be some finality to the (seemingly) endless conflict in/around the middle easy.
14:10.36dlomanlol
14:10.37dlomaneast
14:11.19``Erikperhaps, if they modernize, but we're regressing on the flipside, so...
14:11.48``Erik(mebbe that's the REAL pole shift to be scared about :D )
14:12.03dloman=D
14:12.55dlomanThat would make a decent 'what if' scifi story:  Earth's axial tilt gets knocked to near 90 degrees.....
14:15.03``Erikever read "lucifers hammer"? pournelle and niven, I think?
14:15.15dlomancan't say that I have.
14:15.28``Eriksimilar situation, amusing enough book :)
14:16.07dlomanwonders if there is an audiobook for it.....
14:16.47dlomanif pournelle can tame niven's habit for painful science detail, then it could be good :)
14:17.13``Erikhehehe, I dig niven, I like the detail
14:17.19dlomanthe ringworld series was interesting, but it felt like i was reading a tech manual / textbook at times ;)
14:17.36dloman"Screw plot development, lets talk about cool geeky things"
14:17.40``Erikneeds to pick up pratchets discworld series
14:17.40dloman=D
14:17.51dlomanheh, we have all of them
14:17.54dlomanwell, most of them.
14:18.04dlomanhe got really preachy in his latests books.
14:18.34dlomanHe's a faithfully devout Athiest and started to use his books to evangelize :/
14:18.55``Erikhm
14:19.00dlomanthat was kinda annoying, but the first, oh, 8-10 books in the series were great.
14:19.09``Erikalso need to restock on harry harrison and mercedes lackey O.o
14:19.20``Erikdoes robert asprin still write? is he still alive? O.o
14:19.23dlomanI have a few audio books for pratchet if you want.
14:19.31``Erikoh, he died in '08 :(
14:19.33dlomanno idea.  Who's that?
14:19.46``Erikthe 'myth' series and 'phules company'
14:19.54``Erikcamp comedy scifi
14:20.15``Erikhttp://en.wikipedia.org/wiki/MythAdventures was his big series
14:20.54``Erikkinda mel brookes goofy
14:21.30dlomanhrm, looks interesting.
14:21.37dlomanbookmarks.
14:21.52dlomanso I was wondering...
14:21.57``Erikthe blue pill
14:22.05dlomani found a website pertaining to the whole Ringworld thing
14:22.22dlomansome guy, back in the 80's, tried to do a simulation of the Ringworld.
14:22.34dlomanbut hit a wall due to computer limitations
14:22.44dloman....think we could model it in brlcad?
14:22.46``Erikhm, we do have a hair more computational power these days, I think
14:22.50dlomansimply of course
14:23.06``Erikmodel it? sure, um
14:23.12dlomanalthough, an algo that would generate terrain in addition to the ring would be neat.
14:23.15``Erikaccuracy will get gimpy due to the sizes
14:23.26``ErikI thought we had a few of those
14:23.37dloman....but on that scale? :)
14:23.44``Erikfractal noise generators that create dsp's, etc
14:23.53``Eriksure, big enough fractal, it's just a memory constraint
14:24.12dlomanponders
14:24.22dlomandown to what resolution though....
14:24.31dloman1km ?  10m ?
14:24.36``Erikcould alter one to do 'bound' fractals to chain them along by preseeding one side and generate a metric buttload of dsps' to cover the inner surface
14:25.04dlomani think its funny how you can spew tech stuff and still work the word 'buttload' into it.
14:25.10dloman=D
14:25.39``Erik10m should be okish, I'd start getting nervous about 1m... um, the estimated orbital distance is about jupiters orbit, and we store purely in mm
14:26.11``ErikI'm under the impression that jupiter is (let me figure a better word) a whole metric assload of mm's from the center of the sun
14:26.28``Erikso double precision will start stretching out a fair bit
14:26.43dlomanright, but we have 64 bits of storage to work with right?  And with doubles, we get what.... 15 decimals of precision?
14:26.54``Erik15 decimals is a falacy
14:27.09dloman...hence the question mark :P
14:27.18``Erikit's a logorithmic encoding, with the most accuracy right at 1.0ish
14:27.34``Erikif you get too small or too big, the discernable difference increases
14:27.44dlomanwell forget float then, why not go with pure integer?
14:28.36``ErikI was actually trying to come up with a system in the late 90's, wanting to right an xwing/wingcommander type game for an entire solar system, did the math and double was 'good enough', after being mocked for trying to come up with a tiered integer system
14:29.25``Erikbut that was a space fighter sim, the speeds and distances were assumed to be significant, so mapping between model and world space ... I don't recall :/
14:29.27dlomanwhat was your minimum accuracy with that system?  1m 10m?
14:29.58``ErikI want to think a full double was down to a handful of cm, but I really don't remember
14:30.17``Erikthat's 64b packed, 80b computation, the norm for intel
14:31.10``Erikof course, a ringworld model could hold translation matrices all up the chain to gain accuracy, ya just might get weirdness if you xpush'd
14:31.23dlomanhehehe
14:31.43``Erikmight be a fun diversion in april :D
14:31.53dlomanthat'd be a pretty awesome ISST demo
14:32.00dlomanapril == offsite?
14:32.29``Eriknah, offsite should be serious, but we all have too much to worry about this month, can't have diversions like that
14:33.23``Erik(mebbe we shoulda made geomserv the offsite, it was postponed because geomserv was more important, from what I understand)
14:42.09dlomanwell now, work on the Infinity engine has certainly come along nicely.  Eye candy: http://www.youtube.com/watch?v=h7eREddMjt4
14:52.54CIA-52BRL-CAD: 03davidloman * r43912 10/geomcore/trunk/ (5 files in 4 dirs): Modify GeometryReqMsg to carry 'Path' and 'Recurse' vars instead of 'ReqType' and 'Path' vars
15:08.55*** part/#brlcad sofichinu (~sofichinu@115.69.147.65)
15:09.17*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
16:23.07CIA-52BRL-CAD: 03starseeker * r43913 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r43912
16:57.06CIA-52BRL-CAD: 03davidloman * r43914 10/geomcore/trunk/src/GS/ (geomserv.config geomserv.cxx): Clean up and standardize Datasource declarations in the .config file
17:02.45CIA-52BRL-CAD: 03davidloman * r43915 10/geomcore/trunk/ (include/DataManager.h src/GS/DataManager.cxx): Simplify DataManager by only allowing it to handle a single DataSource.... for now.
17:42.57CIA-52BRL-CAD: 03starseeker * r43916 10/brlcad/trunk/src/ (libbu/booleanize.c libged/red.c): Two things to fix red behavior - need blank and not space in one place in the regex matching, and recognize (null) as a boolean 0 in bu_str_true
17:48.01starseekerpwd
17:48.10starseekerwhoops
17:50.41CIA-52BRL-CAD: 03starseeker * r43917 10/brlcad/branches/STABLE/src/ (libbu/booleanize.c libged/red.c): Sync STABLE to trunk r43916
17:52.48CIA-52BRL-CAD: 03starseeker * r43918 10/brlcad/branches/cmake/src/ (libbu/booleanize.c libged/red.c): MFC r43917
18:09.14CIA-52BRL-CAD: 03davidloman * r43919 10/rt^3/trunk/ (27 files in 25 dirs): Purge out all GeometryService related stuff. This now lives in the GeomCore module.
18:10.16*** join/#brlcad Nohla (~Nohla@64.76.19.227)
18:11.37CIA-52BRL-CAD: 03starseeker * r43920 10/brlcad/trunk/src/libged/color.c: edcolor was eating the colors - check for the right number of digits in the scan line
18:14.38CIA-52BRL-CAD: 03starseeker * r43921 10/brlcad/trunk/NEWS: edcolor was removing old color tables and not accepting new ones - fixed scan logic to expect the actual number of digits being scanned for.
18:16.50CIA-52BRL-CAD: 03starseeker * r43922 10/brlcad/branches/cmake/ (NEWS src/libged/color.c): MFC r43921
18:17.45CIA-52BRL-CAD: 03starseeker * r43923 10/brlcad/branches/STABLE/ (NEWS src/libged/color.c): Sync STABLE to trunk r43921
19:23.31*** join/#brlcad bhinesley (~bhinesley@adsl-99-125-83-101.dsl.bkfd14.sbcglobal.net)
19:44.19bhinesleyHello everyone, I'm a student participating in the GSoC. I would appreciate any suggestions for project proposals. I have about 5 years of professional experience in 3d CAD design (designing commercial plumbing systems in AutoCAD). I have minimal experience with C++ and Java, but I have coded dozens of VBA programs for the companies I have worked for. I use Linux all the time, personally, and I also have about 3 years of
19:44.19bhinesleyexperience administering a Linux server on a ~25 workstation network.
19:45.49bhinesleyAlso, I am somewhat familiar with Python, and I believe I could get up to speed quickly.
19:50.50*** join/#brlcad yukonbob_ (~bch@20-144.wireless.kamloops.net)
19:50.53starseekerdo you have particular interests?
19:51.56starseekerbhinesley: if you have experience with modeling interfaces, you might want to take a look at our ideas for GUI enhancement
19:52.42starseekerWe're using Tcl/Tk, which is a bit different from Python, but not tremendously difficult
19:54.35starseekerhttp://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas
19:55.00bhinesleyI don't have any particular interests, that I can think of yet. I don't have experience with modeling interfaces.
19:55.15starseekerwell, you used AutoCAD yes?
19:55.17bhinesleyLearning a new language isn't really a problem
19:55.23bhinesleyyes
19:55.29starseekerthat's experience :-)
19:56.00starseekerbhinesley: the first thing I'd suggest is compiling BRL-CAD and taking a look at MGED and Archer
19:56.11starseekerthey're where the current GUI development action is
19:56.31bhinesleyI think I misunderstood you, I thought you meant programmer-modeling user interfaces
19:56.51bhinesleyokay
19:56.55starseekerWas your pipe design work in 2D or 3D (drawings, or three space)?  (there's no wrong answer)
19:57.01bhinesley3d
19:57.07bhinesleyfor fabrication
19:57.09starseekernods
19:57.42bhinesleyalthough, obviously I am proficient in 2d drawings as well
19:57.55starseekerIf you're not afraid to get down and dirty with Tcl/Tk, I'd suggest taking a look at the sketch editing task and possibly the Ayam task
19:58.05starseekerdo you have any mathematical background?
19:58.29bhinesleyyes, I have finished calculus 2 (out of 3; I'm on a semester system)
19:58.48starseekerOK - Ayam is related to NURBS, which is pretty heavy duty in the mathematical department
20:00.29bhinesleyinteresting... I am assuming it involves more mathematics than I am familiar with(?)
20:01.42starseekerIt depends... the mathemathical requirements may not be absolutely essential for mapping Ayam nurbs editing to our nurbs editing, but you'll have to become familiar with NURBS structures
20:03.12starseekerOur sketch editor needs help rather badly, so if you're more comfortable with 2D drafting you can take a look at our sketch editor, at what TkCAD can do, and where to go from there
20:04.33starseekerhttp://brlcad.org/wiki/MGED_Sketch_Editor_Migration_and_Enhancement
20:04.44starseekerhttp://brlcad.org/wiki/Ayam_Editor_Feature_Integration
20:05.13starseekerthose will have links to get you started
20:05.18bhinesleythank you
20:05.44bhinesleynot sure if this helps, but here is a picture of some of my work: http://stashbox.org/manage_file/1087048/pipe
20:05.48starseekerremember those are just suggestions - be sure to pick something you find interesting
20:06.12bhinesleycertainly
20:06.49starseekerI base those suggestions on the fact that you've worked at modeling tasks before, and thus have background interacting with graphical modeling tasks
20:07.40bhinesleythat's great, that is exactly what I was looking for
20:08.16starseekerIf you're familiar with Python Tcl/Tk shouldn't seem too alien, although Archer in particular makes heavy use of Itcl/Itk
20:09.31starseekerbhinesley: you'll want to get BRL-CAD built first and foremost, since everything follows from that, and get MGED and Archer running
20:09.47bhinesleyyes, I'll do that right now.
20:10.17starseekerthen explore the sketch editor (I'll offer a shortcut - when you have mged running, create a basic sketch and then edit it to get the gui)
20:11.00starseekerfrom the MGED command line:
20:11.03starseekermake sketch.s sketch
20:11.14starseekersed sketch.s
20:11.51starseeker(remember to compile using --with-ogl to get Archer working)
20:12.19starseekerbhinesley: I can't seem to see that stashbox.org link
20:14.05bhinesleyHmm, I was afraid of that. I'm trying to find an alternative.
20:16.22bhinesleytry this: https://picasaweb.google.com/lh/photo/_dWpWLr1esGb16X7_4DlNHMyrgI048JfNwPx7Dl9cn0?feat=directlink
20:17.11bhinesleythat doesn't show much solids modeling, but I've done that too
20:17.37bhinesleylet me clarify: a tool was used for sizing the pipe
20:17.58bhinesleyall routing/placement was done manually
20:18.36bhinesleyI modeled all of the pumps/tanks to spec though
20:21.05starseekercool
20:26.45bhinesleyso what kind of stuff do you do for BRL-CAD, if you don't mind me asking/
20:26.49bhinesley*?
20:29.29starseekerbug fix, development, support
20:30.11starseekerthe guy to really listen to is brlcad, he'll probably appear in channel later
20:30.38bhinesleyoh okay. founder?
20:30.58starseekerhe's the lead of the open source project
20:31.08starseekerthe actual founder of BRL-CAD itself is Mike Muuss
20:31.43starseekerit's a very old project:  http://brlcad.org/d/about
20:32.05starseekeris a newbie, relatively speaking :-)
20:33.06starseekerbhinesley: if you want to ask questions, go ahead and post them - it may be a few hours before anyone responds, but that's normal - we read backlogs
20:33.36bhinesleyhey, that's cool
20:33.37bhinesleyis a newbie, in absolute terms
20:33.51bhinesleythanks for your help
20:34.00starseekerno problem - any of that look interesting?
20:34.58bhinesleyI haven't looked yet, I'm working on getting the source
20:35.09starseekernods
20:35.25starseekerremember not to check out the whole thing - you only want the latest development sources:
20:35.38starseekersvn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad
20:35.53bhinesleyoh thanks, I wasn't sure which to checkout
20:37.04starseekerthe toplevel files have instructions for building - ideally, ./autogen.sh && ./configure --enable-all --with-ogl && make && make install will do it
20:39.10CIA-52BRL-CAD: 03starseeker * r43924 10/geomcore/branches/fossil/ (4 files in 3 dirs): Get checking building, albeit with a lot of implicit warnings
20:39.59starseekerbhinesley: be sure you review the checklist - do you have a sourceforge account?
20:41.38bhinesleyI will in about 30 seconds
20:51.33CIA-52BRL-CAD: 03starseeker * r43925 10/geomcore/branches/fossil/ (4 files in 2 dirs): Add find_option to basic, but this does not belong in a library (none of the argc/argv stuff does) and will be part of a restructuring
20:56.01CIA-52BRL-CAD: 03starseeker * r43926 10/geomcore/branches/fossil/src/libgeomvcs/checkin.c: update find_option
21:31.51*** join/#brlcad Emma (~Emma@p5.eregie.pub.ro)
22:30.35CIA-52BRL-CAD: 03starseeker * r43927 10/geomcore/branches/fossil/ (10 files in 2 dirs): Declare some more functions.
IRC log for #brlcad on 20110323

IRC log for #brlcad on 20110323

03:17.17*** part/#brlcad niels_horn (~niels@187.14.62.166)
03:26.00*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
03:26.08*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ)
03:26.31*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
03:26.36*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
03:33.57*** mode/#brlcad [+o brlcad] by ChanServ
03:42.08brlcadstarseeker: thanks for the sync to stable, can hopefully test tomorrow
03:45.06*** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1096601295.dsl.bell.ca)
03:45.44brlcadbhinesley: welcome
03:47.08bhinesleybrlcad: thank you, hello
03:50.06brlcadbhinesley: so I read the backlog, have you had a chance to look around at things in BRL-CAD yet?
03:50.40brlcadthere really are nearly a limitless range of areas where valuable projects can be worked
03:51.44bhinesleyI actually just got back from class. Before I left, I was working on getting BRL-CAD compiled; still a couple errors, but close.
03:51.49brlcadfrom a project-perspective, I can share that this year there is a strong emphasis on projects that are tightly integrated and part of BRL-CAD, refacting and improvements being more interesting than new code that could be developed in isolation
03:52.03brlcaderrors?  pastebin?
03:52.11brlcadshould be a clean checkout/build from latest svn
03:53.00bhinesleyI didn't save it, but I'm re-"make"ing right now
03:58.08bhinesleyI will hopefully have more to say about the projects that were presented to me, soon. I feel that I should do a bit more research before I understand.
03:58.28bhinesley*will need to to a bit more research
04:05.37bhinesleyI am certainly interested in contributing to BRL-CAD, though. Now that I know more about it, I will try to help where I can, GSoC or no.
04:05.54bhinesleyhere we go: http://pastebin.com/8SgPkDtK
04:07.51brlcadhuh, interesting -- that's from svn trunk?
04:07.58brlcadwhat version of gcc is that?
04:08.15bhinesley4.5.1
04:08.33brlcadmm, nice 'n fresh
04:08.35bhinesleyit's from here: https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad
04:08.38brlcadk
04:10.10bhinesleythat is the version that came with the stable brach of Fedora. Should I try a newer version?
04:14.12CIA-52BRL-CAD: 03brlcad * r43928 10/brlcad/trunk/src/proc-db/clutter.c:
04:14.12CIA-52BRL-CAD: clear a strict compilation warning from gcc 4.5.1 (reported by bhinesley via
04:14.12CIA-52BRL-CAD: irc) where a warning about an operation within the random number generator may
04:14.12CIA-52BRL-CAD: be undefined. it's undoubtedly due to multiple increment calls being passed as
04:14.12CIA-52BRL-CAD: function args, so evaluation order might not be what one would expect. simple
04:14.13CIA-52BRL-CAD: enough to get the random number prior to the function.
04:14.15brlcadso that's just a compilation warning, halting because we specify "cc1: warnings being treated as errors"
04:14.22brlcadfixes are usually trivial
04:16.39bhinesleythat's what I thought, but I figured the "warnings being treated as errors" was there for a valid reason
04:18.04bhinesleyoh, I see now. I'll remove it.
04:18.39brlcadthe --disable-strict configure flag will get you past those warnings, though there really shouldnt be many/any .. it's almost complete in your build to have gotten as far as it did only halting in proc-db (one of the last dirs)
04:19.20brlcadit's there to weed those issues out by default, instead of ignoring and/or allowing to accumulate
04:19.30bhinesleymakes sense
04:21.13brlcadtook several months to bring the code base into full compliance
04:22.06brlcadbut in the end, having rigid conformance to all warnings across multiple configurations, platforms, and compilation environments really helps maintainability
04:22.25brlcadand pushes back against lazy coding habits
04:24.22bhinesleyhard to argue against paying attention to warnings
04:26.29brlcadbhinesley: so in addition to the project ideas page, there is also http://brlcad.org/~sean/ideas.html
04:27.13bhinesleywow, great
04:27.17brlcadof everything in that list and the project ideas page, priority is generally given to topics that fall into one of our four major focus areas (described in detail at http://brlcad.org/BRL-CAD_Priorities.png )
04:29.09brlcadour main interest isn't so much in getting code, but towards getting you actively developing (long after gsoc is over)
04:32.01bhinesleyassisting in active development is precisely what I am interested in
04:32.04brlcadif that interest is mutual, then the project is really just a catalyst excuse to keep you fed while you code and becaome a proper new dev and we can make a lot more headway on a successful gsoc submission
04:38.50bhinesleyto be honest, though, with all the hype surrounding the competitive nature of the GSoC, I feel like I am competing with a bunch of guys polishing up the last 6 months of their PhD's
04:39.21bhinesleynot to say that I am not going to put forth the maximum effort.
04:39.40brlcadit's a really wide range of talent and experience
04:39.45bhinesleyhas used a double negative
04:40.57brlcadhaving worked with a couple students in previous years whose projects loosely related to their dissertation, I can say that is definitely not something very interesting to entertain again this year unless it was just an outright stellar proposal
04:41.27brlcadthose students tend to work on their project and disappear
04:41.55bhinesleyexpensive, then
04:48.17brlcadfeel free to probe any questions on what you might be interested in working on, whether it's something on the list or not -- keeping in mind the "prefer to fix/improve/integrate existing code over writing new code" inclination as a general guideline
04:50.02bhinesleywill do; when are you usually here?
04:50.06brlcadand of course, ask all the questions that come to mind - several of us read backlog and comment when time is available
04:50.14brlcadusually all the time ;)
04:50.18bhinesley:)
04:50.25brlcadjust sometimes too busy to talk
04:51.09brlcadUTC-4 at the moment
04:52.02bhinesleygood to know, I'm -8
04:54.42brlcadreally??  that's alaska
04:55.09brlcadmaybe +8?
04:55.49bhinesleycalifornia http://upload.wikimedia.org/wikipedia/commons/3/39/Timezones2008_UTC-8.png
04:59.24bhinesleycompile successful :)
05:01.57brlcadah right, so actually UTC-7 then .. (daylight savings)
05:02.51bhinesleyhuh, I didn't realize the UTC code changed for daylight savings
05:03.05bhinesleymakes sense
05:29.10*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
08:14.52brlcadfinishes our gsoc flyer: http://brlcad.org/gsoc/BRL-CAD_GSoC2011_flyer.pdf
08:15.13brlcadfeedback welcome, holding off sending it in to google until after morning
08:16.47*** join/#brlcad merzo (~merzo@193.254.217.44)
09:24.41bhinesleylooks good/professional. Maybe change the color of "GET PAID". Goodnight.
10:46.53starseekerbrlcad: nice, I like it
10:47.19*** join/#brlcad yiyus (1242712427@je.je.je)
10:55.31*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
11:06.27*** join/#brlcad merzo (~merzo@193.254.217.44)
11:17.26dlomanmernin
11:47.54starseekermorning
12:55.54yiyusI'm thinking about applying for the gsoc project "GED Transactions"
12:56.08yiyuslooking at libged source it looks like a lot of work
12:57.47yiyusI think most of the transactions would be trivial, but there will probably be some difficult ones...
12:58.04yiyusany idea of where i should be looking at to figure out the dimension of the project?
12:59.53brlcadyiyus: hello!
13:00.05yiyushi
13:02.39brlcadyiyus: the general idea is to incrementally unroll how each of the commands so they no longer modify geometry
13:02.51brlcadit's a LOT of refactoring, but not hard code fortunately
13:03.47brlcadso, for example, there is a 'kill' command for deleting geometry ..
13:04.26brlcadpresently, that command will search for the specified object(s) and it deletes them from the geometry file if it finds them
13:05.30brlcadtranactionally, that would change to having the kill command still search for the specified object(s) like it was doing before, but when it finds them, it records a "delete OBJECT" action
13:06.46yiyusi have worked in text editors with infinite undo before, we made something similar (though a bit simpler): apply the modification and push the inverse function to an undo stack
13:07.08yiyusiiuc your idea is the same, but having also a "done" stack
13:07.51brlcada wrapper function kill would have been called through gets a resulting action list back from every command, which would then revalidate that all actions can be performed, perform them on a copy, then make the copy replace the original
13:08.50yiyusah, ok, i think i got it
13:08.57brlcadit's similar to infinite undo (and the wrapper function would also need to record the action and the inverse action to a log)
13:09.21yiyusvalidating that the operations can be performed would be refactored or would i have to write it from scratch?
13:09.23brlcadthe only complexity is that the transactions are nestable
13:10.25yiyusnestable, in the same sense that solidworks transformations are nestable, for example?
13:10.35brlcadI might call one command, which might call another, which might call another, etc.. each of them potentially pushing actions of delete, create, or modify of geometry and views
13:10.49brlcadyes
13:11.25yiyuswell, everything sounds quite well, i will have a deeper look to get some familiarity with brlcad and the libged code
13:11.33yiyusone last thing
13:11.56yiyusI also saw the "Geometry Selection Functionality" project
13:12.25yiyuswhich of them would be preferable? ged transactions or geometry selection?
13:13.03brlcadyes :)
13:13.07brlcadboth are high priority
13:13.56brlcadgeometry selection is a lot more tangible for gsoc in terms of complexity
13:14.06brlcadso what's your background?
13:14.52yiyusi'm industrial engineer. programming all my real experience is in C
13:15.05yiyusthough i also know some other languages
13:15.26yiyusi participated in gsoc 2010, with Plan 9 from Bell Labs, writing a virtual machine
13:15.38yiyusbut I don't think that can be applied here
13:15.52yiyusi also know many other languages, but not c++
13:15.57brlcadhow did you like working with the plan 9 guys?
13:16.20yiyusit was great. actually, i have been quite involved in plan9 related projects for some years
13:16.32brlcadare you still working on plan9 too?
13:17.08yiyusyes
13:17.25yiyusi still maintain what i wrote last year, and we have some plans to improve it
13:17.47yiyusas a matter of fact, i'm considering applying there again too
13:18.29dliplan9 still alive? I thought they have stopped it
13:20.17yiyusit is alive, but the team working on it at the labs is very small
13:20.17brlcaddli: oh yeah, their core devs are quite committed ..
13:21.09yiyusthere is not any interest in turning it into a mainstream os (which i think is fine)
13:21.27brlcadi've wanted to attempt of port of brl-cad to plan9
13:21.43brlcadwe'd probably compile right out of the box with 80% functionality
13:21.59brlcadtk would be the one tough part
13:22.16brlcadso probably no gui services, but all command-line commands
13:22.32brlcador at least most, the non-curses ones
13:22.47yiyusthere is a tk port for inferno, which runs on top of plan9
13:22.54yiyusbut it is not tcl/tk, it is in limbo
13:24.15brlcadyiyus: so for gsoc submission, both sound like great ideas -- if you were going to tackle the libged one, I'd want to see a lot of up-front planning and testing on just one command before hitting up the 399+ other commands, maybe even having an initial refactoring plan spelled out in the application
13:24.35brlcadthat's an important one to "get right" so there's not a lot of time wasted refactoring over and over and over
13:24.53brlcadlibged refactoring is another project all in itself (and also high priority) :)
13:26.12brlcadthat's also a project that would extend beyond gsoc so it'd be good to hear what dev plans would look like for beyond gsoc timeframe
13:26.40yiyusi will have to get familiar with libged before i can say too much, but will definitively have a look
13:27.05brlcadif that sounds like a lot of work (and it frankly IS, but would rather both of us be honest about it) .. then select may be a much better proposal or a library refactoring proposal since they're much more incremental
13:31.59yiyusmay i ask what is your approximate student proposals/gsoc slots ratio?
13:33.41brlcadnever know exactly, it really depends on the quality of the proposals more than the count
13:34.00brlcadwe do a quick culling to the quality proposals
13:35.05brlcadone year that knocked 50 applications down to about 10 where we selected 4, another year that knocked 35 down to about 15 and we selected 5
13:35.37yiyusthanks, that's all i wanted to know
13:36.02yiyussome projects cooperate with university departments and such, and have hundreds of applications per slot
13:36.05brlcadif it's a high quality application from a student we've been interacting with and we think is willing to be committed beyond gsoc, will instantly be in that final running
13:36.37brlcadah yeah, no .. we're way more niche
13:37.19brlcadthose sorts of applications rarely result in students that hang around after the summer is up .. interesting for getting academic code, but not so hot for growing the dev team
13:37.44yiyusi would like to stick on the project after gsoc
13:38.07brlcadwe would like that as well :)
13:38.08yiyusi work at a department in the university (phd student) and would like to convince my collegues to use free software
13:38.27yiyusthat's why i'd prefer brlcad over plan9
13:40.11brlcadbrl-cad's in production use today, but our usability is really tough especially compared to commercial cad systems, very steep learning curve
13:40.27brlcadsomething actively being worked on, but that's a lot of work that's going to take several years to address
13:42.21yiyuswell, i don't expect to substitue autocad this year, but i'm sure it is good enough for easy tasks like test samples
13:42.27brlcadhttp://brlcad.org/BRL-CAD_Priorities.png is a useful read to know how the various gsoc projects fit into our "big picture" overarching priorities
13:42.39brlcadlibged fits in under geometry services
13:50.20starseekerbrlcad: so for an undo system, the delete OBJECT action would also record the inverse action (e.g. create OBJNAME OBJTYPE [params...]) in a log somewhere?
14:00.10brlcadright
14:25.59*** join/#brlcad PrezKennedy (MK@whitecalf.net)
14:30.38brlcadhowdy PrezKennedy
14:30.54PrezKennedyhowdy! how's life treating you brlcad?
14:31.02brlcadpretty fantastic
14:31.28PrezKennedygreat!
14:31.39brlcadhows work?
14:32.06PrezKennedymeh, we're wrapping up at the 5 sided building come august
14:32.34PrezKennedywe're at the beginning of a dev cycle so it's not hectic at the moment
14:32.40brlcadnods
14:32.57brlcadhopefully employment is not reduced after the 5side is completed ;)
14:33.25PrezKennedyhopefully, but ive been looking at things up there
14:33.37PrezKennedyim not opposed to moving back, not much keeping me down here
14:33.45brlcadbhinesley: good suggestion, added a little color
14:34.13brlcadPrezKennedy: your brother might appreciate this: http://brlcad.org/gsoc/BRL-CAD_GSoC2011_flyer.pdf
14:35.09starseekerbrlcad: how'd you do the blue halo?
14:36.02PrezKennedybrlcad, something he worked on?
14:56.13brlcadPrezKennedy: yeah, he made that model and rendered the image from scratch
14:57.37brlcadwent to the ordnance museum, took measurements, modeled it, set up all the rendering infrastructure, did several massive distributed renderings -- this one being one of the more awesome lighting setups
14:58.10brlcadstarseeker: I used the blue pill
14:58.17starseekerheh
14:58.26brlcadi mean, blue 'part'icles
14:59.39brlcadit's actually several composite effects -- a 0-offset shadow, a 2px antialiased stroke, and a light underglow effect
15:00.18starseekercool
15:02.50starseekerhmm... it looks like I may have been using svn_add very very badly...
15:03.10brlcadheh
15:03.17starseekeror was I... hmm...
15:03.30brlcadwondered that .. an order of magnitude overhead is pretty substantial :)
15:10.51starseekercommit is still an IO hog
15:12.18brlcadone commit or N commits?
15:12.27brlcadhopefully just one
15:12.44starseekerwell, I added the full breakout of havoc recursively, and am committing the whole thing
15:12.47CIA-52BRL-CAD: 03davidloman * r43929 10/geomcore/trunk/ (include/ByteArray.h src/utility/ByteArray.cxx): Add a printHexString(...) method. Helps a tons during t-shooting.
15:15.12CIA-52BRL-CAD: 03davidloman * r43930 10/geomcore/trunk/src/libNet/Portal.cxx: Add in some commented out ByteArray printHex calls. There's some issue with c++ and java not liking eachother byte orders. T-Shooting continues...
15:16.24starseekerso yeah, just doing one commit ;-)
15:17.58CIA-52BRL-CAD: 03starseeker * r43931 10/geomcore/trunk/tests/svntest/main.c: Let's not individually add everything - use the svn_depth_infinity parameter setting, and go back to a full breakout - still expensive, but add is a lot quicker
15:19.25dlomanso, realistically, are we viewing full model commits as a common occurance?
15:19.42dlomanI always invisioned them as part of the 'upfront' cost for using the svn backend.
15:21.08dlomanstarseeker: if i wanted to 'steal' a root level CMakeList.txt for reworkign the cmake system in rt3, which would be a better fit?  the CMakeLists.txt from geomcore or brlcad?
15:21.25starseekergeomcore
15:21.54starseekerdloman: full model commits are only a common occurance if you do things like frequent xpushing :-P
15:22.29brlcadstarseeker: it'd be interesting to see what the cost difference is after an xpush, how long commit takes
15:22.51brlcadwhether the cost is in the book-keeping to add new nodal entries or whether it's the commit book-keeping itself
15:23.14starseekeronce I get the point where I can do something with the broken out .g I can try - my guess is it'll be murder
15:23.45starseekerI edited one primitive and committed it, and it took a while (less than a minute, but still)
15:25.01starseekermaybe 10-12 seconds
15:53.26CIA-52BRL-CAD: 03davidloman * r43932 10/rt^3/trunk/ (6 files in 4 dirs): Steal Starseeker's geomcore cmake work and apply it to RT3. This is the first step in making RT3 into 'the GeometryEngine' module.
15:53.53starseekerdloman: were you planning to move the ogre/Qt work elsewhere?
15:55.44dlomanDunno....
15:55.56dlomanits currently disabled from any build system.... so....
15:56.13dlomani think it would warrent discussion at some point :)
15:56.48starseekerliked the idea of having a toplevel geomengine module, that is svn:external included in geomcore
15:57.35starseekeror failing that, scrap geomcore and have two toplevels - geomengine and geomservice
15:58.17starseekeras I understand it, the idea is to reduce temptation to mingle GE and GS code and libraries?
15:59.41dlomannods
15:59.55dlomanand singe coreInterface calls rt3 home....
15:59.58dlomanwow
16:00.04dlomans/singe/since/
16:00.34starseekerI like leaving rt3 as the "repository for random ideas"... geometry engine and geometry service are starting to firm up
16:01.31starseekerconceptual neatness aside, I prefer to have the GE and GS build logic stay fully clean and not be polluted with "other" stuff that may be commented out
16:02.00starseekerbut brlcad may have a different take
16:03.28dlomanto be fair, the rt3 module was not intended to be the 'sandbox' that it has become.  so why not make a 'sandbox' repo?
16:03.47starseekerthat's fine too
16:03.48dlomanerr not repo, but module
16:04.16starseekerwould still prefer calling it geomengine or GE instead of rt^3, but I suppose that's a bikeshed issue
16:04.41dlomanagreed
16:04.51dloman'ge' is nice and short :)
16:05.01starseekerdloman: want me to set it up that way?
16:05.09starseekerge, gs and sandbox?
16:05.34dlomanlets get some buy in from brlcad and perhaps Ed et al.
16:05.42starseekernods - fair enough
16:05.45dlomanrenaming rt3 effects more than just us :)
16:06.15dloman...although we could pull a nice prank on Dr Daniel by removing RT3 :)
16:06.24starseekerwinces
16:06.46starseekerpoint - we should probably get GE at least up to parity with his existing rt3 functionality first
16:16.05CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:BRL-CAD GSoC2011 flyer.png]]": This flyer was designed by Christopher Sean Morrison with Google logo and Goliath rendering provided with permission by Google Inc and Stephen Kennedy respectively.
16:16.39dlomancurrently, all i plan on doing is copying the GeometryEngine class files over (which are stubs) and then make a libge that is nothing but coreInterface files.
16:16.59dlomanso, in essence, libge == coreInterface
16:17.05dloman..initially
16:17.13dlomanwe will/can grow libge from there.
16:17.38CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2614 10/wiki/Google_Summer_of_Code/2011: add a link to this year's flyer with details on acceptance
16:17.58starseekernods
16:18.18dlomanalmost got rt3 to that point.
16:21.00CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2615 10/wiki/Google_Summer_of_Code: link to 2011 flyer, scaled appropriately for landscape
16:21.14*** join/#brlcad phani (7ab32f27@gateway/web/freenode/ip.122.179.47.39)
16:22.27starseekerdloman: go ahead and do what you need to - we can always sort it out later
16:22.32phanii am student interested in participating in Google Summer of Code ... are there any admins around ?
16:22.56starseekerthe fundamental cleanup was handled in rt3->geomcore, so subsequent refactoring should be fairly simple
16:22.59starseekerphani: howdy!
16:23.29phaniHi ! I am good . I am a masters student from india.
16:23.33CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2616 10/wiki/Google_Summer_of_Code: /* [[Google_Summer_of_Code/2011|GSoC 2011]] */
16:23.44phaniMy area of spcialization in image processing
16:23.46dlomanstarseeker: nice assertion that I'm going to screw it up :P
16:23.55starseekerdloman: hehe - I didn't mean it like that
16:24.06starseekerphani: have you looked over our projects page?
16:24.14phaniyes ..
16:24.21starseekerwhat do you find interesting?
16:24.24phanihttp://brlcad.org/wiki/Complete_bu_image/libicv_and_redo_all_pix_tools_to_use_it
16:24.26dloman..although, with the run of luck i've been having lately, its probably not a bad assertion to make :)
16:24.30phanii am interested in this
16:24.45starseekerdloman: I just ment sorting out directory organization and whatnot
16:25.02starseekerphani: ah - ``Erik knows the most about that subject
16:25.08dlomanheh, i added a libge/ dir to src/  .....thats about it!
16:25.26starseekerdloman: cool, that should be fine for now
16:26.04phaniok... will contact eric then
16:26.07starseekerphani: did you have any particular questions?
16:27.01starseekerphani: another image related task would be openexr support
16:27.07phanii wanted to ask more about the project
16:27.33starseekerphani: go ahead - ``Erik and brlcad both read backlogs
16:28.02phanii could not find any other project on image processing there
16:28.05starseekerIRC isn't always real-time communication - you generally stay logged in, post a question, and sometimes get a response later
16:28.07phanican you give me the link to it ?
16:28.36starseekerhttp://brlcad.org/wiki/High_Dynamic_Range_Support
16:29.17phanithanks
16:30.05starseekerphani: one of the first things to do for any project is to make sure you can compile and run BRL-CAD
16:30.53starseekerthe work that has been done so far for the libbu image task is in src/libbu and src/libicv, if I recall correctly
16:30.54phaniok. Will do that now.
16:31.40starseekerphani: since any project will involve a lot of work in the codebase, you want to make sure it's something you feel like you can work in/with
16:32.34phanii like image processing very much and i have considerable command over it. I would like to get some experience on open source coding on that subject
16:32.46starseekerphani: when you check out the subversion source, be sure to get just trunk:
16:32.57starseekersvn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad
16:33.27starseekerphani: note that BRL-CAD is a solid modeler, not primarily an image related system
16:34.01phaniyes, of course ...
16:34.10CIA-52BRL-CAD: 03davidloman * r43933 10/rt^3/trunk/src/ (5 files in 3 dirs): Okay, I think i have libGE piggybacking ontop of coreInterface correctly now. Changes to build system have been made. Daniel, please let me know if I broke anything for ya!
16:34.44dlomanokay, so how does one setup an svn external?
16:35.19starseekerphani: not to drive you away, but in the interests of covering your options you've also looked at the OpenCV project?
16:37.02starseekeryou can submit multiple applications
16:37.54CIA-52BRL-CAD: 03davidloman * r43934 10/geomcore/trunk/src/ (13 files in 10 dirs): Move some older dev files into an appropriate directory for now.
16:38.35phaniyes ... opencv and astronomy.net are the other organizations i am interested in ...
16:47.01CIA-52BRL-CAD: 03davidloman * r43935 10/geomcore/trunk/src/ (CMakeLists.txt GE/ libNet/CMakeLists.txt): Remove GE from Geomcore. Its going to be its own module.... eventually.
16:47.53dlomanOkay, there.  GE should be completely in rt3 now, and is piggy backed off of coreInterface.
16:48.32dlomanNow on to wiring up geomcore to find libGE and start working the DataManager/DataSource stuff.....
16:48.44starseekernods
16:53.09brlcadhow about simply ge, gs, and gui?
16:53.42starseekerworks for me
16:53.43brlcadnot really fond of the word sandbox as it implies there are few/no rules and that shouldn't really be the case for any code committed to the repository
16:53.56brlcadrelaxed, sure, but sandbox implies more free-for-all to me
16:54.41brlcadhello phani
16:55.14starseekerge/gs/gui works for me
16:56.54brlcadphani: there are lots of potential image processing related projects in BRL-CAD
16:57.42brlcadthere are a few other orgs that are interested in image processing, fwiw, but we definitely have at least two of high interest -- the two mentioned already
16:59.43phanii am looking at the links given by starseeker ... I am also compiling BRL-CAD now.
16:59.51brlcadphani: if you're looking through our source tree, also of interest will be src/util where there are more than 100 image processing tools from image converters, wavelet transforms, filters, scalers, and much more
17:00.31brlcadmost of them have man pages and are simply one file per binary
17:00.43brlcadso you can just scan through the *.c or *.1 files
17:00.54phaniok...
17:01.24starseekerbrlcad: I chimed in in the Qt discussion on the list, so you may need to smack me down ;-)
17:01.31brlcadthere's also src/sig for more general "signal processing" which generally applies to 1D data stremas, but sometimes to 2D streams as well
17:02.58phaniI will look at these things now and will contact you back as soon as possible. Its already late night here.
17:02.58brlcadphani: as you're probably already finding out, BRL-CAD is a *very* large system -- we know that and don't expect you to know what's there or how to find things easily, so please do ask questions if you have them
17:03.02CIA-52BRL-CAD: 03Willdye 07http://brlcad.org * r2617 10/wiki/Building_from_SVN: Give an example for Ubuntu users who don't have autoconf installed
17:03.36phaniThanks for letting me know where to start. I got a very good intro. Will look at it in detail
17:03.47phaniand will ask you doubts soon
17:03.51brlcadstarseeker: comments sounded spot on to me
17:03.59brlcadmatched up with what I was saying in not so many words
17:04.04starseekerbrlcad: heh
17:04.40starseekerhad viewed the Qt approach as replacing the X11 dm, in the same way that OGRE "replaces" dm-ogl/wgl
17:05.41starseekergrowls at subversion... come on, how do I get a list of files...
17:05.48brlcadphani: if you're really into image processing, you have the potential to turn BRL-CAD into your playground (regardless of GSoC) implementing ideas, research, new tools, etc
17:06.46brlcadso while libicv might be something we're interested in from an architecture standpoint, we're more interested getting new long term developers -- so if you have a long term interest there -- then cater your project proposal around that long term interest so you can and will want to keep working on it long after GSoC is over
17:07.05brlcadwe want devs more than we want their code ;)
17:08.02brlcadgsoc participants that can convince us of that are an easy shoe-in
17:17.53*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110325 || Welcome GSoC 2011 participants! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011
17:33.42CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2618 10/wiki/Google_Summer_of_Code: /* Overview */
17:44.02CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2619 10/wiki/Google_Summer_of_Code: don't repeat ourselves, we list the application guidelines on the checklist. link to the 2011 page.
17:48.32CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2620 10/wiki/Google_Summer_of_Code/2011: link back to main page
18:16.51*** join/#brlcad crazy_imp (~mj@a89-182-15-254.net-htp.de)
18:16.53crazy_impheyho
18:17.08crazy_impis it possible to export everything from a .g file with g-stl ?
18:31.17CIA-52BRL-CAD: 03starseeker * r43936 10/geomcore/trunk/tests/svntest/main.c: Switch back to ktank, make some initial progress on listing out directory contents.
18:32.37CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2621 10/wiki/Google_Summer_of_Code: mention 2010
18:34.12brlcadcrazy_imp: sure, assuming there are no geometry errors and you don't hit a problematic conversion case
18:34.38brlcadyou need to know the names of the top-level objects, which can be obtained with: mged -c file.g tops
18:37.15crazy_impbrlcad: i thought of something like this: g-stl .. -o foo.stl foo.g `mged -c foo.g tops` but it doesn't work
18:37.46crazy_imp(i really want something like "g-stl .... foo.g \*" :)
19:12.22brlcadcrazy_imp: mged's output by default goes to stderr, so you'd have to run mged -c foo.g tops 2>&1 for that to work
19:13.45brlcada problem and one of the reasons why you have to specify which geometry objects is because the .g container supports multiple models (multiple hierarchies of models at that) whereas STL only supports a single model
19:15.07crazy_impbrlcad: so i should simply design everything inside one file (at least if it's logical to do so) inside one group for easier converting?
19:17.34brlcadIFF you convert your model to BoT (mesh) format, you might have better luck with something like: mged -c foo.g bot_dump -t stl -o foo.stl
19:17.42brlcadthat will dump all BoT objects to files
19:18.13brlcadconverting objects to BoT beforehand is done with the facetize command or during import from a polygonal converter
19:19.10brlcadand yes, you very likely will design everything in one file and construct objects together based on their material compositions that need to be differentiated
19:19.31brlcadthe principles of effective modeling go into proper modeling best practices in more detail
19:20.34*** join/#brlcad Ralith (~ralith@d142-058-175-170.wireless.sfu.ca)
19:20.42crazy_impright now i just want to use it for 2.5D modeling ;)
19:44.37CIA-52BRL-CAD: 03starseeker * r43937 10/geomcore/trunk/tests/svntest/main.c: Re-assemble ktank.g into a staging area.
20:17.10PrezKennedybrlcad, i sent my brother a link to that picture you showed me
21:03.18*** join/#brlcad dli (~dli@dyn-216-087.wireless.concordia.ca)
21:14.03CIA-52BRL-CAD: 03bob1961 * r43938 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Minor mod to Ged::handle_data_move to not load data for _pane.
21:22.10CIA-52BRL-CAD: 03brlcad * r43939 10/brlcad/trunk/HACKING: add CADCAM insider to our distribution list
21:24.38CIA-52BRL-CAD: 03starseeker * r43940 10/geomcore/trunk/tests/svntest/main.c:
21:24.38CIA-52BRL-CAD: Handle naming (very) slightly better. Maybe need UUID to ensure each connection
21:24.38CIA-52BRL-CAD: can get its own workspace for assembling geometry from checkouts for return
21:24.38CIA-52BRL-CAD: shipment down the socket? Or do I need recursive checkout and dbconcat based on
21:24.39CIA-52BRL-CAD: comb contents for sub-checkouts? (or both?)
21:33.12CIA-52BRL-CAD: 03starseeker * r43941 10/geomcore/trunk/tests/svntest/main.c: Supply the .g file as an argument, so we can try multiple files without recompiling
22:16.49brlcadstarseeker: where do all of the palloc() allocations in src/librt/search.c get freed?
22:20.51CIA-52BRL-CAD: 03brlcad * r43942 10/brlcad/trunk/NEWS: per r43399, bob fixed a bug in the wgl display manager where it was broken when drawing strings with line breaks in them. now skips no pixels or rows.
22:23.47CIA-52BRL-CAD: 03brlcad * r43943 10/brlcad/trunk/src/burst/grid.c: VINIT_ZERO instead of constant init.
22:24.40starseekerbrlcad: hmm - I think it's up to the function that called db_search_formplan to free it
22:25.02brlcadstarseeker: also plan on submitting the iwidgets ttk change upstream, any reason not to?
22:26.04brlcadhm, so search.c has a leak then?  it doesn't free the dbplan that it received
22:26.12brlcadlooks like it's some sort of nested allocation structure?
22:26.45starseekerbrlcad: urm, yeah it's possible search has a leak (may have always had it, for that matter)
22:27.06starseekerbrlcad: I can try - don't know what the iwidgets take is on ttk
22:27.15brlcadif you have a valgrind handy, that'd probably be a good one to slip in sometime
22:27.40brlcaddon't know how much allocation that is, or if it's just a matter of free'ing the main pointer
22:28.45brlcadit can't introspect it at the libged level because it's a void*, all callers can do is free that
22:30.53starseekernods - I'm knee deep in subversion at the moment, but I'll try to take a look)
22:31.05brlcadnp
22:35.11brlcadyeah, looks like the db_plan_t is a linked list
22:45.07brlcadstarseeker: huh, the find implementation that you used apparently never bothers to free any memory
22:45.22starseekeroops
22:45.23brlcadundoubtedly because the application quickly exits
22:45.31starseekersorry about that
22:45.34brlcadwhich is fine, bad form but fine, for a binary
22:45.45brlcadproblem for a library, since the leak will accumulate
22:45.52brlcadnot your fault
22:45.57starseekershould have checked that <puts on programmer dunce cap>
22:55.33CIA-52BRL-CAD: 03starseeker * r43944 10/geomcore/trunk/tests/svntest/main.c: Add some timing code in. Also try to get cute and call g_diff on the reassembled file, but that's not perfect yet.
22:58.03CIA-52BRL-CAD: 03brlcad * r43945 10/brlcad/trunk/ (include/raytrace.h src/librt/search.c):
22:58.03CIA-52BRL-CAD: implement a db_search_freeplan() to go with the db_search_formplan() function.
22:58.03CIA-52BRL-CAD: releases the allocated db_plan_t linked list structures acquired during a given
22:58.03CIA-52BRL-CAD: plan formulation. looks like the original source code for find never bothered
22:58.03CIA-52BRL-CAD: to release any memory, but we have to be more careful since we're in a library.
22:58.36starseekerbrlcad: awesome, thanks for swatting that
23:00.14CIA-52BRL-CAD: 03brlcad * r43946 10/brlcad/trunk/src/libged/search.c: call db_search_free() to release our dbplan allocations. this should prevent/reduce memory leakness across subsequent calls. untested but testing now.
23:00.38brlcadnods
23:03.49CIA-52BRL-CAD: 03brlcad * r43947 10/brlcad/trunk/NEWS: bob added pix2fb and corresponding fb2pix commands to archer as a means to capture the contents of the framebuffer to a pix image file. useful for screenshots and image overlaying
23:03.54brlcadall commits now reviewed, testing release
23:05.46starseekerbrlcad: this should be up your alley: http://pastebin.mozilla.org/1190541
23:07.16brlcadstarseeker: what was the benefit for the ttk scrollbar change?
23:07.36brlcadlooks
23:08.17brlcadhm, odd
23:08.25brlcadshouldn't take 38 seconds to reassemble
23:09.24brlcadcat **/*.g only took 0.05 seconds or something from the shell, that's the base time to scan all dirs, open all files, read/write all file data
23:09.38brlcad(for havoc)
23:10.29starseekerI'm using the svn list function, which may introduce some overhead
23:10.43starseekerI don't think I'm going to keep doing it with that function, it's not well suited to this use
23:11.09starseekeris cat faster than db_concat?
23:11.21brlcadnot much difference
23:11.27starseekerbrlcad: uniformity of appearance in archer
23:11.46starseekerwe had switched all our other scrollbars to ttk - the iwidget window was the odd man out
23:11.53brlcaddon't want to just cat them, that's more to understand that it's not in the file I/O at least
23:12.02brlcaddbconcat makes sure there aren't name collisions
23:12.15brlcadthat might take a sec or two, but definitely not 38s
23:12.18starseekernods
23:12.31brlcadokay, cool wrt iwidgets
23:12.37brlcadwas just wondering what I should write them :)
23:12.43starseekerheh
23:12.49brlcadyou make the edits or bob or both?
23:13.08starseekerthinks back... that was me, but Bob told me where to look
23:13.18starseekerand what to remove to avoid some errors
23:13.55brlcadk
23:14.12starseekerhas yet to integrate itcl into his working knowledge base
23:15.30brlcadhttps://sourceforge.net/tracker/?func=detail&aid=3238914&group_id=13244&atid=383689
23:15.32starseekerI was trying to use svn's list command as a convenient way to get a list of the files I needed to work with, but it's optimized to print out results to the command line
23:16.15starseekerbrlcad: cool, thanks!
23:16.44brlcadhttp://www.devmaster.net/news/index.php?storyid=2663
23:16.46starseekerbets they're surprised to see anyone still using it
23:17.21brlcadbets they're not
23:17.26brlcadhave you met any of the tcl guys? :)
23:17.31starseekerhehe - point
23:18.16starseekerhad kind of gotten the impression that tcllib and tklib were gaining more of a following
23:18.27starseekerhttp://www.tcl.tk/software/tcllib/
23:21.41starseeker'course, bwidget still gets used too... oh, well
23:21.48starseekerif it works it works
23:24.09brlcadcool, looks like I didn't bust search
23:47.24CIA-52BRL-CAD: 03starseeker * r43948 10/geomcore/trunk/tests/svntest/main.c: Add a note on what to do about replacing svn_client_list2
IRC log for #brlcad on 20110324

IRC log for #brlcad on 20110324

00:11.20bhinesleywhat handles the main mged exit "X" GUI button?
00:13.33bhinesleyis done grepping :)
00:13.58starseekerheh - you found it?
00:14.10bhinesleyno, I've been looking for a while
00:14.21bhinesleyI figured it was time to ask
00:14.52starseekerIIRC that involves either signal handling or Tk bindings
00:15.22starseekertake a look at the exit or quit commands
00:15.55bhinesleyyeah, that's what I've been doing. That, and the tcl files
00:16.17starseekerI'll have to ask our expert tomorrow - I confess I don't know the details of that right offhand
00:16.40starseekerTcl/Tk is kind of annoying in that respect - debugging usually involves lots of print statements
00:17.04starseekermost of the debuggers I know about are commercial :-(
00:17.47starseekerThe only open source one I know of is http://www.compassis.com/ramdebugger/
00:18.00starseekerand I've never actually gotten it working with MGED or Archer
00:18.10starseeker('course I didn't try real hard)
00:20.37starseekerbhinesley: oh, I'll bet this is it - look for instances of WM_DELETE_WINDOW
00:21.02bhinesleyI have been
00:21.33starseekerhttp://www.tcl.tk/man/tcl8.5/TkCmd/wm.htm
00:21.50bhinesleyI guess I'll pursue that a little further
00:21.58starseekerthe details of the window distruction are handled by Tk, IIRC
00:22.44starseekerthe "X" button is actually the responsibility of the window manager
00:23.17starseekerso when you click on that "X", a WM_DELETE_WINDOW event (or something similar) is generated
00:23.57starseekersupposes if he's suggesting Tcl/Tk projects he should make another stab at figuring out how to hook up RamDebugger...
00:24.35starseekerbhinesley: are you running into problems with closing windows?
00:25.26bhinesleywell, I was trying to work on a bug
00:25.37starseekerah, very good :-)
00:25.40starseekerwhich bug?
00:26.42bhinesleyI believe these two may be related, and not specific to Windows as it appears:
00:26.44bhinesleyhttps://sourceforge.net/tracker/?func=detail&aid=2278072&group_id=105292&atid=640802
00:26.44bhinesleyhttps://sourceforge.net/tracker/?func=detail&aid=1961127&group_id=105292&atid=640802
00:28.25starseekerbhinesley: note that at least the second one reports using a VERY old version of BRL-CAD, so it might be worth trying to reproduce the problem first
00:28.59bhinesleyI am experiencing a similar problem in Fedora
00:29.07starseekerah, really!
00:29.12bhinesleyactually... I've tested it in windows, too
00:29.21starseekervery good
00:29.53starseekerbrlcad may have more insight on how all that's wired together
00:30.41starseekerbhinesley: a possible suggestion would be to try to simplify the problem down - if you create a tk window displaying a png file (say) and close it, does it have the same problem?
00:30.56starseekerthat might indicate a Tk issue
00:31.33bhinesleyhmm, okay, I will try that in a little bit If I cannot isolate it to one of the WM_DELETE_WINDOW's
00:32.15starseekeranother question is is it Tk specific?
00:32.20bhinesleythe code for the 'q', 'quit', and 'exit' commands works properly
00:32.37bhinesleyso does file-> exit (oddly)
00:32.53starseekerso one possibility is to make sure the WM_DELETE_WINDOW calls are triggering the same logic
00:33.05starseekerif you want to try without Tk, do mged -c
00:33.10starseekerthen pick nu
00:33.17starseekernon-graphical mged ;-)
00:33.58starseekerdo that in one terminal, close the terminal without quitting, the check the status of the file from a different terminal
00:34.41brlcadbhinesley: which platform are you on?
00:34.59brlcadah, fedora .. just catching up
00:35.10bhinesley:) hello
00:35.37brlcadyeah, the issue is cross platform -- I think our code that used to pick up with window-close event from tk-land is no longer being handled or at least no longer being handled sufficiently, so mged doesn't shut down
00:37.27brlcadlets see if I can get this right -- it's supposed to close the application if the graphics window is closed, but keep mged running if only the command window is closed
00:38.06starseekerblinks - really? is there a way to start up a new command window from the GUI?
00:38.28brlcadI'm not real keen on that behavior frankly, so it's fair game to change -- I think it should either close both windows if you close either, or not shut down mged until both windows are closed regardless of which is closed first
00:38.59brlcadyeah, it would make total sense the other way around since you can keep reattaching new graphics windows
00:39.17brlcadI think the old reasoning was that you'd shut down the command window and just end up with a pure viewer
00:39.41starseekervotes for the other way
00:39.52brlcadthat's fine, but closing the graphics window shouldn't close the command window..
00:39.55starseekerthe minimize button is a powerful tool
00:39.59bhinesleyif closing the command window closes the graphics window, then perhaps the command window should just be modal, and only allow closing from the graphics window
00:40.18bhinesleywait, closing the graphics window should leave the command window up?
00:40.39starseekerthat would be my vote.  you can launch multiple graphics windows from the command prompt
00:40.56bhinesleyhm okay, sounds backwards to me, but I'm from AutoCAD-world
00:41.12starseekerwe're a trifle command line centric :-P
00:41.16bhinesleyyeah
00:41.43brlcaddepends if we're talking about what it "should" do, what it's "supposed" to do, or what it "presently" does? :)
00:42.19starseekerArcher is currently organized more around the traditional desktop app paradigm, but we hadn't gotten to addressing desired behavior there with respect to this question
00:43.19bhinesleywell the Archer command window is embedded
00:43.28brlcadif we ignore "presently" and "supposed" behavior, what I'd want it to do is not have either the graphics window or command window close button quit the application unless it's the last window open
00:43.30starseekerbhinesley: you can detach it :-)
00:43.34bhinesleyah I see now :)
00:44.14bhinesleybrlcad: ok
00:44.17starseekerbrlcad: yeah, I was thinking that too - as long as you can launch display managers from the command prompt, and command prompts from the display, you're fully up as long as you have a window
00:44.21bhinesleyI have to leave guys, I'll bbl
00:44.27bhinesleythanks, bye
00:44.30starseekerbhinesley: bye!
00:44.37brlcadbhinesley: something to keep in mind while testing is you can "attach X" as many times as you like from the command window, you can also run mged -c to get classic mode and then run "gui" to start up the tcl/tk gui
00:45.23starseekerrealizes he has to get up at 5am and heads home...
00:45.32brlcadwee
00:45.48brlcadencounters compilation success!
00:57.04brlcadpretty impressive mesh manipulation tool http://www.meshmixer.com/
01:02.53CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2622 10/wiki/Google_Summer_of_Code/Project_Ideas: de-emphasize an idea of their own. want integrated code
01:09.03CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2623 10/wiki/Google_Summer_of_Code/Project_Ideas: add programming languages potentially involved
01:09.56*** join/#brlcad crazy_imp (~mj@a89-183-78-5.net-htp.de)
03:27.15CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2624 10/wiki/OGRE_Display_Manager: combine ogre and qt into the same topic
03:27.24CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Qt Display Manager]]": merged in with the ogre idea
03:27.50CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[OGRE Display Manager]] moved to [[Cross Platform Display Manager]]: rename post-merge
03:28.13CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2627 10/wiki/Google_Summer_of_Code/Project_Ideas: merged
03:29.12CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Other Cross Platform Framebuffer]] moved to [[Cross Platform Framebuffer]]: simplify
03:36.46CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2630 10/wiki/Cross_Platform_Framebuffer: merge in qt
03:37.06CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Qt Framebuffer]]": no longer needed, merged with the more general cross-platform tasker
03:37.39CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2631 10/wiki/Google_Summer_of_Code/Project_Ideas: merged framebuffer tasks, only need one
03:44.24CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2632 10/wiki/Google_Summer_of_Code/Project_Ideas: recategorize the gui projects
03:48.44*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
04:09.56CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Cross Platform Display Manager]] moved to [[New Cross-Platform 3D Display Manager]]
04:10.13CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Cross Platform Framebuffer]] moved to [[New Cross Platform 2D Framebuffer]]
04:10.53CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[New Cross Platform 2D Framebuffer]] moved to [[New Cross-Platform 2D Framebuffer]]
04:12.33CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2639 10/wiki/Google_Summer_of_Code/Project_Ideas: make the task descriptions sub-context information
04:22.28CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:BRL-CAD Priorities.png]]": Overview of our project scope, vision, mission, and main priorities.
04:28.25CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2641 10/wiki/Google_Summer_of_Code/Project_Ideas: link in project priorities image
04:43.42CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2642 10/wiki/Google_Summer_of_Code/Project_Ideas: bump up nurbs, priority
06:16.43bhinesleybrlcad: is the project idea labeled "MGED to Archer Command Migration" considered a priority?
06:25.26*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
06:47.23bhinesleyI'm leaning towards the MGED Sketch Editor Migration and Enhancement project, as suggested by starseeker
06:54.56*** join/#brlcad bhinesley (~bhinesley@99.125.83.101)
07:19.50bhinesleyis there a mentor assigned to the MGED Sketch Editor Migration and Enhancement project?
08:04.08*** join/#brlcad merzo (~merzo@193.254.217.44)
08:57.40*** join/#brlcad piksi (piksi@83.145.207.200)
09:55.40CIA-52BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2643 10/wiki/User:Bhinesley: First profile post
11:26.35dlomanMernin all
11:30.14dlomanbah, blast it all!  I can't 'apply' to be a mentor cause their application process is 'down' in preps for the launch of their new GUI later this week.  :/
11:40.40*** part/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
12:22.03brlcaddloman: it's been that way since monday
12:23.25brlcadbhinesley: note that I would consider that project "hard" so you should define lots of small milestones
12:24.14brlcadwe generally perform group mentoring so that you're not reliant upon getting answers from any one mentor
12:24.34brlcadbhinesley: as the current code is all Tcl and archer is predominantly Tcl, I hope you like Tcl :)
12:25.40brlcadthat said, the three people most likely able to help you or get answers to your questions are going to be myself, starseeker, and "bob" who you'll probably only be able to talk to via e-mail (but is the foremost knowledgeable on all things Tcl)
12:28.17brlcadbhinesley: ah, missed your first question -- I would consider the command migration higher priority than sketch editing
12:28.51brlcadintends to spend a lot more time hashing out more ideas onto the ideas list today
12:39.31dlomanbrlcad: can the project lead send invites? ...or is that disabled also?
12:42.08CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2644 10/wiki/New_Cross-Platform_3D_Display_Manager:
12:43.56CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2645 10/wiki/Google_Summer_of_Code/Project_Ideas: put the ideas into a table for more concise readability
12:48.48CIA-52BRL-CAD: 03davidloman * r43949 10/geomcore/trunk/ (2 files in 2 dirs): Verbage change: 'Data' to 'Path' ...makes more better cents.
12:52.20CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2646 10/wiki/Google_Summer_of_Code/Project_Ideas: impact
12:52.46CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2647 10/wiki/Google_Summer_of_Code/Project_Ideas: tablify
12:54.09CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2648 10/wiki/Google_Summer_of_Code/Project_Ideas: Undo revision 2647 by [[Special:Contributions/Sean|Sean]] ([[User talk:Sean|Talk]])
12:55.43dlomanbrlcad: are there any file IO functions in the brlcad libs for reading/writing plain ol files?  
12:59.31CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2649 10/wiki/Google_Summer_of_Code/Project_Ideas: tablify redux
13:04.18CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2650 10/wiki/New_Cross-Platform_3D_Display_Manager:
13:05.36CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2651 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Graphical User Interface (GUI) Projects */
13:05.56CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2652 10/wiki/New_Cross-Platform_2D_Framebuffer: new layout
13:08.34CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2653 10/wiki/MGED_to_Archer_Command_Migration: new layout
13:10.07CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2654 10/wiki/MGED_Sketch_Editor_Migration_and_Enhancement: new layout
13:11.42CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2655 10/wiki/New_Cross-Platform_3D_Display_Manager: ogre/qt as refs
13:12.26brlcaddloman: also disabled
13:13.35brlcaddloman: if they're really "plain", then libc would be the most appropriate
13:14.14brlcadotherwise we have routines to read lines from files and map files to memory buffers that are commonly used
13:16.48brlcadroutines for creating temp files, locating files, logging to a file, reading/writing strings to files
13:17.31brlcadwhat are you trying to do?
13:19.38dlomansimple check if a directory exists
13:19.54dlomanwanted to use a brlcad way to do it since there's a larger chance it will be cross platform ;)
13:20.05CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2656 10/wiki/Google_Summer_of_Code/Project_Ideas: bgcolor
13:21.06*** join/#brlcad Elrohir (~kvirc@p5B14BA4E.dip.t-dialin.net)
13:23.14CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2657 10/wiki/Google_Summer_of_Code/Project_Ideas: smaller priorites link, push to top
13:28.45CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2658 10/wiki/New_Cross-Platform_3D_Display_Manager: medium
13:30.43CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2659 10/wiki/NURBS_Intersections: new layout, add references
13:32.47CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2660 10/wiki/Google_Summer_of_Code/Project_Ideas: kiss
13:34.50CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2661 10/wiki/NURBS_Tessellation: new layout, add references
13:35.37CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2662 10/wiki/NURBS_Tessellation: redundant to repeat title
13:36.05CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2663 10/wiki/NURBS_Intersections: dry
13:36.23CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2664 10/wiki/New_Cross-Platform_3D_Display_Manager: dry
13:38.01CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2665 10/wiki/CSG_to_NURBS_conversion: refs
13:41.56CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2666 10/wiki/New_Cross-Platform_3D_Display_Manager: dry
13:42.08CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2667 10/wiki/NURBS_Intersections: dry
13:42.19CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2668 10/wiki/NURBS_Tessellation: dry
13:43.59CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2669 10/wiki/Plate_Mode_NURBS_raytracing: code refs
13:46.33brlcaddloman: search include/bu.h for "directory" .. there are two or three specifically for that
13:49.19CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2670 10/wiki/Google_Summer_of_Code/Project_Ideas: CSG is the operator, not the entity type
13:49.48CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[CSG to NURBS conversion]] moved to [[Implicit to NURBS conversion]]: CSG is an operator, not a type
14:05.11CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2673 10/wiki/Google_Summer_of_Code/Project_Ideas: add a code refactoring section, move refactoring tasks up into it
14:05.31CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2674 10/wiki/New_Cross-Platform_2D_Framebuffer: dry
14:05.53CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2675 10/wiki/MGED_to_Archer_Command_Migration: dry
14:06.09CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2676 10/wiki/MGED_Sketch_Editor_Migration_and_Enhancement: dry
14:08.16CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2677 10/wiki/Ayam_Editor_Feature_Integration: new layout, add refs
14:09.10CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2678 10/wiki/New_Cross-Platform_2D_Framebuffer: consistency
14:10.44CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2679 10/wiki/Analytical_Raytracing_Visualization: new layout, refs
14:13.21CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2680 10/wiki/Level_of_Detail_Wireframes: new layout, add references
14:14.17CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2681 10/wiki/BoT_Editing: new layout, add references
14:15.52CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2682 10/wiki/NMG_Editing: new layout, add references
14:16.23CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2683 10/wiki/NMG_Editing: /* Requirements */
14:17.31CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2684 10/wiki/Graph_layout_based_geometry_hierarchy_view: new layout, add references
14:18.07CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2685 10/wiki/Graph_layout_based_geometry_hierarchy_view: /* References */
14:29.42dlomanstarseeker: http://svnbook.red-bean.com/en/1.5/svn.developer.usingapi.html#svn.developer.usingapi.urlpath
14:30.20CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2686 10/wiki/Google_Summer_of_Code/Project_Ideas: expand all of the gui projects
14:46.33CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2687 10/wiki/Google_Summer_of_Code/Project_Ideas: expand the rest of the sections with table views, impact, and difficulty
14:48.16CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2688 10/wiki/Google_Summer_of_Code/Project_Ideas: move step up
15:04.21dlomanbrlcad: thanks!
15:05.35bhinesleybrlcad: thanks for all of the info and new updates. I will reconsider my project choice in the light of this.
15:08.32starseekerbrlcad: has subversion moved to the Apache license?
15:09.56starseekerhttp://svn.apache.org/repos/asf/subversion/trunk/LICENSE
15:11.01CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2689 10/wiki/Google_Summer_of_Code/Project_Ideas: terse is so much more informative here. combine title with description and reduce to no more than two lines (on my wide screen)
15:12.52starseekerah, crap - yep http://svn.apache.org/viewvc/subversion/trunk/LICENSE?revision=878444&view=markup
15:14.35starseekeryeah, this was the old one:  http://svn.apache.org/viewvc/subversion/trunk/COPYING?revision=875073&view=markup&pathrev=878443
15:16.26*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
15:16.33dloman...so are we incompatable with apache?
15:19.06starseekerhttp://www.apache.org/legal/3party.html
15:19.33CIA-52BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2690 10/wiki/User:Bhinesley: reconsidering project choice
15:21.34CIA-52BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2691 10/wiki/User:Bhinesley: /* BRL-CAD Project Proposal */ remove superfluous blank line
15:22.19dlomanstarseeker: that really reads for people trying to package stuff instde Apache products... not the other way around.  :/
15:25.59CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2692 10/wiki/Google_Summer_of_Code/Project_Ideas: another awesome reduction
15:36.46starseekerdloman: yeah, but it works both ways, unless I'm missing something
15:36.55starseeker(quite possible)
15:41.29starseekerbrlcad: I don't suppose you have those scripts you used to benchmark breaking up a file and reassembling it from the command line?  Those might be a good way to try fossil with just a little tweaking
15:45.32brlcadusing apache isn't a problem because we're not deriving or integrating, no more compatible/incompatible than a proprietary system using an apache product
15:46.22brlcadnow that they've switched from a bsd-like license to apache, that does represent a problem to us in terms of integrating their code into ours and making updates -- has to stay separate or we have to change our license
15:46.29brlcadwe can, however, still use them
15:46.43brlcadthey can't use us is the bigger incompatibility
15:47.03dlomanso... what about the eventual plan to make a FS-G back end?
15:47.19dlomanwith the current liscense... isn't that plan now out the window?
15:47.20starseekerbrlcad: I thought we had been avoiding apache licensed stuff to avoid uncertainties about what code moved where...
15:47.24brlcadthat's fine, we just can't bundle their sources together with ours
15:47.52starseekerso I should take the subversion directory out of geomcore
15:48.26brlcadif it's the full sources, probably -- should be fine in a separate module with svn:external set up
15:49.04brlcadsource repo isn't a big deal, it's any published/distributed source tarballs where we'd have to be careful and not bundle them together
15:49.22brlcadand that's more just for perception, not necessarily legal requirement
15:49.39dlomanSo, if we put the svn code in a top level module licensed Apache, and make our FS-G code there.... then that's okay?
15:50.03dlomanso long as GS and the FS-G 'products' are distinctly different... even though GS requires the FS-G ?
15:50.21dloman(Just making sure I understand things....)
15:51.09brlcadyeah, that can work
15:51.35brlcadit's really not that big a problem for us because apache is not viral like gpl/lgpl in imposing requirements on code it's combined with
15:52.27brlcadtheir license merely applies to their code, so if we ever combined their code with ours, the license terms would conflict (lgpl isn't a superset of apache)
15:53.36brlcadour lgpl can't apply to their code and their license can't apply to our code
15:53.43dlomanokay then, so if our mythical fs-g module needs to have brlcad libraries as a dependancy... that's okay since the LGPL won't impose any restrictions on the fs-g's Apache license?
15:54.15brlcadso we can't make a blanket statement if it was bundled into a source tarball to say that "this collective work is lgpl" .. because we can't apply lgpl to their code -- it would merely be two projects with two licenses in one tarball
15:55.05brlcadit's "okay" in the sense that we can develop that module, make it lgpl, use our libs .. but it could never be integrated into svn proper
15:55.58dlomanI am pretty sure the fs-g would need to be a *modified* version of svn, rather than something that uses svn as a dep
15:56.38starseekerwould tend to agree
15:59.02brlcadit'd probably make more sense for fs-g to be apache licensed, and merely use brl-cad's libs as an installed but not bundled dependency
15:59.31brlcadas we'd be deriving from their existing fs-fs or other code anyways
16:00.49brlcadnotes that many of these concerns become moot if we switched to the BSD license :)
16:01.06dloman'we' being brlcad code?
16:02.54brlcadall brl-cad code, yes
16:03.13brlcador mit
16:03.19brlcador apache 2.0 for the patent grant
16:03.27brlcadeither way, more flexibility
16:03.56starseekerbrlcad: the original motivator for LGPL was to ensure some reciprocity, correct?
16:05.25brlcadand to abate concerns at the time of any entity forking brl-cad, making extensive valuable modifications, then trying to sell that derived version back to the gov't
16:05.54brlcadthinks he might have picked up whatever ed has
16:06.01starseekerdoesn't that risk still exist?
16:06.05starseekeruh-oh
16:07.25brlcadsure, it still exists
16:07.31brlcadbut it's not nearly as much of a concern any more
16:08.06starseekerwe've established enough momentum now?
16:08.20brlcadafter 7 years open source, I think so
16:08.42brlcadat worse, the risk is minimized as much as reasonably possible
16:08.51starseekernods
16:09.30brlcadmoreover, the benefits of allowing unencumbered use, whether commercial or not, would still benefit the brl-cad open source community and gov't regardless
16:10.12brlcadeven if their changes were never released or integrated, it would be more .g files floating around, brl-cad libraries being used, etc
16:10.18brlcadanyways, not a problem that needs solving today
16:10.23starseekerright
16:47.47CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2693 10/wiki/Google_Summer_of_Code/Project_Ideas: more awesome
16:51.21CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2694 10/wiki/General_Tree_Walker: new layout, add references
16:52.20CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2695 10/wiki/Rework_of_libbu/libbn_to_not_require_Tcl: new layout, add references
16:55.18CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2696 10/wiki/Complete_bu_image/libicv_and_redo_all_pix_tools_to_use_it: new layout, add references
16:55.58CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Complete bu image/libicv and redo all pix tools to use it]] moved to [[Consolidate image processing]]
16:57.09CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2699 10/wiki/Google_Summer_of_Code/Project_Ideas: new name
16:57.50CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2700 10/wiki/Consolidate_image_processing:
17:02.18CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[MGED Sketch Editor Migration and Enhancement]] moved to [[2D Sketch Editor]]
17:04.36CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Analytical Raytracing Visualization]] moved to [[GUI Integration of Analysis Tools]]
17:05.02starseekerbrlcad: wow that looks nice
17:05.09CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Graph layout based geometry hierarchy view]] moved to [[Visualizing Constructive Solid Geometry (CSG)]]
17:05.27CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2707 10/wiki/Google_Summer_of_Code/Project_Ideas: new names
17:07.53``Erikhm, apache license 2.0 is compatible with GPLv3, if that means anything
17:08.09starseeker``Erik: yeah, I think it primarily has to do with the patent stuff
17:08.53starseekersucky that some projects are LGPL2 only, some are LGPL3 only - makes me appreciate the simplicity of BSD/MIT
17:09.20starseekerI finally (belatedly) contacted the NURBS++ author, but wasn't able to sell him on BSD
17:11.14``Erikthe fork risk is probably greatly diminished, there was a core competency migration from the dangerous group O.o :D
17:12.01starseekerhehe
17:12.31starseeker'course, NURBS++ was LGPL2 with the later version clause, so that's somewhat better
17:12.36CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2708 10/wiki/Google_Summer_of_Code/Project_Ideas: another one bites the dust
17:12.38starseekers/was/is
17:14.12starseekerwish I could have found him before the takeover request went through, but only dug up his contact info months later
17:14.22starseekeroh, well - not like there was much going on with it
17:14.56CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2709 10/wiki/Geometry_Conversion_Library: new layout, add references
17:16.29CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2710 10/wiki/Voxelize: new layout, add references
17:17.47CIA-52BRL-CAD: 03erikgreenwald * r43950 10/geomcore/trunk/src/GS/DataManager.cxx: getData changed to getPath
17:20.42CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2711 10/wiki/IGES_import_improvements:
17:21.50CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2712 10/wiki/STEP_Libraries: new layout, add references
17:22.01CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2713 10/wiki/IGES_import_improvements: ws
17:22.24CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2714 10/wiki/IGES_import_improvements:
17:36.21CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2715 10/wiki/Google_Summer_of_Code/Project_Ideas: more awesome expansion
17:36.49CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2716 10/wiki/GED_Transactions: new layout, add references
17:37.49CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2717 10/wiki/Add_exec_option_to_search: new layout, add references
17:38.54CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2718 10/wiki/Geometry_Selection_Functionality: new layout, add references
17:40.45CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2719 10/wiki/Geometric_Constraint_Solver: new layout, add references
17:43.38CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2720 10/wiki/Space_Partitioning_for_Tessellation: new layout, add references
17:46.33CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2721 10/wiki/Libsvn_within_Geometry_Database_Format: new layout, add references
17:56.39CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2722 10/wiki/Google_Summer_of_Code/Project_Ideas: final awesome restructure
17:57.43CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2723 10/wiki/Shader_Enhancements: new layout, add references
17:58.36CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2724 10/wiki/Shader_Enhancements: refs
17:59.40CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2725 10/wiki/Material_and_Shader_Objects: new layout, add references
18:01.21CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2726 10/wiki/NMG_Raytracing_Performance_Improvement: new layout, add references
18:02.25CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2727 10/wiki/Generalized_abstracted_spacial_partitioning_capability: new layout, add references
18:03.59CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2728 10/wiki/High_Dynamic_Range_Support: new layout, add references
18:05.23CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2729 10/wiki/Vector_output_from_raytracing: new layout, add references
18:07.01CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2730 10/wiki/Analysis_Library: new layout, add references
18:08.01CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2731 10/wiki/Analysis_Library: /* References */
18:11.44CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2733 10/wiki/Google_Summer_of_Code/Project_Ideas: overlap tool is geometry processing
18:12.55CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2734 10/wiki/Overlap_tool: new layout, add references
18:13.31CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2735 10/wiki/Google_Summer_of_Code/Project_Ideas: ws
18:25.22CIA-52BRL-CAD: 03davidloman * r43951 10/geomcore/trunk/ (3 files in 2 dirs): Move DataManager Initialization over to the DataManager itself.
18:28.59*** join/#brlcad Stattrav (~Stattrav@117.192.129.170)
18:29.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:30.12*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
18:40.16CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2736 10/wiki/Google_Summer_of_Code/Project_Ideas: add mentors
18:40.50CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2737 10/wiki/Google_Summer_of_Code/Project_Ideas:
18:40.58brlcadwoot, done
18:42.29brlcad"the patent thing" is actually what makes it incompat with gpl/lgpl v2, adds a new requirement which those licenses say you can't do
18:42.38dlomanNice!  Im an 'expert modeler' !
18:42.43dlomannice page btw brlcad !
18:42.52brlcadalso why gpl v2 and v3 are only compat in one direction
18:42.58brlcadthanks dloman
18:43.21brlcadstarseeker and ``Erik did most of the hard work writing up all those topics
18:44.30brlcadfelt kinda dirty putting 'guru' after NMG, but the poor guy needed something there
18:45.04CIA-52BRL-CAD: 03starseeker * r43952 10/geomcore/trunk/tests/svntest/main.c:
18:45.05CIA-52BRL-CAD: Start major reworking of our approach to svn - use lower level api. Whole new
18:45.05CIA-52BRL-CAD: learning curve here, so everything that was previously working isn't - got it to
18:45.05CIA-52BRL-CAD: compile, so checkpointing. Also gut all the old svn client code we were using
18:45.05CIA-52BRL-CAD: to avoid license questions - figure out how to use the APIs from scratch with
18:45.05CIA-52BRL-CAD: examples.
18:45.38brlcadheh
18:46.04starseekerone step forward, two steps back... sigh
18:46.42dlomanand turn your self around... that's what its all about!
18:47.10starseekeroh, I'm alredy dizzy
18:47.39brlcadpaula abdul loves you
18:48.31starseekeraaand another reference sails right over my head... :-P
18:48.57brlcadheh
18:49.00brlcadopposites attract!
18:49.13brlcadhttp://www.youtube.com/watch?v=xweiQukBM_k
18:49.25starseekersafe for work?
18:49.29brlcadjust a song
18:51.09brlcadahh, good ol' 80's music videos
18:53.41CIA-52BRL-CAD: 03erikgreenwald * r43953 10/geomcore/trunk/src/GS/testclient/gstestclient.c: start cleaning up and simplying things
18:56.30``Erikis there any reason to be pushing strings across the pipe as unicode16 instead of ascii?
18:57.00starseekerI was doing that because of the definition of the string type on the wiki
18:57.04starseekeror were you asking dloman ?
18:57.10``Erikopen question
18:57.20dlomani down graded them to 1 byte char strings.... last week i think.
18:57.21``Eriksuspects it's a qstring thing
18:57.38dlomanqstring and java thing
18:57.54starseekerhttp://brlcad.org/wiki/GSNet_String
18:58.06``Erikjava has some dandy unicode16/ascii conversion stuff already in it
18:58.25dlomanstarseeker: thats out of date :(
18:59.26CIA-52BRL-CAD: 03Dloman 07http://brlcad.org * r2738 10/wiki/GSNet_String:
18:59.26starseekeroh - are we all agreed on GS, GE and GUI for toplevel modules?
18:59.49dlomanshakes magic 8ball.
18:59.59dloman.....Sounds good starseeker!
19:00.26starseekermagic8 ball... haven't seen one of those for many years
19:02.45CIA-52BRL-CAD: 03davidloman * r43954 10/geomcore/trunk/ (include/FileDataSource.h src/GS/FileDataSource.cxx): Stub in init routine for FileDataSource
19:06.23CIA-52BRL-CAD: 03davidloman * r43955 10/rt^3/trunk/include/ (70 files): Dump all the old GS header files. No longer needed here.
19:14.26CIA-52BRL-CAD: 03starseeker * r43956 10/geomcore/trunk/tests/svntest/main.c: Oh yeah, need to init apr and friends.
19:21.21CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2739 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Geometry Conversion Projects */
19:25.32CIA-52BRL-CAD: 03starseeker * r43957 10/geomcore/trunk/tests/svntest/main.c: Somewhat surprisingly, this approach to subdirectory addition works too. Files still aren't right
19:27.27CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2740 10/wiki/Google_Summer_of_Code/Project_Ideas: add a couple more STEP tasks
19:28.06CIA-52BRL-CAD: 03starseeker * r43958 10/geomcore/trunk/tests/svntest/main.c: And we can create empty files.
19:28.45CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2741 10/wiki/Google_Summer_of_Code/Project_Ideas:
19:35.59CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2742 10/wiki/STEP_exporter: New page: STEP is the current standard for exchange of CAD data between different software packages. BRL-CAD makes use of the NIST STEP Class Libraries code to support its step-g converter, but we ...
19:40.22CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2743 10/wiki/STEP_importer_improvements: New page: STEP is the current standard for exchange of CAD data between different software packages. BRL-CAD makes use of the NIST STEP Class Libraries code to support its step-g converter, but th...
19:42.45*** join/#brlcad hyarion (c05ben@peppar.cs.umu.se)
20:09.58CIA-52BRL-CAD: 03erikgreenwald * r43959 10/geomcore/trunk/src/GS/testclient/ (CMakeLists.txt gstestclient.c): complete rewrite. (hey, it works)
20:11.59CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2744 10/wiki/Benchmark_Performance_Database: initial benchmark web interface idea
20:17.14CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2745 10/wiki/Materials_Database: New page: BRL-CAD uses simple material properties, presently limited to density, for calculating weights, moments of inertia and other geometric analyses. There is presently no centralized reposito...
20:18.23CIA-52BRL-CAD: 03erikgreenwald * r43960 10/geomcore/trunk/src/GS/testclient/gstestclient.c: cleanup the socket
20:19.19CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2746 10/wiki/Materials_Database:
20:19.55CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2747 10/wiki/Google_Summer_of_Code/Project_Ideas: add a couple web tasks with discouraging wording
20:28.02CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2748 10/wiki/Fix_Bugs: initial bugs idea
20:35.12CIA-52BRL-CAD: 03erikgreenwald * r43961 10/geomcore/trunk/src/GS/testclient/gstestclient.c: parse and print response packet
20:37.06CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2749 10/wiki/Code_Reduction: code reduction
20:37.16CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2750 10/wiki/Google_Summer_of_Code/Project_Ideas: add code reduction
20:38.20brlcadawesome, up to 42 project ideas now -- 47 if you count the other tool projects .. I think that's sufficient now :)
20:38.33brlcadhas the new catch-all ones too
20:39.59brlcadstarseeker: I'd prefer lowercase for top-level modules just for consistency (probably less error-prone for newbies), but not strong preference
20:41.07brlcad16 byte strings across the wire will be 50% waste 99.9% of the time :)
20:42.07brlcaddon't know of anyone even attempting to deal with 16-bit stringery at the moment
20:42.23brlcadmaybe catia, but then they're french
21:02.40starseekerbrlcad: sure, lower is fine
21:06.11starseekerouch - Apple is now going to avoid Samba because of GPLv3
21:07.40starseekerbrlcad: the dynamic range one... IIRC (and I may not) another point there was to generate output images that fit better into image processing pipelines that make use of HDR
21:08.23starseekernot that that changes priority or anything, but I think that may have been the envisioned immediate practical consequence
21:08.34starseeker(HDR displays would be neat though...)
21:08.59``Erikor like CMYK or YUV for printing or something
21:46.05CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2751 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Mentors */
21:48.06brlcadstarseeker: the labels aren't really weighted well
21:48.49brlcadin the big scheme of things with the dozens of other "high" priority high impact topics on there, I think HDR is still *relatively* low impact yet it'd still be useful and cool to have
21:48.54brlcadimmediately useful even
21:49.09brlcadthe description can be reworded, didn't mean to downplay it if it comes off that way
21:49.33starseekernah, it's cool
21:49.46starseekerdon't know how much role it will play in submissions anyway
21:49.54brlcadas for the high/medium/low, I was actually considering a simple two-level instead of three
21:50.24brlcadHIGH and LOW do sound like they're being discouraged, though, when it's really meant to just emphasize the high ones
21:50.26starseekerbaby-bottle and skull+crossbones? :-P
21:50.33brlcadheh
21:51.06brlcadmaybe BIG and BIGGER
21:52.04brlcadha, winner .. BIG and HUGE
21:55.03CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2752 10/wiki/Google_Summer_of_Code/Project_Ideas: BIG AND BIGGEREST!
21:58.08starseekerwangs his head on the wall... why can't I get file content into files??? auugh
22:30.03*** join/#brlcad dli (~dli@dyn-217-029.wireless.concordia.ca)
22:35.21CIA-52BRL-CAD: 03starseeker * r43962 10/geomcore/trunk/tests/svntest/main.c: OK, we're getting non-zero sized files now. No way to know if they're anything like correct yet.
23:53.14CIA-52BRL-CAD: 03starseeker * r43963 10/geomcore/trunk/tests/svntest/ (CMakeLists.txt main.c): start working out how to reassemble using the lower level api...
IRC log for #brlcad on 20110325

IRC log for #brlcad on 20110325

00:52.30*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
01:10.34*** join/#brlcad crazy_imp (~mj@a89-182-14-228.net-htp.de)
02:33.28*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
02:58.06*** join/#brlcad IriX64 (~IriX64@bas2-sudbury98-1096601295.dsl.bell.ca)
03:00.46*** join/#brlcad PrezKennedy (MK@whitecalf.net)
03:12.43*** join/#brlcad dli_ (~dli@dsl-173-248-203-45.acanac.net)
04:09.01*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
06:02.25*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:02.25*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:02.19*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
10:10.31*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
12:29.25CIA-52BRL-CAD: 03Rossberg 07http://brlcad.org * r2753 10/wiki/Google_Summer_of_Code/Project_Ideas: corrected my irc name
13:26.07CIA-52BRL-CAD: 0368.34.98.23 07http://brlcad.org * r2754 10/wiki/Google_Summer_of_Code/Project_Ideas: group method of communicatio together
13:41.06CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2755 10/wiki/Google_Summer_of_Code/Project_Ideas: extra info
13:53.19*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
13:53.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:09.55*** join/#brlcad AbhijitKane7 (~Abhijit@111.93.5.194)
15:22.52*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
15:23.27AbhijitKaneHi, I intend to apply to BRLCAD thru the GSOC program, and work for the "Materials Database" project.
15:23.37AbhijitKaneIs there any specific mentor associated with the project?
15:32.13*** join/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
15:38.33brlcadhi AbhijitKane, what draws you to that particular project?
15:38.47brlcadhello Zaebos
15:39.02brlcadsaw your message on the mailing list as well
15:40.10AbhijitKaneI've always been interested in web-related projects, and I think that a web interface would help a lot of people access the data that you have.
15:40.31Zaeboshi
15:40.32brlcadAbhijitKane: what are your thoughts for that project?
15:40.41brlcadwhat do you envision it entailing?
15:41.46AbhijitKaneactually, thats what I wanted to clear
15:41.52*** part/#brlcad Zaebos (~irc@pd95b7f5e.dip0.t-ipconnect.de)
15:42.11AbhijitKaneAt first glance, i thought it was a simple front-end to query the database
15:43.03AbhijitKanebut I'm not sure what else is required to be done
15:43.42brlcadhow much do you know about materials?
15:43.49brlcadand material properties
15:44.15brlcadit is a simple front-end to the database, but it also entails establishing the database
15:44.28brlcadsetting up the schema
15:44.58AbhijitKaneNot much. I've just done one course related to material properties - I haven't got any other exposure to the subject
15:45.02brlcadthere was someone that actually worked on this project five or so years ago, but they never finished
15:45.15brlcadmade great progress, but never got to production status
15:45.34AbhijitKaneOh, is that the "proof-of-concept web work of relevance" mentioned on the website?
15:45.40brlcadyes
15:46.19brlcadso your project could either leverage all that previous work as a starting point or you could start from scratch
15:47.24brlcadif you start from scratch, you'll need to do some basic research on materials science, so our database captures common properties sufficiently
15:47.24AbhijitKaneIs the database schema / website source code included in the BRLCAD code?
15:47.29brlcadit is not
15:47.52brlcadI'll have to dig around for it in our archives -- it was quite a while ago
15:48.10brlcadit's available (somewhere), it'll just take a little while to find it
15:48.26brlcadregardless -- it was a homegrown setup
15:48.37brlcadhow were you envisioning the implementation?
15:49.11brlcadusing a content management system, rapid dev toolkits, or also from scratch?  something else?
15:49.48AbhijitKaneI have the most experience with MySQL. I also have a fair idea about UML, so if there are UML diagrams that I could look at, it would be advantageous.
15:50.24AbhijitKaneNot a CMS, but I could take a look at the old code or work from scratch
15:50.34brlcadheh, no UML
15:51.41brlcadpersonally (and others may have different opinions), I'd prefer that IFF you are not going to use any web toolkits or CMS that you then leverage the old code and pick up where they left off
15:51.55brlcadotherwise there'd be no difference if it was all just from scratch again, effort wasted
15:52.09brlcadrather, duplicate effort .. not necessarily wasted
15:52.19AbhijitKanei agree
15:52.55brlcadhave you ever used a revision control system before for web development?
15:53.10AbhijitKaneI used subversion for a project that I did last year
15:53.26brlcadit'll be required for this, as will creating a simple patch showing your ability
15:53.33brlcadoh?
15:53.36brlcadwho'd you work with?
15:53.56AbhijitKaneIt wasn't a part of gsoc. I was interning with a start-up
15:55.14brlcadanything on-line that we can take a look at?
15:56.33brlcadAbhijitKane: also, what got you interested in BRL-CAD?
15:56.41AbhijitKaneI helped with this: http://www.vindev.net/phototourv2/public/apps/html5
15:56.51AbhijitKaneits an HTML5 implementation of www.phototour.in
15:56.59brlcadbe sure to put that in your application
15:57.19AbhijitKaneok
15:58.16AbhijitKaneI was just looking through all the organisations that wanted back-end web development, and BRL-CAD was one of the few
16:00.05brlcadnods
16:01.05AbhijitKaneIs there any reading material related to material properties that you can recommend?
16:02.05brlcadthere are some references on the detail page
16:02.34brlcadthere are several online commercial material database websites that you could look through for comparison/reference, see what all they include
16:02.48AbhijitKaneok
16:02.52brlcadfew google searches will lead you to two or three of them
16:03.56AbhijitKanei'll take a look at them
16:04.14AbhijitKaneI have to go - be back in an hour or so
16:04.22brlcadnods
16:04.24brlcadcya later!
16:04.28AbhijitKanebye!
16:04.45brlcadcan't wait to see the proposal
16:07.19*** join/#brlcad adityag (~ADITYA@182.237.144.88)
16:09.59adityagi am pretty fluent in C & web related projects. i would love to contribute if im guided by some one experienced
16:10.44adityagbrlcad : i would love to work here
16:11.11brlcadadityag: howdy and welcome
16:11.34brlcadthe C background is great, we have tons of C projects ;)
16:11.49brlcadsuggest you scan down through our project ideas page and see if anything catches your interest
16:11.59adityagin fact, i won a national level C/C++ programming contest
16:12.10brlcadwhich nation? :)
16:14.47*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
16:15.04*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
16:16.26brlcadadityag1: connection problems? :)
16:16.40brlcadwaves hello to dli
16:17.02dlibrlcad, hi
16:18.11dlibrlcad, I am trying to become a gentoo developer to update the brlcad package, but they are very slow there
16:18.24brlcaddli: awesome!
16:18.31starseekerdli: my sympathies
16:18.33brlcadI was just about to ask if you were you
16:19.07brlcada Lin Di just messaged the mailing list, thought they might have used your irc nick :)
16:20.06dlibrlcad, couldn't be me :( my family name is Li :(
16:22.09dlibrlcad, the gentoo story, andreas Huettel told me he would be my mentor for gentoo-scicence, but I have to wait for him to start the recuiting process
16:22.32*** join/#brlcad adityag (~ADITYA@182.237.144.88)
16:22.52starseekeradityag: welcome back :-)
16:24.22brlcadhis peers don't like him
16:24.48adityagbrlcad starseeker:  connection problem + dinner time
16:25.24brlcaddli: that's great news either way, you're well on your way
16:25.37*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
16:25.43brlcadadityag: understandable
16:26.17brlcadwe're here all day -- we don't expect immediate and perpetual connectivity/responses, neither should you ;)
16:26.57adityagyes cool
16:29.02dlibrlcad, for me to test the intersection program (from previous GSoC?), is it possible for me to skip building the whole brlcad package. my gentoo is on a slow core 2 thinkpad, got to speed up the process
16:30.58brlcaddli: you can build by hand, you just cd to the dir and build from there
16:32.18brlcad"make depends" and "make" in src/proc-db should get you built
16:34.49dlibrlcad, maybe, I should write some cmake or autotools for the folder first
16:35.45starseekerdli: it shouldn't be necessary
16:36.10brlcaddli: what's the problem?
16:36.24brlcadcmake branch should work as should trunk's autotools build
16:37.09brlcadadityag: so if you didn't see my question, which nation? :)
16:38.06dlibrlcad, want to limit the range of code base for me to work on
16:39.56*** join/#brlcad piksi (piksi@pi-xi.net)
16:40.40starseekerdli: just cd into the directory with the code in question and type make there - it should only build what is needed
16:40.41adityagbrlcad: India.... & u ?
16:41.24adityagbrlcad:  for more info about me http://aditya.ritzsoftec.com
16:41.57dlistarseeker, let me play with it more
16:42.11brlcadadityag: maryland (usa)
16:45.25brlcadadityag: thanks (also good to include in your proposal)
16:45.38brlcadadityag: what platform do you work on?
16:46.42adityag<PROTECTED>
16:48.02brlcadk
16:48.11brlcadwhat is slmbk?
16:50.01adityagits a social network site which i had lauched in 2008 which revolves around filling scrap/slam books for students
16:54.19*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
16:54.46adityag1brlcad: i tried working on a few start ups.. i failed every time, so i want to contribute now
16:56.15*** join/#brlcad adityag (~ADITYA@182.237.144.88)
16:59.00*** join/#brlcad adityag (~ADITYA@182.237.144.88)
17:01.27*** join/#brlcad adityag (~ADITYA@182.237.144.88)
17:02.30brlcadadityag: okay thanks!
17:03.44AbhijitKanebrlcad: hi again
17:04.09AbhijitKanewent thrrough a few material database sites - most of them focus on their querying abilities
17:04.24AbhijitKaneranges for value of various properties and things like that
17:05.23AbhijitKane:adityag: hi! where are you from?
17:06.57brlcadAbhijitKane: great
17:07.13*** join/#brlcad adityag (~ADITYA@182.237.144.88)
17:09.06brlcadAbhijitKane: it'd be great to include a rough mock-up of the layout with your application -- wouldnt' have to be anything too complex or fancy but it would give the reviewers a sense of the project goal
17:09.55AbhijitKaneok sure
17:10.21AbhijitKanei don't know if im supposed to ask - but is adityag applying for the same project?
17:10.35brlcadno idea :)
17:10.42brlcadsounded like he was interested in a C project
17:10.49AbhijitKaneohk
17:11.03adityagim interested in any cool projects
17:11.33adityagbrlcad : suggest me the coolest idea from brlcad's list
17:12.17brlcadhelps to include the '-' when referring to the project and without when referring to me .. otherwise just gets confusing ;)
17:12.36brlcadhm, depends how you defined 'cool'
17:13.24brlcadthe first one on the list, NURBS surface-surface intersection calculations is pretty freaking cool, but really frickin' hard too
17:13.43adityag:-D.  Whats the best idea about brl-cad ?
17:13.48brlcadotherwise, what's cool to me isn't necessarily cool to you :)
17:13.58adityaglet me check out
17:14.39brlcadspend an hour or so and go down the list
17:14.50brlcadif the short summary doesn't catch your attention, move on to the next one
17:15.35*** join/#brlcad adityag (~ADITYA@182.237.144.88)
17:16.09brlcadmight have missed me saying "spend an hour of so and go down the list, if the short summary doesn't catch your attention, move on to the next one.."
17:16.22brlcadshould have a great idea by the end which two or three sound the most interesting
17:16.34brlcadrather you pick something YOU like, than it be something I like
17:17.06brlcadeven if it's something simple sounding like cleanup or something complex like nurbs
17:17.25adityagok cool
17:18.08brlcadwe don't really care what you work on -- we want you to become a brl-cad developer merely enjoying what you work on, so maybe you'll keep working on it
17:19.20CIA-52BRL-CAD: 03starseeker * r43964 10/geomcore/trunk/tests/svntest/main.c: OK, get as far as printing out what's in the toplevel directory...
17:26.29*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
17:37.38*** join/#brlcad Ralith (~ralith@d142-058-094-084.wireless.sfu.ca)
17:38.28*** join/#brlcad adityag (~ADITYA@182.237.144.88)
17:41.32adityagbrlcad : can i get my couple of my friends to work with me on Code Refactoring, GUI, Web Developments ? we can work on others too but im pretty sure that we can work on the mentioned topics.
17:47.42*** join/#brlcad Ralith (~ralith@d142-058-094-084.wireless.sfu.ca)
17:58.07*** join/#brlcad adityag (~ADITYA@182.237.144.88)
18:31.53*** join/#brlcad Ralith (~ralith@d142-058-094-084.wireless.sfu.ca)
18:45.45CIA-52BRL-CAD: 03erikgreenwald * r43965 10/geomcore/trunk/src/GS/testclient/gstestclient.c: try to send a disconnect request
18:50.37CIA-52BRL-CAD: 03erikgreenwald * r43966 10/geomcore/trunk/src/GS/testclient/gstestclient.c: glue header magic together. make package display a little more readable
19:03.32CIA-52BRL-CAD: 03bob1961 * r43967 10/brlcad/trunk/src/libged/ged.c: Initialize libged's _FreeSolid list if not already initialized.
19:12.26brlcadadityag: if they're gsoc students, their work has to be independent of yours, but otherwise they're welcome to apply too
19:13.28brlcadthere's no guarantee that any student will be selected really, it really depends how each student is evaluated, how many proposals, what sort of interest there is, etc
19:17.38adityagbrlcad : we could apply to 3 different projects as i mentioned you.
19:27.53*** join/#brlcad kunigami (~kunigami@201.53.192.197)
19:32.51brlcadyou could apply to 3 different projects each -- they'll all still be evaluated independently ;)
19:33.25brlcaddo generally recommend that seriously interested students should apply to at least two topics in case there is a conflict that needs resolving
19:35.12CIA-52BRL-CAD: 03erikgreenwald * r43968 10/geomcore/trunk/src/GS/testclient/gstestclient.c: read node name msg and test magics
19:39.39kunigamihi, I'm interested in the vector output from raytracing: http://brlcad.org/wiki/Vector_output_from_raytracing -- Question: do I have to know beforehand algorithms to fit curves to points or I could learn them during the project?
19:40.16brlcadkunigami: hello!  saw your message to the mailing list
19:41.05brlcadyou can learn them during the project, but you should have some basic references already researched
19:41.39kunigamiPerfect!
19:41.52brlcadtwo or three research papers that do exactly that, understanding the tradeoffs so that you spend most of your time figuring out how to implement the algorithm
19:42.56brlcadthen your proposal should reflect that time with baby milestone steps, more than pure coding projects, so that we can make sure you're making progress
19:43.00kunigamiOk! I'll research some papers on the subject and ask back if they are enough!
19:43.13brlcadlike if you find a particular paper, break the algo up into a bunch of steps that could all be testable
19:45.02kunigamihmm ok. splitting the algorithm is also good for debugging purposes :)
19:56.46brlcadkunigami: how'd you come to our project ideas page?  what's your interest?
20:06.44kunigamiwell, I found BRL-CAD through GSoC page - I didn't know BRL-CAD before. I just searched for "computer graphics" keyword. which is also my interest.
20:09.35kunigamiI've also interest in computational geometry. Last year I tried CGAL, but I couldn't get in touch with them, so I sent my proposal without their review :( Obvisusly it was rejected.
20:11.53*** part/#brlcad adityag (~ADITYA@182.237.144.88)
20:13.25kunigamiI've a particular interest in raytracers. I was going to contribute to yafaray, but this year they didn't get accepted to gsoc. glad to see there's another project that involves ray-tracing \o/
20:18.00CIA-52BRL-CAD: 03erikgreenwald * r43969 10/geomcore/trunk/include/Portal.h: 5309!=0x5309, change this to match the spec.
20:23.46CIA-52BRL-CAD: 03starseeker * r43970 10/geomcore/trunk/tests/svntest/main.c: not working, but checkpointing
21:21.18CIA-52BRL-CAD: 03starseeker * r43971 10/geomcore/trunk/tests/svntest/main.c: Ah, right - path from root, not from model_name
21:46.35Ralithbrlcad: would it be worthwhile for me to apply to work on the toolpath generator?  I'd be happy to discuss the results of my previous participation, if it'd help.
21:50.33CIA-52BRL-CAD: 03starseeker * r43972 10/geomcore/trunk/tests/svntest/main.c: Woot! re-assembles the file, althought we're losing some information at the moment.
21:55.00starseekerabout one minute fifty seconds with that code to process havoc.g
21:56.14starseekerthat's disassembly and insertion, committing, and reconstruction
21:56.50starseekernot handling units correctly yet, or _GLOBAL - probably some other issues
21:58.25starseekerthis API communication may be below the "safe for multiple clients" level, but does give a decent baseline.  There are no working copies used either for insertion or reassembly.  A traditional svn checkout does succeed
22:03.37CIA-52BRL-CAD: 03starseeker * r43973 10/geomcore/trunk/tests/svntest/main.c: Remove some debug statements, use 1 for unit conversion factors...
22:08.42starseekerhumph.  OK, not preserving title, units, color tables, or "region_id" attributes - otherwise g_diff reports nothing
22:10.01starseekerthat's a good note to call it a week on
22:38.18brlcadstarseeker: wow, so 4.5 min reduciton
22:38.21brlcadthat's substantial.
22:40.52brlcadpretty awesome progress, so that's apparently as fast as it'll get for the svn server overhead
22:41.43brlcadpresumably most of that time is spent inserting and committing
22:44.55brlcadkunigami: that's cool, those are sister projects we don't interact with very often, but are in related domains
22:46.01brlcadcgal mostly just because their license is incompatible
22:46.18brlcadkunigami: did you see our yafaray-related project?
22:49.12kunigamino, I didn't. Is it listed in the project ideas?
22:49.20brlcadnot sure.. ;)
22:50.27brlcadthere was an idea at one point to hook into yafaray using our raytracer to shoot the ray, find hit point, then pass off to yafray (I need to get used to using their new name...) for optics calculations
22:50.59brlcadbasically so we can render our geometry using their global illumination model as a plugin to our tracer
22:51.26kunigamiinteresting!
22:51.30brlcadyeah very
22:51.33brlcadBUT ...probably wouldn't recommend it for gsoc unless you were already really familiar with
22:51.38brlcadbrl-cad or yafray
22:51.55brlcadat the source code level, since it's undoubtedly a tricky integration of data management
22:52.30brlcadthough that could be a great out-year project after becoming familiar with the code this summer
22:52.42kunigamihmm ok. I'll consider helping with it afterwards
22:53.17brlcadthe first render project would be a good step towards becoming familiarized with the code
22:53.24kunigamiyes! I hope to learn a lot about ray-tracers :)
22:54.06kunigamiyou mean the "shader enhancements" one?
22:54.11brlcadyeah
22:54.26kunigamihmmm, I'll take a look on it too
22:54.29brlcadhooking in something like OSL would cover related code
22:55.27kunigamiok!
22:56.25brlcadkunigami: what projects were you considering before I mentioned that? :)
22:58.34kunigamiactually only the "vector output from raytracing", but when I joined the room, I got the end of a conversation about applying to more than one project
22:58.39CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2756 10/wiki/Shader_Enhancements: link to main wikipedia article and yafaray
22:58.51brlcadah excellent
22:58.55kunigamiso I'm looking for two projects
22:59.10brlcadyeah, that's perfect
22:59.47brlcadbecause usually we narrow down to the individual first, then pray we've not narrowed down to two students that have proposed the same project
22:59.59brlcadsubmitting two makes that never an issue
23:00.35kunigamihmm ok. good to know that
23:01.02brlcadwow, wikipedia page on shaders doesn't mention OSL
23:01.38brlcadthey're the hot cool new kid on the block for ray tracing
23:02.40kunigamiOSL = open shading language?
23:03.06brlcadyeah
23:03.21brlcadsony imageworks released that project about two or three years ago
23:03.37brlcadit's a shader language specifically tuned to ray tracing
23:03.46kunigamihmm nice! didn't know it
23:04.08brlcadunlike renderman, which was designed for pixar-style micropolygon raster engines
23:05.46brlcadahh, that's why it's not on our ideas list .. it was a discussion with the yafaray devs
23:06.21CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2757 10/wiki/Shader_Enhancements: typo
23:24.05starseekerbrlcad: I'll probably have to have a third go at it using the svn_ra layer (svn_fs most likely doesn't have the multi-client safty features)
23:24.55starseekerthat requires a little more understanding of things like batons though, so I went for the svn_fs approach as faster (and the same split-and-recombine-without-using-files issues had to be addressed, so that will apply)
23:26.45starseekerI think the majority of the time was committing, but inserting was also significant
23:33.08brlcadok
23:33.49brlcadlocking wouldn't amount to 4 min of activity .. had to be lots of i/o, book-keeping, unnecessary allocations, etc
23:34.02brlcadhard to say, would need to profile
23:34.14brlcadthe good news is that the raw server layer is very promising
23:34.48brlcadif we had to, we lock the write session or even lock per node
23:35.05brlcador profile and optimize their code
23:35.11brlcadeither way, very promising
23:35.36brlcadstill waiting for that magical "holy crap" moment where it drops to sub 5sec :)
IRC log for #brlcad on 20110326

IRC log for #brlcad on 20110326

00:09.54CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2758 10/wiki/Backstaff: kiss down to 3
01:10.21*** join/#brlcad crazy_imp (~mj@a89-183-83-230.net-htp.de)
01:14.30CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2760 10/wiki/Backstaff: add the backstaff image with left/right alignment now working on images (style.css was missing juju)
02:00.37starseekerbrlcad: <snort> not with Mac file IO and a filesystem based backend
02:02.14starseekerhmm - apparently, all public subversion APIs are concurrent-safe, both interprocess and intraprocess
02:03.44starseekerhttp://mail-archives.apache.org/mod_mbox/subversion-users/201103.mbox/%3C20110325234038.GA12220@daniel3.local%3E
02:06.27starseekerwill have to decide what to do about _GLOBAL, since it doesn't work as an exported object
03:26.34*** join/#brlcad adityag (~ADITYA@182.237.144.88)
03:33.18*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
03:37.38*** part/#brlcad adityag (~ADITYA@182.237.144.88)
03:44.57*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
03:59.58*** part/#brlcad kunigami (~kunigami@201.53.192.197)
04:13.47brlcadstarseeker: my timing tests manually breaking up the file and recombining were all on mac
04:16.16brlcad_GLOBAL is really just a collection of attributes on the file namespace
04:18.10brlcadso for now you can just create a dir/comb representing the file (e.g., "havoc.g") that unions all of the top-level objects that were in that file and assign all _GLOBAL attributes to it, perhaps one additional "cad::namespace=true" attribute
05:17.07brlcadstarseeker: I'm trying to recall, what was the issue you ran into using opengl to tessellate/render NURBS?  was it the trim curves?
05:58.18*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
05:58.18*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
IRC log for #brlcad on 20110327

IRC log for #brlcad on 20110327

08:25.30*** join/#brlcad ibot (~ibot@rikers.org)
08:25.30*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110325 || Welcome GSoC 2011 participants! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011
08:27.57*** join/#brlcad adityag (~ADITYA@182.237.144.88)
08:47.23*** join/#brlcad adityag (~ADITYA@182.237.144.88)
08:58.08*** join/#brlcad adityag (~ADITYA@182.237.144.88)
10:14.56*** join/#brlcad piksi (piksi@pi-xi.net)
13:00.16*** join/#brlcad kunigami (~kunigami@201.53.192.197)
13:50.28*** join/#brlcad adityag (~ADITYA@182.237.144.88)
15:16.17*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
15:23.50kunigamihi all, I'm studing mged code in order to fix the bug "gets stdin myinVar" fails - ID: 3087665 http://sourceforge.net/tracker/?func=detail&aid=3087665&group_id=105292&atid=640802
15:24.01kunigami<PROTECTED>
15:24.05kunigamiI though that input was read through a callback too (stdin_input) but it seems that in mode interactive and not classic_mged, the callback isn't set
15:24.09kunigami<PROTECTED>
15:24.12kunigamithanks!
15:39.45*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
16:02.31brlcadAbhijitKane: glad to hear the research continues, and expected regarding alloys and polymers -- from our perspective we treat materials as strictly homogeneous matter
16:03.23brlcadbhinesley: yeah, don't worry about line length
16:04.38brlcadkunigami: oof, that's a tricky one since mged input is handled in a variety of ways
16:04.48brlcadinput is left up to tcl most of the time iirc
16:44.15kunigamihmm ok. One thing I noticed is that when we don't redirect stdout/stderr to tclchannels (I commented out in the code). The output, now printed to terminal, does not show that bug
16:52.55kunigamiI'll try to go back to this bug another time. I'm switching to the to-do list of brlcad :)
16:53.04kunigamiThere's this one:  bu_basename() says it'll return things that it probably won't
16:53.05kunigami<PROTECTED>
16:53.05kunigami<PROTECTED>
16:53.05kunigami<PROTECTED>
16:54.21kunigamiindeed, it says that "/" should return "/" and "a/" return "a", but for both cases the actual code is returning the empty string
16:54.42kunigamiwhat is to be done: change commentaries or the code?
17:14.50brlcadkunigami: the redirection is definitely the "cause" of the bug -- it's more making sure the logic is appropriate for both console mode (where there shouldn't be redirection) and graphical mode (where there is redirection) and console mode that invokes the graphical mode (where there are multiple output streams)
17:15.10brlcadkunigami: the code should be fixed
17:15.55brlcadfor bu_basename() .. it should basically behave identical to basename(); it's really just a wrapper for platforms that don't have basename()
17:16.18brlcadthe initial naive implementation was just a little too hastily coded
17:17.00brlcadthat would should be pretty easy to code from scratch or find a bsd reference impl
17:19.22kunigamiI see. I'll do it then! thanks
17:34.40brlcadthank you, awesome
18:05.34kunigamihmm there are some issues though: I need to modify the string if it is for instance "a/" (it should return "a"). An option would be allocating space for a new char array, it that ok?
18:06.29kunigamithis memory will probably never be deallocated, but I not sure if it's a problem
18:06.32*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
18:09.45AbhijitKanebrlcad: any updates on the database schema?
18:20.19starseekerfor those interesting in watching an animation of part of the BRL-CAD source code history (a small part, admittedly):
18:20.26starseekerhttp://bzflag.bz/~starseeker/brlcad-gource.avi
18:20.40starseekerthat's the gource tool brlcad found
18:23.05brlcadstarseeker: awesome!
18:23.39brlcadstarseeker: what settings did you use?
18:23.49brlcadand how did it take you to render it to video?
18:29.55brlcadAbhijitKane: I found everything, so no worries there
18:30.30starseekerbrlcad: was a combination of yukon video capture, seom-filter, mencoder
18:30.33brlcadin fact, the dev site is still on-line .. just no means for online auth
18:30.36brlcadmater.brlcad.org
18:30.41starseekerdon't seem to have the exact settings used for gource
18:31.28starseekergrabbed mencoder settings from here: http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-x264.html
18:31.43starseekerseom-filter yukon.seom | mencoder - -ovc x264 subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b -vf scale=512:384 -o file.avi
18:32.23brlcadoh, it's not the whole video
18:32.28starseekerright
18:32.44AbhijitKanebrlcad: great. i checked a few material databases - they bascially divide all their data into polymers and alloys
18:32.52starseekerjust thought I'd put up a subset for those interested in seeing something
18:32.53brlcadahh, looks like you have the same settings too
18:33.01AbhijitKanethen there are different methods for searching through each subset
18:33.04brlcadi made a few source code mod improvements
18:33.23brlcadnever used seom-filter
18:33.34starseekerit goes along with the yukon thing
18:33.47starseekerhttps://devel.neopsis.com/projects/yukon/wiki/HowTo/Install?version=15
18:33.49brlcadalso a tiny video relative to what I was trying to capture
18:33.54brlcadwas going for 720p
18:34.01brlcadwell, originally 1080p :)
18:34.09starseekerhttps://devel.neopsis.com/projects/yukon/wiki/HowTo/Capture
18:34.09brlcadthat would have filled this hd fast
18:34.42starseekernods - yeah, mine is just the "here's something cool" sample, not the canonical video
18:34.43brlcadmaybe I can just send you my mods and settings.. :)
18:35.09starseekerheh - and watch my pathetic little PC fry ;-)  Still may be worth a shot
18:35.28starseekerhowever, the raw capture on just that part of the animation was 8 gigs
18:35.46brlcadwell your video still looks better than mine, I was going to resort to the built-in ppm stream
18:36.26starseekerwhat were your source mods?
18:36.48brlcadnothing major, the big one was to make the nodes have a little more separation
18:36.54brlcadand I think that one was a data mod
18:37.04brlcadthe other was control on the font size
18:37.21starseekernods - cool. If you want to tar it up, I can give it a whirl
18:37.32brlcadthere is an advanced font-size option, but it doesn't affect any of the node labels, just the title
18:37.58starseekerdid you send them back upstream?
18:38.03brlcadthe way it is now, it's a jumbled mess if the dir has more than about a dozen files in it and they're all edited
18:38.33brlcadwith this, you can read most of them without overlap just by increasing the spacing slightly and decreasing the font slightly
18:38.34starseekeroh, there's my gource terminal
18:38.41starseekeryukon ~/gource-0.32/gource -p 0.8 -a 1 -s 1
18:39.35starseekerthis thing would make an awesome screensaver
18:39.48brlcaderm, now to remember what the short-hand opts were
18:40.31starseekerI think those were just to keep things moving rather than pause while waiting for the time to advance to the next commit
18:40.37brlcadsettings I was using last:  brlcad.org/tmp/CONFIG.gource
18:40.45brlcadthough I was constantly tweaking
18:41.21brlcadah right hilighting too
18:41.39brlcadmade it so that commiters were slightly larger and always highlighted so you could distinguish them from the source nodes
18:41.53brlcadthey get really lost with the defaults and a big tree
18:42.00starseekernods
18:42.13brlcadlemme see if I can pull a patch
18:42.32starseekercan gource handle our full history?
18:43.05starseekerthat's a stress test and a half
18:43.53brlcadif you skip forward in time, it gets totally screwed up -- the layout engine can't solve a suitable graph fast enough so it oscillates horribly
18:44.09brlcadit does handle the full history, takes a couple min to load
18:44.22brlcadif you let it build up the graph incrementally, works just fine
18:44.51brlcadwanted to compare two videos, one where we don't remove any nodes -- let the additions and deletions remove them instead of the time-based removal it uses by default
18:45.06brlcadthen let it do something more like the default for unchanged nodes face away
18:45.29brlcadso you see where the action is at, instead of full view of the project
18:45.45brlcadAbhijitKane: haven't forgotten about you -- just a few secs
18:45.52AbhijitKanehaha...sure
18:46.08starseekerbrlcad: if it can do the full node graph, that'd be cool
18:46.56brlcadI think it can .. that's where the ppm stream frame dump may be required though
18:47.17brlcadon mine it really bogs down to < 1fps if there's a massive tree edit
18:47.26starseekerah, so definitely beyond my machine for that one then
18:47.28brlcadlike in 2004 during the conversion
18:47.44brlcadit catches back up, just slows the animation to a halt
18:47.58brlcadso if you're capturing video directly from the window, it'd suck
18:48.00starseekeryeah, that's gonna need a ppm dump
18:48.08brlcadbut letting it take its time and compute frames, it'd be fine
18:48.14brlcadhow much disk you have?
18:48.15brlcad:)
18:48.21starseekernot that much :-P
18:48.47starseekermy biggest drive is an external 1 terabyte, and that's got all my backup stuff
18:48.51brlcadI think I calculated it'd be around 90GB for the stream at 720p
18:48.53starseekerplus it's slow as a dog
18:49.11starseekerah - I've got over a 100 gigs on my main drive
18:49.32brlcadthat should compress down to less than 1GB for the full video
18:49.43brlcadbut just take a day or so to process
18:50.08brlcaduploaded to http://brlcad.org/tmp/gource
18:50.16starseekerhow much disk space do you have handy?
18:50.17brlcadreplaces one of the files in data/
18:50.24brlcadi only have 5GB at the moment
18:50.43starseekercan gource give me ppm frames as it currently stands?
18:50.49brlcadyep
18:50.52brlcadone of the options
18:51.34brlcadffmpeg will read the ppm stream as is
18:52.05starseekeruh... I don't have a config file in data
18:52.41brlcadgource --load-config CONFIG.gource --output-ppm-stream frames.ppm
18:52.56brlcadno, that config file is a cmd-line option
18:52.57starseekeroh, gotcha
18:53.01brlcadthe file.png goes into data
18:53.08starseeker(thought that was one of the source code mods)
18:54.41kunigamihi, I just sent a patch to the patch tracker. Any commentaries and suggestions are welcome. Thanks :)
18:55.23brlcadstarseeker: pulling the source mods now
18:57.54starseekerah, ok - you're filtering out src/other I see
18:58.21brlcadstarseeker: uploaded patch.diff
18:59.05brlcadkunigami: fantastic .. it'll definitely get reviewed
18:59.36brlcadkunigami: include a web link in your application to your patch, that helps save some time figuring out who is who
18:59.59brlcad(not to mention your irc name, contact info, etc..)
19:00.14starseekerbhinesley: be sure to link to your patch(es) too
19:00.58brlcadAbhijitKane: glad to hear the research continues, and expected regarding alloys and polymers -- from our perspective we treat materials as strictly homogeneous matter
19:02.06AbhijitKaneoh, so i guess you don't store many of the properties that the other databases do
19:02.41brlcadAbhijitKane: right now today, we only really care about density directly, and indirectly care about a half dozen other props like young's modulus
19:02.55kunigamiok!
19:03.28kunigamiI'll turn now on composing my proposal.
19:03.42brlcadgreat
19:04.00AbhijitKaneohk
19:04.35AbhijitKaneso the searching will just be based on these properties right?
19:04.42brlcadstarseeker: patch apply alright?
19:04.54brlcadI didn't scrutinize it too closely
19:04.59starseekerthe sketch one?  Haven't had a chance to try it yet
19:05.07brlcadno, the gource patch
19:05.14starseekeroh :-)
19:05.31starseekeryep, just my ftgl.h was in a slightly different location then configure.ac wanted
19:05.42brlcadmy patch changed that too
19:05.54brlcadjust turned off the check and linked -lftgl :)
19:06.01starseekerah :-)
19:06.21starseekerwell, just compiled file - so about to give it it's initial trial
19:06.36brlcadwas nice to see that it works cleanly against ftgl trunk
19:07.02brlcadwe'd restructured things quite a bit, but trying to preserve the compile-time interface
19:07.19brlcadeven run-time should be backwards-compatible
19:08.58starseekerbrlcad: where's a good place to grab BRL-CAD_64x64.png?
19:09.09brlcadoh right
19:09.21brlcadhttp://brlcad.org/images/logo/
19:11.06brlcadskips src/other, also skips dpk commits (jove dev)
19:11.14starseekernods
19:11.32starseekerbit of a shame to skip the step and opennurbs work, but saves a lot of other cruft
19:11.45brlcadyeah
19:12.05brlcadcould get more creative with the regex, but it's pretty darn complex as it is
19:12.15starseekernods
19:12.24brlcadbigger issue is the length and speed of the animation
19:12.29starseekeralrightie, let's see what happens here...
19:12.35starseekerReading Log...
19:13.05starseekeris this the config that keeps all the nodes?
19:13.10brlcadnext thing I was going to try was allowing a bigger timescale .. it won't let you go over 4x right now .. 4 days per second
19:13.44brlcadI think so
19:14.09starseekercan I get away with piping this into ffmpeg, or will that preserve all the pauses for the long builds?
19:15.15brlcadah, this one was a balance .. keeps nodes for 5min .. which should pretty much keep the whole graph most of the time
19:15.50brlcadsince 5min is 300 sec is 1200 days is a lil over 3 years
19:16.02starseekernods
19:16.26brlcadall source code is edited annually for the copyright update, so should keep the bulk of the tree at least from 2000 forward
19:16.38brlcadyou should be able to pipe directly
19:16.52brlcadbut I'd check the output first, letting it run
19:17.07brlcadhm!
19:17.23brlcaddidn't think of that.. that might even be a way to avoid writing out 100GB .. duh
19:17.28starseekerstill loading...
19:17.38brlcadyeah, takes a couple min
19:18.48starseekeris going with the default ffmpeg string on their site for now
19:20.05brlcadcool
19:20.11starseekerbrlcad: you realize I won't be able to give ``Erik a hard time when he complains about how much space docbook takes up?
19:20.43brlcadI'm motivated to try it streaming here myself, but need to get my butt over to the gym.. haven't been sick like this in a while, probably due to gym slacking
19:20.59starseekerwinces - I should be in the gym too
19:21.53starseekerah, there we go
19:21.59starseekerit begins with mike
19:22.27brlcadyep
19:22.36starseeker1993
19:22.40brlcadthe begining year or two is actually pretty cool
19:22.54brlcadI had it skip .1
19:23.33brlcadwas initial attempt at skipping dpk's commits, but then later found the other option, so can probably remove it back to skipping 0
19:24.06brlcadhow does it look?
19:24.28starseekeron screen it's OK - not sure about the video yet
19:25.18starseekerwill stop it and restart - that shoudl be enough to test
19:25.54starseekerhah, awesome
19:26.03starseekerthat should do it!
19:26.09starseekersets up for the full run
19:36.51brlcadawesome
19:36.53brlcadset the skip to zero?
19:41.06starseekeruh - opps - was just using your settings
19:42.21starseekerrestarts again
19:44.54starseekerbrlcad: which setting are you referring to?
19:44.56starseekerstart potition?
19:45.03starseekerer start-position?
19:45.04brlcadthe one that says 0.1
19:45.07brlcador .1
19:45.10starseekerok, I see it
19:45.56starseekerhopefully screensaver won't bother this... not sure how to disable power save...
20:08.18*** join/#brlcad sachi1325 (75d3557b@gateway/web/freenode/ip.117.211.85.123)
20:57.25*** join/#brlcad sachi1325_ (75d3557b@gateway/web/freenode/ip.117.211.85.123)
21:07.33*** part/#brlcad adityag1 (~ADITYA@182.237.144.88)
22:52.09kunigamiis there any reference on brlcad system or do I have to study the code?
22:53.01kunigamioops
22:53.17kunigamiI mean brlcad shader system
22:53.47``Erikgoing to just have to look, they're in src/liboptical/
22:54.35kunigamiok
22:54.38kunigamithanks
22:57.15kunigamiforgive my ignorance, but there are two distinct things: shader language and a shader system, right?
IRC log for #brlcad on 20110328

IRC log for #brlcad on 20110328

00:12.47brlcadkunigami: they imply different concepts, so yes
00:13.07brlcadthe language just describe *how* something should be rendered
00:13.21brlcadthe shader system implements the rendering
00:23.11kunigamihmm, in liboptical we have a shader language or a shader system?
00:33.38brlcadheh, system
00:35.38brlcadthe shader strings we set on objects could be construed as a primitive language, example: "plastic di=0.4 sp=0.2" another "stack {{plastic} {texture src="file" name="foo.png"}}"
00:39.42kunigamicool. I think I'm understanding
01:05.44kunigamiI saw your commentary on my patch. I'm switching from malloc/strncpy to the wrapped version. bu_malloc has a const char *parameter, but I couldn't get its meaning from the commentaries. Looking its definition, it seems that it has debug purposes (or not?). So I'm passing NULL to this function. Is that ok?
01:10.44*** join/#brlcad crazy_imp (~mj@a89-182-222-119.net-htp.de)
02:25.29*** part/#brlcad kunigami (~kunigami@201.53.192.197)
03:21.48starseekerfull movie clocks in at just over a gig
03:34.14starseekerand just over 45 minutes
03:34.36starseekerlayout's a bit skewed by trunk and brlcad always being present
03:36.25starseekerbrlcad: I'll probably have to bring you a dvd - I don't know that my upload connection will tolerate such a huge upload even if bzflag has room
06:18.42*** join/#brlcad bhinesley (~bhinesley@adsl-99-125-83-101.dsl.bkfd14.sbcglobal.net)
06:20.51bhinesleyI'm having build issues in Windows/Cygwin. Is Cygwin used to build the releases of BRL-CAD?
06:23.58bhinesley*windows releases
06:33.39CIA-52BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2761 10/wiki/User:Bhinesley: /* Checklist */ Updated status
06:34.33CIA-52BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2762 10/wiki/User:Bhinesley: /* Checklist */ removed item no longer working on
06:43.12*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
06:52.58*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:28.05bhinesleyNevermind, found README.Windows
10:05.04brlcadstarseeker: more importantly, does the graph go nuts after 2004?
10:06.13brlcadbhinesley: it's not, but it 'should' build .. it's just not a configuration that's tested very often at all.  shouldn't be more than a few minor tweaks but if it is, that could be a patch submission
10:12.42*** join/#brlcad sachinjain (~sachin@117.211.88.150)
10:13.16brlcadhello sachinjain, what's your question?
10:13.57sachinjainyeah...
10:14.27sachinjainI was talking about the project....."Vector output from raytracing"
10:15.31sachinjainI wanted to know.....how does brlcad generates raster images?
10:15.40brlcadthrough raytracing :)
10:16.05dlomanMernin all!
10:16.14sachinjainso....it generates a set of pixels?
10:16.17brlcadso a ray is fired for every pixel, if it hits something, that pixel is shaded according to the properties of what it hits
10:16.21brlcadhello dloman
10:16.46sachinjainok...
10:17.22sachinjainso...what do u mean by "generate vector drawings"
10:17.42sachinjainwe can only generate vector drawings if we assume that we have raster image
10:18.12brlcadthe idea with getting vector output is two-fold -- you either are going to still shoot rays and interpolate vector lines (i.e., edge/object detection) ... OR ... you're not really going to shoot rays but instead extrace outline representations "somehow" and project those onto a vector image plane
10:18.44brlcads/extrace/extract/
10:20.07sachinjainI have done a project....where I have to a construct a vector image out of raster image
10:20.18sachinjainby using bezier splines
10:20.30brlcadthat would be the first method I mentioned
10:20.37sachinjainhmmm
10:21.08brlcadit can work that way, but you have to be really careful about how those curves are constructed
10:21.36brlcadthey don't tend to sample well for small resolution images
10:21.43sachinjainyeah
10:21.57sachinjainhow small resolution images are we talkin about?
10:22.07brlcadyou either need to really increase the grid size or you need adaptive sampling where there are areas of large derivatives
10:22.24brlcadit's user-specified, so pretty much anything
10:22.33brlcadit should still give a sensible result though
10:22.59brlcadif it's basically giving the raster image scaled, that's rather useless
10:23.18brlcadthe whole point is to have smooth edges that scale and interpolate cleanly
10:24.43brlcadthat's why the method that doesn't involve sampling is superior, but a bit harder
10:25.09sachinjainso what other method you can suggest?
10:25.33brlcadyou extract outline representations "somehow" and project those onto a vector image plane
10:25.45sachinjainyou mean the second approach
10:25.45sachinjain?
10:26.01brlcadthat would be the other method
10:26.35brlcadnote that there are lots of degrees of freedom here
10:27.14sachinjainwhat do you mean by "extracting outline representations"?
10:27.31brlcadyou could, for example, query each individual primitive, shoot a grid of rays at it, evaluate bezier curves for that outline, then perform boolean evaluation of the bezier curves all the way back up to the resulting vector iamge
10:28.28brlcador instead of shooting a grid of rays, you could use the conversion to a boundary representation format (NURBS) and then calculate the edge contours from the NURBS surface, and once again, perform boolean eval of those curves up the hierarchy
10:30.45*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
10:31.44brlcadsachinjain: feel free to post any more questions if they come up -- it's a tricky subject but if you already know how to interpolate bezier curves then you already have an advantage
10:31.57sachinjainyeah.....I know
10:32.01brlcadotherwise, I have to go walkabout for a bit to tame this congestion
10:32.02sachinjainhow to interpolate
10:32.54sachinjainbut...I am still trying to understand your above suggestion
10:37.10sachinjainok....
10:37.21sachinjainso what I understood from your explaination
10:37.24sachinjainis that
10:37.36sachinjainfor every object in a scene
10:37.51sachinjainwe find the outline of that object
10:38.09sachinjainconstruct a bezier curve on that outline
10:38.10brlcadyes
10:38.29sachinjainn then do some...."boolean evaluation"
10:38.41sachinjainwhat is this boolean evaluation?
10:39.12brlcadhttp://en.wikipedia.org/wiki/Constructive_solid_geometry
10:39.42brlcadso look at that image on the bottom right
10:40.04brlcadthat's basically our CSG hierarchy, with primitives at the bottom, boolean operations that combine them up to the final image on the top
10:40.10sachinjainhttp://en.wikipedia.org/wiki/File:Csg_tree.png
10:40.12sachinjainthis one?
10:40.16brlcadwe want a vector version of what is on top
10:40.24brlcadyes
10:41.08sachinjainhmm
10:41.15sachinjainthat seems pretty interesting
10:41.22brlcadgotta run, others in here should be able to help further .. look forward to talking more!
10:42.21sachinjainyeah sure
10:42.26sachinjainsome specific time?
10:43.01sachinjainlast question...what do I need to have...to work upon this project?
10:44.44sachinjainHi starseeker
10:45.52dlomansachinjain: 'what do I need to have' ....as in software installed on your computer?
10:46.24sachinjaindloman: I didn't got u
10:46.25sachinjain?
10:48.00dlomanyour question: "What do I need to have...to work upon this project?"
10:48.12sachinjainyeah
10:48.15dlomando you mean: "What software do i need to have installed to work on this project?"
10:48.30sachinjainI already have that software installed
10:48.51sachinjaintrying to go through its documentation
10:49.16sachinjainis there any specific part of documentation which I need to go through...for this project
10:50.25dlomanyou are working on the  "generate vector drawings" that you and brlcad were talking about just a few minutes ago?
10:50.35sachinjainyup
10:50.54sachinjainI think I got the whole idea of the project
10:51.38dlomanI'm no expert, but I'd suggest diving into the code.  libbu was the most informative library for me when I started, and I'd imagine libRT will be very good for you also.
10:54.42sachinjainwhere can I find these libraries?
10:55.04dlomanin the source code:  /src/libbu and /src/librt
10:55.32dlomantheir header files would also be good to start with:  /include/bu.h and /include/rt.h
10:59.46sachinjainthere is no such file in this path
10:59.57sachinjain:-/
11:00.16sachinjainI am working on windows
11:00.33sachinjainand the version installed is 7.14.8
11:00.45dlomanah, winderz.
11:00.59sachinjainshould I do my work in linux?
11:01.03dlomanokay then, wherever you have it installed:
11:01.13dloman<installpath>/include/bu.h
11:01.25dloman<installpath>/include/rtfunc.h
11:01.32dloman<installpath>/include/rtgeom.h
11:01.33sachinjainno file with name "bu.h"
11:01.58sachinjainI can only find "rtgeom.h"
11:01.59dlomanwell that's not right
11:02.11dlomandid you download binaries or the source?
11:02.32sachinjainjust the exe files
11:02.33sachinjain:D
11:02.36sachinjainfile*
11:02.47dlomanah, well then that's the issue.
11:02.58dlomanif you are going to develop, you are going to need to get an SVN checkout
11:02.59sachinjainhmm
11:03.08sachinjainon eclipse?
11:03.41dlomanthat's one way to do it, however, I have never built brlcad using eclipse... so i dunno if its possible.
11:03.55dlomanmost windows developers for brlcad use some flavor of visual studio
11:04.02sachinjainohhh
11:04.14sachinjainbtw...is it easy to do through linux?
11:04.28dlomanin my opinion, yeah, much easier.
11:05.03sachinjainok...so I can work on one of my servers....
11:05.06sachinjainit has got linux
11:05.40sachinjainhow do I get binaries or source on linux?
11:05.56dlomanhow familiar with *nix are you?
11:06.22sachinjainnever heard of it
11:06.24sachinjain:-/
11:06.45dloman*nix == unix, linux, bsd, etc
11:06.48dlomangeneral term
11:06.52dlomanaka 'not windows'
11:06.56sachinjainkk
11:06.57sachinjainkk
11:07.09sachinjainvery familiar
11:07.10sachinjainthen
11:07.25sachinjainI do all my coding on unix only
11:07.42dlomanjust get an svn checkout of the brlcad repository.
11:08.27dlomanhttp://sourceforge.net/scm/?type=svn&group_id=105292
11:08.59dlomanaka: svn co https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk directoryOnYourHD
11:10.13sachinjainso...I have to just run this command....
11:10.18sachinjain"svn co https://brlcad.svn.sourceforge.net/svnroot/brlcad brlcad"
11:10.40dlomanwell, that's the generic 'svn checkout' command that sourceforge gives
11:10.49dlomanthe proper version of it is what i wrote above
11:11.03dlomanare you familiar with using Subversion at all?
11:11.12sachinjainkk
11:11.19sachinjainI have used once
11:11.24sachinjainwhile building a compiler
11:11.31dlomanokie
11:11.42dlomanthere's plenty of tutorials on the net
11:11.49dlomanbut all you really need to know are:
11:12.02dlomansvn checkout (or: svn co)
11:12.10dlomansvn commit (or: svn ci)
11:12.12dlomanand
11:12.15dlomansvn up
11:12.20sachinjainokie
11:12.32sachinjainI am following them
11:12.58dlomanhowever, commit permissions are not automatically granted and you will likely have to 'submit a patch' via the sourceforge website.
11:13.14dlomanonce you get the code checked out, lemme know.
11:13.21sachinjainkk
11:13.23*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
11:13.26dlomani *should* be here for the next 8 (ish) hours.
11:13.44sachinjainI will try to do that...as soon as possible
11:15.00dlomanis diggin the new GSoC web UI.
11:24.32dlomanhrm... where's my profile editing link?  Not liking the new UI that much anymore... its pretty, but that's about it.
11:27.33dlomanNice... I can't 'apply' to be a mentor without first applying to be part of GSoC.  But the only way to be part of GSoC is to apply to be a mentor.  LOL  i love it.
11:30.30sachinjainhey dloman....where are you from?
11:30.53dlomanI am currently living in Pennsylvania, USA
11:30.54dlomanyou?
11:31.30sachinjainI am living in Hyderabad, india
11:32.21sachinjainso...you are one of the developer in BRL-CAD?
11:33.58dlomanA newbie, but yeah :)
11:34.24sachinjainit seems a very big open source project
11:39.05sachinjainhow much time does it generally takes to download all the source and binaries...
11:39.19sachinjainthrough brl-cad repository
11:39.48sachinjainits taking a hell lot of time
11:43.54dlomanits abig repo.  we maintain nearly all required deps internally in case they are not present on the current system.
11:54.52sachinjainokie....while other files are being downloaded
11:54.57sachinjainI have
11:55.01sachinjain"ru.h"
11:55.09sachinjain"rtedge.h"
11:55.15sachinjainn "rgeom.h"
11:55.22sachinjainwhat should I do with them?
11:55.39dlomanI'd say read them.  Get to know the code base a bit.
11:56.04dlomanbefore you can do any develop that's worth anything, you have to get familiar with the existing code.
11:56.18dlomannot *all* of it, but enough to know where you will be primarily working.
11:57.53sachinjain"ru.h" is very big
11:58.05sachinjainhow can I get familiar with something like that
11:58.07dlomanbu.h?
11:58.12sachinjainyeah....
11:58.15sachinjain"bu.h"
11:58.52dlomanI'd think that looking at the build system, seeing what executables and libraries are made is a good start
11:59.19dlomanlaunch mged and get a feel for what brlcad's primary modeler looks like.
11:59.39dlomanthen start tracing backwards from the build system.
11:59.50dlomansee what the app touches in the way of source files.
12:00.15dlomanthat should give you a feel for where your project fits in to the big picture, 'source-wise'
12:00.54dlomanits a big code base and takes years to get familiar with, so don't sweat it if its still mostly foriegn to you at the end of hte summer :)
12:01.14*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
12:04.04CIA-52BRL-CAD: 03davidloman * r43974 10/geomcore/trunk/include/IDataSource.h: Require classes implementing IDataSource to have a init() fn. (Even if its a stub). This is needed for both the FS data source(DS) and SVN DS.
12:05.06CIA-52BRL-CAD: 03davidloman * r43975 10/geomcore/trunk/ (include/FileDataSource.h src/GS/FileDataSource.cxx): Implement minimal init() checks for the FS DataSource.
12:05.53sachinjainis there any README file?
12:06.06dlomanyes, should be in the root of the checkout.
12:12.34CIA-52BRL-CAD: 03davidloman * r43976 10/geomcore/trunk/include/FileDataSource.h: Oops. Can't make an interface mandated function private. Change visibility to public.
12:22.42CIA-52BRL-CAD: 03davidloman * r43977 10/geomcore/trunk/src/GS/FileDataSource.cxx: Log success/failure of IO tests on the repo path.
12:24.37dlomanbrlcad: How does Ohloh know about the brlcad repo?  Did you have to add the url to ohloh's database or did it just all happen automagically?
12:25.00dlomanI only ask cause it seems that ohloh isn't seeing the /geomcore module.
12:25.13dlomanand was wondering if that new module needs to be added somewhere
12:26.40dlomanhah, nevermind.
12:58.19CIA-52BRL-CAD: 03davidloman * r43978 10/geomcore/trunk/src/GS/GeometryService.cxx: Quick Type Fix
12:59.53CIA-52BRL-CAD: 03davidloman * r43979 10/geomcore/trunk/src/GS/DataManager.cxx: Wire in FileDataSource init() call and return check.
13:08.51dlomandigs into coreInferface. Need to get ejumakated on dis.
13:15.43*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
13:30.23CIA-52BRL-CAD: 03Dloman 07http://brlcad.org * r2763 10/wiki/TypeOnlyMsg: Enter the simple wiki page for TYPEONLYMSG
13:32.03CIA-52BRL-CAD: 03Dloman 07http://brlcad.org * r2764 10/wiki/NetMsgTypes: Admit that this list is not up to date :(
13:36.02``Erik*readreadread* yowza, blew out my buffer this weekend O.o
13:37.28CIA-52BRL-CAD: 03Dloman 07http://brlcad.org * r2765 10/wiki/GenericFourBytesMsg: Remove caps
13:37.40sachinjainDloman: From where should I start checking binary files
13:37.45sachinjainI am stuck all along
13:37.53dloman'stuck' ?
13:38.00dlomanas in you are lost in the code ?
13:38.06sachinjainI mean...I dont know from where should I start
13:38.17sachinjainwhich file should I look into
13:38.28sachinjainfirst
13:38.42dlomanhave you compiled yet?
13:38.45CIA-52BRL-CAD: 03Dloman 07http://brlcad.org * r2766 10/wiki/GenericEightByteMsg: Write up description for GenericEightByteMsg
13:39.12sachinjainI have run....
13:39.15sachinjainsh autogen.sh
13:39.19sachinjain./configure
13:39.22CIA-52BRL-CAD: 03Dloman 07http://brlcad.org * r2767 10/wiki/GenericEightByteMsg: Drat! CopyPaste strikes again! Fixed.
13:39.31sachinjainn now.."make" is running
13:40.17dloman``Erik: any 'esssssspert' advice on where a good starting point for learning the code is?
13:40.42``Erikum, to what end? there're lots of good starting points for different end pionts
13:40.43``Erikpoints
13:41.13dloman"generate vector drawings"
13:41.45sachinjainyeah...erik...
13:41.46``Erikhrm, like an svg outputting tool with an rt interface? lemme read the wiki
13:41.49sachinjainplease help
13:42.57``Erikobviously, check out http://brlcad.org/wiki/Google_Summer_of_Code/Checklist
13:42.59CIA-52BRL-CAD: 03Dloman 07http://brlcad.org * r2768 10/wiki/NetMsgTypes: Add in some descriptions for the simpler messages
13:43.45dloman``Erik: FYI the wiki was correct on the PING and PONG.  HEADER + a single 8byte field.
13:43.56``Erikdoh, musta missed that
13:44.11``Erikhttp://brlcad.org/wiki/Vector_output_from_raytracing lists some useful tools/files to look at
13:44.32dlomanno worries, i only write wiki pages in bad-engilsh and stupid.  You should feel good you're not fluent in those :)
13:45.18``Eriknah, I'm used to seeing pings only done as "send a ping, save my time locally... wait for the response, compare it to the local time", since clock drift between two machines is inevitable
13:46.13``Erikmy guess is that brlcad means to take an approach similar to rtedge (src/rt/viewedge.c) to sample and then string it together into a vector set by line/curve fitting
13:47.02``Erikso running rtedge and looking at viewedge.c would be the right beginning point for the BRL-CAD side, the papers good for the algorithm, then figuring out the ps/pdf/svg format for the write phase
13:47.18sachinjainjust these two files
13:47.28sachinjain"src/rt/viewedge.c"
13:47.36sachinjain"src/rt/view.c"
13:47.37sachinjain??
13:47.54``Erikthat's the starting point... in understanding how it works, many other files will be involved :) all the way down to libbu stuff
13:48.33``Erika tool like cscope (or an IDE that does that kind of thing) can be very useful in exploring
13:50.38``ErikI wonder if finishing up the 'time per ray' raytracer would be a good "acceptance patch"
13:52.58dlomanhey brlcad: Can i write the GS in java?  I'd be done by the end of the day! ;)
13:53.16dlilooks like brlcad need to update 7.18.4 ETA daily :)
14:00.14d_rossbergdloman: any questions about the coreInferface?
14:00.28*** join/#brlcad sachi1325_ (75d3557b@gateway/web/freenode/ip.117.211.85.123)
14:02.52dlomand_rossberg: not yet, still reading :)
14:09.30starseekerdloman: depending on where we are Wednesday, you may have to try it :-/
14:09.53dlomani just cant seem to program fast in c or c++ :/
14:10.13starseekeris down the svn rabbithole
14:10.41starseekerdloman: if it really would help, can you prototype the whole thing in java in a day and have something working?
14:10.55dlomanquite likely
14:11.26starseekerunless ``Erik disagrees, I'd say having SOMETHING that runs is critical right now
14:11.42dlomancurrently, it runs just fine =D
14:11.50starseekergeometry is moving across the wire?
14:12.05dloman.... it runs just fine! =D
14:12.23starseekerlol
14:13.05starseekerI can disassemble and reassemble most (not all) of the .g, but I can't yet apply changes
14:13.37starseekerthat's what I'll be having to tackle over the next few days
14:14.39starseekerI'm hoping the file backend will suffice to iron out the "moving bits of geometry across the wire" issues (even if the .g file is a rather... large bit of geometry)
14:15.50starseekerdloman: I'm guessing byte arrays of the bu_external variety are well suited to your needs?
14:16.22dlomanso long as its got ALL the data for the dbobject, yup!
14:16.43starseekerone of the outstanding issues is why the region_id information is getting stripped by the approach I am taking
14:17.27starseekerI'm using the internal to external and external to internal routines, which is pretty much the same level the dbio layer uses
14:18.12starseekerunfortunately, that means where precisely I'm losing the region_id info is a bit murky
14:19.08dloman``Erik: lynx is pretty neat :)
14:20.52CIA-52BRL-CAD: 03erikgreenwald * r43980 10/geomcore/trunk/src/GS/testclient/gstestclient.c: add start (clientside) timestamp
14:22.00CIA-52BRL-CAD: 03davidloman * r43981 10/geomcore/trunk/prototyping/: Add in a prototyping directory for in process work.
14:33.45dlomanstarseeker: so what did we descide: we are, or are NOT compatable with the Apache license?
14:33.53dlomanApache v2.0 that is.
14:33.57starseekerwe're fine to use it, we just can't mix code
14:34.32starseekerthat's why the big change with the svnTest app
14:34.57starseekerI originally started by taking the svn client code and modifying, but now I'm just using the library APIs
14:35.21dlomankk
14:35.42starseekerwhich would have had to happen eventually anyhow, since the client APIs are too high level for us, but it kills two birds with one stone
14:36.13starseekerif we ever do a geometry specific backend, that'll probably have to be Apache
14:36.14*** join/#brlcad adityag (~ADITYA@182.237.144.88)
14:36.32starseekerbut as with most things, we'll do that if/when need to so it's not an immediate concern
14:36.59CIA-52BRL-CAD: 03erikgreenwald * r43982 10/geomcore/trunk/src/GS/testclient/gstestclient.c: woops, bufp, not buf
14:38.32starseeker``Erik: do you know enough about the db read/write interface to know why rt_db_cvt_to_external5 would strip out region_id?
14:39.43starseekerI thought the functions it called would preserve attributes...
14:42.05starseekerI know why _GLOBAL information isn't there, but the region_id thing I don't get
14:59.10``Erikregion_id isn't an attribute, though.. it's a field, no?
15:03.21``Erikhrm, hm, looks like it's also in the standard attribute set
15:06.30*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
15:06.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:06.49CIA-52BRL-CAD: 03davidloman * r43983 10/geomcore/trunk/ (3 files in 2 dirs): Stub in interface requirements for and FileDataSource implementation of putObj(...), the ability to put a single db object into the datasource
15:07.27``Eriklooks like there's stuff to set the attribute to be the same as the GIFT region_id code in rt_comb_export5
15:07.47``Eriklibrt/comb/comb.c:405
15:14.36dlomand_rossberg: are there samples of how to use your classes to load/save/create .g files anywhere?
15:14.54*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
15:20.21d_rossberghttp://brlcad.org/wiki/CoreInterface_PrintTitle_Example is a simple example of how to load a database and perform a simple operation on it
15:21.07dlomanawesome thanks
15:21.20d_rossberghowever, first you have to decide which kind of database you want:
15:21.41d_rossbergreadonly file, read/write file or in memory
15:21.54dlomanreading thru your code, I think 'memory' is best for what I am working on.
15:22.07d_rossbergthere it depends if you may or have to save you changes
15:22.31dlomanjust looking to to read/write from/to disk quickly
15:24.35d_rossbergto get an in memory database in the above example you have to replace BRLCAD::ConstDatabase by BRLCAD::MemoryDatabase, that's all
15:25.17dlomanand, to verify, i can still dump an in memory dtaabase to file simply by calling save()... correct?
15:25.33d_rossbergcorrect
15:25.41dlomanawesome.  thanks! =D
15:25.54d_rossbergfor creating elements and saving the database see e.g. http://brlcad.org/wiki/CoreInterface_Hallo_World_Example
15:28.13d_rossbergand http://brlcad.org/wiki/CoreInterface_Tree_Walker_Example for walking down the tree and writing the elements names to stdout (as an example)
15:29.27dlomannice.  just read all your wiki pages.  Dunno why i didn't think to check there, lol
15:30.45d_rossbergyou may find the Get(objectName) and Set(object) methods handy too (in Constdatabase.h and Database.h)
15:39.48*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
15:44.56CIA-52BRL-CAD: 03erikgreenwald * r43984 10/geomcore/trunk/src/GS/testclient/gstestclient.c: add more display stuff
15:57.28*** part/#brlcad adityag1 (~ADITYA@182.237.144.88)
15:59.09CIA-52BRL-CAD: 03erikgreenwald * r43985 10/geomcore/trunk/src/GS/testclient/gstestclient.c: indent
16:00.11CIA-52BRL-CAD: 03davidloman * r43986 10/geomcore/trunk/include/ (brlcad/ conf/): Drop unused headers
16:00.30dloman``Erik: got a second to swing by?
16:00.41``Eriksure
16:01.21CIA-52BRL-CAD: 03erikgreenwald * r43987 10/geomcore/trunk/src/GS/ (21 files in 2 dirs): indent
16:05.56*** part/#brlcad sachinjain (~sachin@117.211.88.150)
16:09.06dlomanHrm... too bad d_rossberg logged off.  it looks like his common.h is trying to clobber brlcad's common.h :/
16:12.57dlomannever mind on that, it looks as thought coreInterface's common.h isn't being installed!  Ack!
16:16.39CIA-52BRL-CAD: 03davidloman * r43988 10/rt^3/trunk/ (7 files in 3 dirs): Change core interface's common.h to cicommon.h and add it to cmake's install routine. It is needed for using the coreInterface libraries.
16:17.30dlomanThere.  that's a quick fix.  renamed common.h to cicommon.h and installed it :)
16:18.27dloman``Erik: FYI, im wiring up geomcore to have libge as an external dep.  So soon, you will need to have rt3 compilied and installed for geomcore to compile nad link.
16:18.36dlomani haven't committed that yet, just giving a heads up
16:18.59dloman'compile nad link'  ....lol that paints a funny picture.
16:36.09dlomanstarseeker: you still around?
16:37.39*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
16:38.13CIA-52BRL-CAD: 03erikgreenwald * r43989 10/geomcore/trunk/src/GS/testclient/gstestclient.c: add login
16:42.25*** join/#brlcad Stattrav (~Stattrav@117.192.137.238)
16:42.25*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:45.52CIA-52BRL-CAD: 03erikgreenwald * r43990 10/geomcore/trunk/src/libNet/netMsg/NetMsg.cxx: print msgType as hex
17:06.36*** join/#brlcad siddharth (~siddharth@117.211.88.150)
17:13.52dlomanstarseeker: Had a thought.  You could hack that video into 10 minute segments and put it on youtube.... let them deal with the storage.
17:20.04CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2769 10/wiki/NetMsgTypes: guessing at payloads
17:20.33starseekerfigured to run it by brlcad and see what he thinks of it - probably more tweaking to do
17:20.50starseekernow that the streaming thing appears to work, he can tweak it on his own box too
17:25.59CIA-52BRL-CAD: 03erikgreenwald * r43991 10/geomcore/trunk/src/utility/GSUuid.cxx: Tricky, uuid returns the length including the trailing 0 where std::string does NOT want it. Was causing an extra byte to be written into the packets.
17:29.01dloman``Erik: was that was was causing the lockup?
17:29.21dloman...cause I thought I fixeded that one already... :/
17:29.48brlcadthx starseeker -- I was thinking that there'd probably need to be some more tweaking
17:30.24brlcadi guess sachinjain was having quite a tough time with some basic concepts
17:31.22``Eriknah, but it was causing issues... caused an extra 0 to be written behind the uuid, since the geomclient used the same function, it worked (both sides expected the extra byte) O.o
17:31.49dlomanrighto, but I caught that one with the java junk i was making for the guys upstairs....
17:31.55dlomanguess i didnt commit it :/
17:32.24``Erikhm, *shrug* goes to show that completely seperate implementations are valuable :D
17:32.24brlcadregion_id is stored as an attribute in v5 during comb export, but in memory, it's both an attribute and a field in the comb internal structure
17:33.58brlcaddloman: anyone can add new projects to ohloh, I forget how brl-cad was added but I took ownership and set up the svn repo links
17:34.07brlcadyou do specify checkout points for them to track
17:34.33dlomanyeah, i saw that right after i posted in the channel :)
17:34.56brlcadfor the statistics to work, the specifically mention not listing branches unless they're fully self-contained/separate codes
17:35.18starseekerbrlcad: I'm using rt_db_cvt_to_external5 to export and rt_db_external5_to_internal5 to import, but somehow g_diff is reporting region_id differences
17:35.26brlcadwhich geomcore would qualify, but not rt^3 with all of the other code
17:35.37brlcadstarseeker: why so low?
17:36.19starseekergetting miminal bu_external byte arrays to feed directly into the subversion fs
17:38.08brlcaddb_get_external() should give you the appropriate bu_external()
17:38.34*** join/#brlcad sachinjain (~sachin@117.211.88.150)
17:39.23starseekerdo I still use rt_db_external5_to_internal5 to reassemble?
17:39.40brlcadnot sure what rt_db_external5_to_internal5()'s purpose specifically is
17:39.45brlcadhave to look it up
17:39.49starseekerk
17:39.49brlcadI've used db5_get_raw_internal_ptr() in the past
17:40.09brlcadit'll take that raw bu_external and give you an uncracked internal
17:40.10starseekeractually, looking closer it's only the region_id -1 cases where it didn't preserve it
17:40.39brlcadyou still probably uncovered api inconsistency
17:40.47brlcadwhat'd it do with then?
17:41.08starseekereither didn't preserve them or didn't assign them on import, not sure which
17:41.23starseekerwonder if it's a signed/unsigned assumption somewhere
17:41.25brlcadso just no attribute
17:41.29starseekerright
17:41.59starseekerregion_id WAS preserved on regions that had region flag and non-negative region id, from the looks of it
17:42.51brlcadthere's no definition of valid region_id values, so technically, that's just like it dropping a region id of 1000
17:43.11starseekernods
17:43.36starseekerI can try the db_get_external and db5_get_raw_internal and see if that does the trick...
17:43.50sachinjainhi brlcad
17:44.11starseekeris a little itchy operating at this level of dbio - new turf
17:44.31starseekerplus I've still got to start slogging through how to do and apply diffs...
17:44.36dlomanbrlcad: if I wanted to get the byte equivalent of a memory database out of an rt_i, where would I look?
17:44.59*** join/#brlcad sachi1325 (75d3557b@gateway/web/freenode/ip.117.211.85.123)
17:45.03brlcadstarseeker: looks like your routine calls my routine :)
17:45.14starseekerheh
17:45.16starseekerphooey
17:45.21brlcadplus does some more work
17:45.26starseekerso much for dodging the bullet that way
17:45.37sachinjainbrlcad : do you remember me
17:45.43sachinjainwe had a talk
17:45.44starseekerwhat I am doing seems to work surprisingly well, except for that one case
17:45.48brlcadthe docs on rt_db_external5_to_internal5() sound like it should do what you want
17:45.57brlcadso it's more who's messing up
17:46.07starseekernods - was afraid of that
17:46.12brlcadsachinjain: yes
17:46.15starseekeryech - bug hunt
17:46.39starseekerat least that -1 thing is a clue
17:46.42brlcadisolated and trivial to reproduce... doesn't get much better
17:46.55sachinjainbrlcad : what should I do to get myself considered for that project?
17:47.04starseekermutter... I suppose
17:47.09brlcaddloman: what do you mean by the "byte equivalent"?
17:47.11starseekerstarts setting up the simple test case
17:47.38brlcadsachinjain: we provide a detailed checklist and lots of info on the website
17:48.23dlomanbrlcad: preferably, a byte array of bytes read from disk that constitute the database file
17:48.48brlcadstarseeker: db5_import_attributes() seems to be completely unaware of attribute values so it's got to be during export
17:48.52dlomanim working with Daniel's classes now, and am planning on using them to load a .g in
17:49.14dlomanat that point, i'd like to simply dump the entire DB into a byte array and sling it down the socket.
17:49.56dlomanor could i just read the entire db_i struct from memory?
17:50.00starseekerbrlcad: sounds good - I did a keep with one of the -1 combs and am stepping through now
17:50.13brlcaddloman: there are lots of routines related to this (several that starseeker and I are talking about right now) ... it depends
17:50.23brlcaddloman: do you want there to be object awareness?
17:50.31dlomannot at this point no.
17:50.37brlcadas in, "im expecting 10 and I received 10 objects"?
17:50.53brlcadthen it has absolutely nothing to do with the rt_i
17:51.24brlcadthe db_i has a pointer to both a disk pointer and a byte array
17:51.27dlomanwell right now, I am trying to just get an entire file read and sent.  next step is to break the db into objects then send.
17:51.45brlcaddloman: the g_transfer tool does the latter already
17:51.48dlomanand be able to cat it togeher on the other side.
17:51.59brlcadsrc/gtools/g_transfer.c
17:52.06brlcadthat's a sender and a receiver all in one
17:52.13brlcadwith object counting
17:52.13dlomankk
17:52.17dlomandanke
17:53.11brlcadit also works entirely with in-memory databases on the receiving in, which is what you want for service handling
17:53.24brlcadstarseeker: curious, what has a -1 region_id set?
17:53.45dlomanheh, g_transfer looks strikingly similar to  a pkg test file i saw once..... ;)
17:53.51brlcadthat could very well be some signed/unsigned nasty
17:54.29brlcaddloman: yeah, it was based off of it .. tpkg implemented ttcp over libpkg, g_transfer implements the same thing but with .g object awareness
17:54.58*** join/#brlcad Stattrav_ (~Stattrav@117.192.136.134)
17:55.27starseekerbrlcad: ktank.g has a number of assemblies that have that setting
17:55.36brlcadvery preliminary "geometry service" work way back when long before geometry service was being pushed, making sure that in-memory database processing worked
17:55.39starseekerpossibly havoc too, but haven't confirmed  that yet
17:55.40brlcad(it didn't originally)
17:55.47brlcadk
17:56.55starseekerOooo!
17:57.11starseekera keep on the same object also wipes out that region_id setting
17:57.26starseekerso it's not just my low level stuff, it looks like a legit bug
18:00.28brlcadso now, does the in-mem have it set as -1?
18:01.03brlcadlooks like the attribute import/export code is ignorant, just treats them as strings
18:01.18brlcadthat leaves the comb code
18:02.54CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2770 10/wiki/NetMsgTypes: GSPONG is 0x62, not 0x61
18:05.41CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2771 10/wiki/GeometryServiceNetworkProtocol: Message Length does not include magic/length values.
18:06.35CIA-52BRL-CAD: 03erikgreenwald * r43992 10/geomcore/trunk/src/GS/testclient/gstestclient.c: add transmission of remote node name. Fix off by 8 error causing lockup. Formatting cleanup
18:06.46dlomanbrlcad: looking at Daniel's code.  He loads a database by calling rt_dirbuild and getting back a db_i*
18:06.57dlomanand a err,
18:07.14dlomani ment 'and getting back an rt_i*'
18:07.55dlomansince you're the expert, will the db_i* that the rt_i* have be in a condition where I can use it to get the data I need?
18:08.02CIA-52BRL-CAD: 03brlcad * r43993 10/brlcad/trunk/src/librt/comb/comb.c: use atol() instead of atoi() since the fields are long. adjust printing routines to print long too.
18:08.20brlcaddloman: yes
18:08.30brlcadan rt_i contains a db_i
18:08.40dlomansexy, thanks!
18:09.00dlomanbtw, heard you're under the weather.  Hope you feel better soon!
18:09.45brlcadthe db_i is your handle to the database, it uses a plain FILE * or memory buffer or mapped file, depending on how the data is being managed (e.g., an in-memory-only database has no FILE *)
18:09.58brlcadthere are routines for getting the memory buffer or traversing objects on a db_i
18:10.16brlcadit's easy to get both but iterating over objects is actually problably a little easier
18:10.27brlcadyeah, I think ed gave me a cold
18:10.46dlomanwell, if its any form of justice, he's out again today. ;)
18:10.47brlcadat least, I'm comfortable blaming him for it :)
18:10.51dlomanlol
18:10.52dlomannice
18:11.08brlcadI slept for 14 hours last night trying to recover
18:11.25dlomansee, now you've gone and made me insanely jealous
18:11.51brlcadI'll gladly come in and cough all over you so you too can feel this "blessing"
18:11.57dlomanaahahaha.
18:12.14dlomani have 1600% DV c vitamins coursing thru my veins
18:12.26dloman(dont forget i have virus generators, err, kids, at home)
18:13.00brlcadI rarely ever get sick and get tons of exposure to sick kids too
18:13.36brlcadI'm chaulking this one up to weakened immune system from the long travel combined with complete lack of exercise
18:14.30dlomanbrlcad: how familiar are you with Daniel's coreInterface stuff?
18:14.44brlcadi've read through it a few times
18:14.48dlomankk
18:14.57brlcadpretty awesome use of in-mem db's
18:15.17dlomanis an rt_db_internal* the representation of an object?
18:15.45brlcadthat gets a database object in "internal representation" form
18:15.53sachinjainbrlcad : is it necessary to submit a patch?
18:16.09brlcadsachinjain: it's highly recommended, however small and simple
18:16.17brlcadjust to make sure you can actually read and write code
18:17.14brlcadmost orgs have a similar request of applicants, it helps characterize your ability to become familiarized with the source code and communicate a trivial change
18:18.08CIA-52BRL-CAD: 03erikgreenwald * r43994 10/geomcore/trunk/src/GS/testclient/gstestclient.c: more display stuff
18:18.29brlcaddloman: there are two types of internal representation -- an uncracked and a cracked form -- the GS should never have to deal with a cracked form (i.e. where it becomes aware of the radius value on a sphere)
18:19.03dlomannods.
18:19.05brlcadiirc, rt_db_get_internal is going to be the uncracked from, where you have the name and entity type
18:19.49brlcadmajor performance win to not deserialize fully
18:19.55dlomanright no.
18:20.01dlomanerr, right on.
18:20.53dlomanI am trying to use coreInterface as much as possible, fyi.  The Object class has a db_i* pointer, rt_db_internal*, directory* and resource*
18:21.02*** part/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
18:21.28brlcadsounds like the appropriate minimum
18:21.50dlomanfrom what little I know (via crash course over the last 24 hours) I think i have to grab the 'serialized' data out of the rt_db_internal.... correct?
18:22.46brlcaddb_i is a pointer to the object's container, rt_db_internal is a pointer to the object's data, directory is a pointer to a tree-prep'd record from the db_i, and resource is "magic" that makes it all work faster on multiprocessor systems
18:23.16CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2772 10/wiki/NewSessionReqMsg: New page: Two (GS style network order uint32_t followed by ascii, no terminating 0) strings First is username Second is password (in plain text)
18:23.29dloman"Object's Container" ... as in the database file?
18:23.36brlcadthe rt_db_internal IS the object in a half-serialized, half-deserialized form .. for schlepping it over the wire, you want to convert from internal to external form
18:23.41starseekerok, rt_db_get_intern returns an intern that DOES have a populated idb_avs structure...
18:23.49brlcaddloman: it's not necessarily a file, but yes
18:23.56brlcadit's just "the database"
18:24.09dlomandoh.  I used the word file. ;)
18:24.40starseekerand correctly populated
18:25.18CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2773 10/wiki/Common_NetMsg_Exchanges: list initial connect pattern
18:25.35dlomanbrlcad: the internal->external conversion somewhere in raytrace.h ?
18:26.08``Erikrt_*_export5
18:26.45brlcaddloman: of course :)
18:26.53brlcaddloman: see send_to_server() in g_transfer.c
18:27.03brlcaddoes exactly what you should be needing
18:27.28siddharthhello
18:27.37``Erikah, db_get_external
18:27.50siddharthfor the patch thing,what should we do exactly?
18:27.54siddharthany ideas?
18:28.04brlcadyou can go lower-level and use the export routines, but db_get_external() is a lot simpler, just taking a directory pointer
18:28.18brlcadsiddharth: it's entirely up to you
18:28.30brlcadthe more impressive your patch, the more impressive your submission
18:28.39dloman``Erik: thanks for all the wiki-fu.  My heads spinning :/
18:28.46brlcadsomething simple to show that you can read/write code is a minimum basic, siddharth
18:28.57siddharthok thanks :)
18:29.06brlcadsiddharth: you can start with just about anything in our BUGS file or TODO file or something in one of our trackers
18:29.12``Erikcomplete circles? will there be split pea soup vomit, I skipped lunch :/
18:29.38brlcadstarseeker: jeez, I'm not seeing anything reading code on my end
18:29.41dlomanokay, see... there's the 'line'... and you just crossed it.
18:29.49brlcadhopefully you have better luck with the debugger
18:30.56siddharthOk..one more question,what can we do in BUGS file?
18:31.35brlcadsiddharth: next you're going to ask me where and how to fix the bug?
18:31.38brlcadis this 20 questions? :)
18:31.48siddharthlol :P
18:31.57brlcadyou can do any of them...
18:32.33*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
18:32.34brlcadsome are hard, some are easy -- you have to figure that out
18:32.35siddharthok ill try them out :)
18:32.40starseekerbrlcad: yeah, this is an annoying bugger
18:33.10brlcadsiddharth: if you need more specific hand-holding, there are some code projects listed at http://brlcad.org/wiki/Quickies
18:33.39siddharththanks
18:33.47brlcadsome of those, however, are harder than the BUGS and TODO items
18:34.33starseekerbrlcad: ah HAH
18:34.48starseekerthe internal representation is being altered by rt_comb_export5
18:35.09starseekerthat's where the ip->idb_avs.count changes from 1 to 0
18:39.03dlomanHrm, hitting a C++ knowledge wall.  The only way to know what type class you are dealing with is to attempt a dynamic_cast<> and then check the result for NULL ?
18:39.08dloman...anyone?
18:39.29starseekerbrlcad: I think I've got it
18:39.43starseekernot sure what to do about it though
18:40.14starseekercomb.c:358 - encodes "other stuff" as attributes
18:40.37starseekerthe region_id of the comb itself (internally) is out of sync with the region_id string attribute
18:41.38starseekerline 405 checks for a non-zero comb->region_id
18:42.05starseekerit doesn't find it (because it's checking the comb's data structure, not the string attribute)
18:42.36starseekerso it runs bu_avs_remove on the avsp and strips region_id
18:44.14starseekerin effect, this aspect of the comb export makes it impossible to have separate values in the comb data structure and the associated attribute
18:44.45starseekerdloman: uh, not sure
18:45.07``Erikfor c++, you can enable rtti and do 'isInstanceOf()' or something
18:45.32``Erikbut there's overhead to enabling rtti
18:45.35dlomanjust looked it up.  FYI dynamic cast will return a NULL if a type cast fails and you're dealing with pointers, but throws an Exception if you're dealing with references.
18:45.45starseekerdoes typeid help any?
18:46.27starseekerhttp://en.wikipedia.org/wiki/Typeid
18:56.06CIA-52BRL-CAD: 03erikgreenwald * r43995 10/geomcore/trunk/src/GS/testclient/gstestclient.c: hoist time function
19:05.40*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
19:06.45*** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
19:07.33brlcadstarseeker: it's saying you have to create a profile before I can add you (on socghop.appspot.com)
19:07.58starseekerk, one sec
19:08.50brlcadsame thing for ed's account
19:09.03brlcaddloman: did you create a link_id yet?
19:09.09dlomanneat.  coreInterface just bombed me out: http://pastebin.mozilla.org/1193575
19:09.17dloman....can't say that I have.
19:09.31dlomansocghop.appspot.com?
19:10.02dlomanI've registered that site and applied to be a brlcad mentor.
19:10.07dloman...is that a link_id ?
19:10.46dlomanman, what a terrible day.
19:11.02dlomanim missing blantantly obivous things
19:11.09dlomanbrlcad: yes, i have a link_id
19:11.14dlomando you want it?
19:11.14starseekerbrlcad: uh... where do I create a profile?
19:11.16brlcaddloman: when did you submit the request?
19:11.21starseekerthis new site is less than helpful
19:11.34dlomanhttp://socghop.appspot.com/gsoc/profile/google/gsoc2011
19:11.37brlcadif you sent it before the site change, then you'll have to resubmit it
19:11.49dlomanbrlcad: this morning, if it didn't mess up on me.
19:11.56brlcadregardless you'll need to resubmit it because you're not in the pending requests queue :)
19:11.59dlomanbrlcad: am i not showing up?
19:12.05dlomanokie, will do.
19:12.11brlcaddaniel's came through
19:12.21starseekerdloman: that site isn't accessible because I don't have a profile
19:12.38starseekerOh, I see it
19:12.45starseekergrowl
19:12.50brlcadlikes the new look
19:12.56brlcadwork in progress, but it's better
19:13.10dlomani like the look also, the navigation needs a bit of work
19:13.12brlcadjust not quite ready for production
19:13.18dlomanbrlcad: submitted
19:13.36brlcadgot it and approved
19:13.47dlomansmashing old chap!
19:15.37brlcadnote that anything that redirects to www.google-melange.com may be blocked ... but socghop.appspot.com works, just edit the url manually
19:15.58brlcadsomeone needs to send a request in to get it unblocked
19:17.04``Erikbeat, I broke it :D
19:17.07``Erikneat, even
19:17.15brlcadyeah I see that
19:17.33brlcadI can withdraw it, but not approve
19:17.41brlcadlooks like admins are auto-mentors this year
19:17.41``Erikwhen I click anything either 'accept' or 'reject', I get "You cannot be a mentor for BRL-CAD to access this page."
19:18.12brlcadheh, it let me withdraw the request
19:18.12starseekerbrlcad: sent
19:19.22brlcadjust need to get ed, larry, tom, and curly registered
19:20.00dlomanMoe?
19:20.08brlcadthat'd be ed
19:20.15dloman*snicker*
19:20.29brlcadalthough he does a great curly
19:21.50starseekerbrlcad: what do you think about comb and attributes?
19:21.57brlcadwas just looking at that
19:24.02*** join/#brlcad sachinjain (~sachin@117.211.88.150)
19:35.35bhinesleyFYI, ACM student membership is dirt cheap, and it comes with a MSDN Academic Alliance account, which provides Visual Studio 2005 Professional (and many others) for free.
19:42.01brlcaddloman: FileDataSource::getObj() .. when is the iterator incremented?
19:42.41brlcadduring Good()??
19:42.48dlomannice catch, thanks :)
19:43.01brlcadsame in FileDataSource::getObjs()
19:43.31dlomangetObj() is only supposed to get ONE object, so no inrementing needed.
19:43.44dlomanthis is still just a 'proof' that I can actually do this :)
19:43.50dlomancleanup to follow
19:43.56*** part/#brlcad sachinjain (~sachin@117.211.88.150)
19:44.25brlcadshould toss-in FIXME's though when the code doesn't do what the function suggests, so it's not lost down the road
19:44.36dlomanright on
19:44.37brlcadand ends up being a multi hour/day debugging
19:45.21dlomanHrm, even with the iterator incrementor, it still bombs.
19:45.48brlcadit's bombing an uninitialized vls .. which could be lots of things
19:46.09dlomanrighto.  I'll check it out tomarrow.... I'm fried :(
19:46.11CIA-52BRL-CAD: 03davidloman * r43996 10/geomcore/trunk/CMake/FindBRLCAD.cmake: Make FindBRLCAD.cmake find libge. Likely not the best spot for this lib, since its in the rt3 module, but it works for now.
19:46.13CIA-52BRL-CAD: 03davidloman * r43997 10/geomcore/trunk/ (8 files in 2 dirs): Wire in libge (aka coreInterface) classes for loading and saving .g databases. Implement bare bones read/write for .g files in the FileDataSource class.
19:46.35CIA-52BRL-CAD: 03davidloman * r43998 10/geomcore/trunk/tests/GS/ (CMakeLists.txt FileDataSourceTest.cxx):
19:46.35CIA-52BRL-CAD: Implement basic test for FileDataSource class. A database with a primitive at
19:46.35CIA-52BRL-CAD: top works fine, however a combination at top with a primitive as a child causes
19:46.36CIA-52BRL-CAD: a bomb: http://pastebin.mozilla.org/1193575 Will investigate asap.
19:46.36dlomanwell that took a while.
19:52.42``Erikthis is requiring rt^3 now?
19:53.29dlomanya, just put that in
19:53.40dlomanrt3 should compile and install with no problem.
20:03.19``Erikheh, libge doesn't seem to be linking libbu :/
20:08.45CIA-52BRL-CAD: 03erikgreenwald * r43999 10/rt^3/trunk/src/ (coreInterface/CMakeLists.txt libge/CMakeLists.txt): add BRL-CAD link libraries
20:25.58CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2774 10/wiki/GSNet_String: mention lack of terminating NULL
20:26.34CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2775 10/wiki/Category:Geometry_Service: New page: Pages related to the GeometryService
20:28.36CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2776 10/wiki/NetMsgTypes: fix link
20:29.24kunigamihi, how do I add a regression test? I want to implement one for a function of a library. Should I provide a code with main function calling this function and perform some assertions?
20:31.58``Erik<PROTECTED>
20:33.19kunigamiok! thanks!
20:33.35brlcadkunigami: if it's only testing the interface, then it's just a unit test and can be added as a noinst binary in any directory (e.g. the examples erik mentioned)
20:34.01brlcadif it's going to compare an interface with known good input that might change down the road, then it can be added as a regression test in the regress/ directory
20:34.24brlcadmost of those are shell scripts that perform integration testing and/or regression testing
20:36.05CIA-52BRL-CAD: 03erikgreenwald * r44000 10/rt^3/trunk/src/ (coreInterface/CMakeLists.txt libge/CMakeLists.txt): woops, old cache, update to new variable names
20:44.02kunigamithe function I'm referring to is 'bu_basename', which I think lies on "testing interface" case. What do you mean by 'noinst' binary?
20:44.36starseekera noinst binary refers to a binary that has build logic to create it but not install it
20:44.44starseekere.g. a "make install" won't do anything with it
20:45.03starseekercheck the Makefile.am in src/libbn for bntester, for example
20:45.40kunigamihmm perfect! thank you
21:02.22kunigamiok, so I also have to modify Makefile.am template. I need to add a rule to compile my tester program and declare it to be noinst_PROGRAM. one more doubt: what means FAST_OBJECTS on the Makefile at src/libbu?
21:02.40kunigami*Makefile.am
22:51.51*** join/#brlcad Ralith (~ralith@d142-058-175-056.wireless.sfu.ca)
IRC log for #brlcad on 20110329

IRC log for #brlcad on 20110329

00:51.01starseekerhuh - asymptote has the ability to plot a NURBS surface, apparently:  http://asymptote.sourceforge.net/gallery/
01:10.22*** join/#brlcad crazy_imp (~mj@a89-182-15-178.net-htp.de)
01:40.23brlcadkunigami: you don't really need to worry about FAST_OBJECTS -- you can either list there or not, inconsequential
01:44.45*** join/#brlcad sachinjain (~sachin@117.211.88.150)
01:56.59brlcadhow goes the application sachinjain
02:08.18sachinjainI just woke up
02:08.34sachinjainI have started to get familiar with the application
02:08.58sachinjaineven the installation tool so much of my time
03:14.29*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
03:14.29*** join/#brlcad kanzure (~kanzure@131.252.130.248)
03:18.16*** join/#brlcad bhinesley (~bhinesley@adsl-99-125-83-101.dsl.bkfd14.sbcglobal.net)
03:18.21*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
03:18.49*** join/#brlcad crazy_imp (~mj@a89-182-15-178.net-htp.de)
03:18.49*** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
03:18.49*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
03:18.49*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
03:18.49*** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ)
03:19.14*** join/#brlcad sachinjain (~sachin@117.211.88.150)
03:19.15*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
03:19.15*** join/#brlcad kanzure_ (~kanzure@bioinformatics.org)
03:19.15*** join/#brlcad vtts (~vytautas@diz.ktu.lt)
03:19.16*** join/#brlcad hyarion_ (c05ben@peppar.cs.umu.se)
03:19.16*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
03:19.16*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
03:19.35*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
03:19.35*** join/#brlcad siddharth (~siddharth@117.211.88.150)
03:20.04*** join/#brlcad PrezKennedy (MK@whitecalf.net)
03:20.35*** join/#brlcad yiyus (1242712427@je.je.je)
03:56.17*** join/#brlcad sachinjain (~sachin@117.211.88.150)
04:18.55*** part/#brlcad sachinjain (~sachin@117.211.88.150)
04:37.27*** join/#brlcad sachinjain (~sachin@117.211.88.150)
04:57.40*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
05:00.36*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
05:30.57CIA-52BRL-CAD: 03davidloman * r44001 10/geomcore/trunk/src/GS/FileDataSource.cxx: Remove the simplistic (likely poor) read/write locks in FileDataSource for now.
05:44.18*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
05:47.52*** part/#brlcad siddharth (~siddharth@117.211.88.150)
05:56.23dlomanAnyone still around?
05:57.21bhinesleyprobably not who you're looking for, but I am :)
05:57.59dlomanWell now, you're correct, but nice to meet ya :)
05:58.33bhinesleyyou too
05:59.30dlomanso, hang out here much?
05:59.39bhinesleypretty much constantly
06:00.13dlomanquiet then?  I don't see you chatting much.
06:00.45bhinesleyI try not to interfere unless I have an important question, or significant contribution to the conversation.
06:01.34bhinesleyI'm working on understanding the source, patches, and my GSoC proposal.
06:01.53dlomanhow long you been involved with brlcad?
06:02.17bhinesleyjust a week or two
06:03.30bhinesleyprobably closer to a week
06:03.32bhinesleyhow about you?
06:04.06dlomanoh wow.... um.  close to 3 years now, i think?
06:04.11dlomani lost track a long time ago
06:04.14dlomanheh
06:04.52bhinesleythat's cool. where are you?
06:05.00bhinesley(geographically)
06:05.20dloman'south central' PA, usa.  joo?
06:05.34bhinesleyCalifornia
06:06.24dlomanbrlcad: I've narrowed that vls bad magic down to a bu_vls_free() call on lin 757 of Combination.cpp (coreInterface)
06:06.57dlomanbrlcad: I just don't know where to go from here (at this point), although Im gonna keep picking away at it.
06:07.07dlomanbhinesley: first year at GSoC?
06:07.46bhinesleyyeah
06:08.33*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:08.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:09.23dlomanwell enjoy it, its a blast.
06:09.56dlomanwe got a good crew here, so i hope you stick around
06:10.08dlomanwhat caught your interest in brlcad anyways?
06:10.16bhinesleyI plan to, and I hope I can help.
06:11.16bhinesleyI have a fair amount of experience modeling 3D in AutoCAD, which I really loved doing. I like coding even more.
06:12.07bhinesleyputting the two together sounds like a lot of fun
06:12.44dlomancould be :)
06:14.08dlomanwhere oh where is d_rossberg when ya need him!  :)
06:32.46*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:34.27dlomanhullo d_rossberg !
06:34.52dlomanif you got a few moment's, I'd like to chat a bit.
06:35.02d_rossbergdloman: ? it's half past two!
06:35.23d_rossbergabout common.h?
06:35.36dlomanactually its a bu_vls failure
06:36.20d_rossbergok, where is the problem?
06:37.36dlomanCombination.cpp:757 is seemingly causing a 'ERROR: bad pointer 0x1454eb10: s/b bu_vls(x89333bbb), was Zero_Magic_Number(x0)' failure
06:38.30dlomangeomcore/trunk/tests/GS/FileDataSourceTest.cxx is the file I was using to perform a simple test
06:38.47dlomanto open a .g, and iterate over the top items
06:38.55dlomanerr, 'top objects'
06:39.01dlomanwith a single object it works just fine
06:39.34dlomanwith two objects in the db, it bombs out with this backtrace: http://pastebin.mozilla.org/1193575
06:40.06dlomanI am admittedly not very familiar with the inner workings of the brlcad libraries.
06:40.14dlomanall the C and Macros really really confuse me.
06:41.24d_rossbergi'm looking at it right now, may take some moments ...
06:41.40dlomanI appriciate it!
06:59.32CIA-52BRL-CAD: 03d_rossberg * r44002 10/rt^3/trunk/src/coreInterface/Combination.cpp: improved test for an only partly generated m_internalp (rt_comb_internal) after a long jump (C exception)
06:59.49d_rossbergthis is not the entire solution, it only solves the error after the long jump
07:00.41d_rossbergi think, that db_dup_subtree fails if the database was removed (or something like this)
07:03.52d_rossbergi'll test it ...
07:11.38*** join/#brlcad sachinjain (~sachin@117.211.88.150)
07:18.12dlomanthanks d_rossberg !
07:18.24dlomani got a bit side tracked from the irc window, my apologies!
07:41.56CIA-52BRL-CAD: 03d_rossberg * r44003 10/rt^3/trunk/src/coreInterface/Combination.cpp: initialize the VLS before first usage (in bu_vls_strcpy here)
07:42.15d_rossbergthis should solve it, sorry ;}
07:47.43dlomanAwesome thanks!
07:48.07dlomanI'm gonna crash get some sleep, but I'll check it out later today.  Thanks d_rossberg!!
07:56.06d_rossbergdloman: something for the notes:
07:57.34d_rossbergyou should delete the object at the end with its Delete() method (not so important for your example, but if you have a real server ...)
08:25.40d_rossbergthe common.hs: i've never installed the basic BRL-CAD's and and the C++ interface's headers into the same directory, i.e. there was always a distinction between common.h and brlcad/common.h
08:42.38d_rossbergsee also the rt^3/include/brlcad/readme.txt file
08:44.37d_rossbergif there is a need to install both into the same directory i need to think over the C++ interface's naming conventions
09:11.19d_rossbergnext: every Object has a static ClassName() and virtual Type() method (see Object.h)
09:12.01d_rossbergthey can be compared by == (guess why ;)
09:12.42d_rossberge.g.: if (obj->Type() == BRLCAD::Combination::ClassName()) then ...
10:23.23dlomand_rossberg: great stuff!  You really did a bang up job on the coreInterface.
10:50.48*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
11:23.35CIA-52BRL-CAD: 03davidloman * r44004 10/geomcore/trunk/src/GS/FileDataSource.cxx: Add iterator incr for proper iterating.
12:07.50CIA-52BRL-CAD: 03davidloman * r44005 10/geomcore/trunk/tests/GS/FileDataSourceTest.cxx: Expand test out to getting a single object and then getting a list of all objects at top.
12:09.24dlomanso... who can pick me up a Mt Dew on the way to work?  ;)
12:09.46dlomanhas the need... the need for caffene!
12:11.19*** join/#brlcad sachinjain (~sachin@117.211.88.150)
12:19.56dlomand_rossberg: still around?
12:21.53d_rossbergyes
12:22.20dlomanokay, so I've moved on to Add() ing objects to a memorydatabase.
12:22.27d_rossbergand probable the next 3 hours
12:22.30dlomanand, as usual, i broke things, lol
12:23.00dlomanmade an Arb8 using two vector3d objects, but failed to give the arb8 a name.
12:23.18dlomanand attempting to add that is causing a segfault.
12:24.16dlomanI can see why at Database.cpp:229
12:24.19d_rossbergthe name is a property of the Object
12:24.36d_rossbergsee http://brlcad.org/wiki/CoreInterface_Hallo_World_Example for example
12:24.38dlomanwhere the call to object.Name() is returning a null char*
12:24.56dlomanokie.  Is this expected behavior then?
12:26.06dlomanbtw, great wiki entries.  They'ev been most helpful.
12:27.10dlomanI am wondering, in the event that someone like me attempts to .Add() an Object before setting its name, should there be a check or default name?
12:27.28d_rossbergthat Name() returns 0 is OK, but i should probable test for a valid name before calling wdb_export
12:32.10CIA-52BRL-CAD: 03d_rossberg * r44006 10/rt^3/trunk/src/coreInterface/Database.cpp: test for the presence of a name before trying to add a new object to the database
12:49.28d_rossbergdloman: every Object has a virtual Valid() method to test if it's ok
12:51.21dlomanalirghty, good to know
12:51.28dlomanhehe, more questions:
12:53.27dlomanit seems that if I try to add two Arb8's in a row, the second one clobbers the first.
12:54.03CIA-52BRL-CAD: 03d_rossberg * r44007 10/rt^3/trunk/src/coreInterface/Database.cpp:
12:54.03CIA-52BRL-CAD: corrected the test for a non empty object name
12:54.03CIA-52BRL-CAD: not using object.Valid() here because it should be possible to add "broken" objects e.g. during copying a broken database
12:54.30d_rossbergit looks like you add the arb8s always to an empty database
12:54.59dlomanso should I add, save, add ?
12:56.14d_rossbergBRLCAD::MemoryDatabase md; creates an empty database
12:56.47dlomanlol, duh.  Okay.  Thanks, i see my mistake.
12:57.35d_rossbergif you want to save the database after every operation you should consider using FileDatabase instead
12:58.05dlomanRighto, I have seen my mistake.  Error with the wetware :)
13:03.09CIA-52BRL-CAD: 03davidloman * r44008 10/rt^3/trunk/ (3 files in 2 dirs): Make the GeometryEngine header file installable since this will serve as an excellent search point for FindLibGE.cmake
13:17.52CIA-52BRL-CAD: 03davidloman * r44009 10/geomcore/trunk/ (CMake/FindBRLCAD.cmake CMake/FindLIBGE.cmake CMakeLists.txt): Give libGE its own cmake FIND file. Un-hack the ge find routines out of FindBRLCAD.cmake
13:17.55dlomanthere we go ``Erik give it a shot now.  Unless you installed rt3 in some silly place, it should be found.  Also, you will need to update rt3 as i changed it a bit so it will install GeometryEngine.h
13:20.00dlomanoh dayum: http://www.cnn.com/2011/WORLD/asiapcf/03/29/japan.nuclear.reactors/index.html
13:20.22dloman100 R water in a tunnel.  Oh yeah, that's a core containment breach....
13:27.49kunigamihi, I've updated my patch to basename. Comments are welcome. thanks.
13:40.51CIA-52BRL-CAD: 03erikgreenwald * r44010 10/geomcore/trunk/CMake/FindLIBGE.cmake: allow libge directory to be fed explicitely
13:41.05dlomandidnt work eh?
13:42.52``Eriknot quite yet
13:43.25CIA-52BRL-CAD: 03erikgreenwald * r44011 10/geomcore/trunk/src/GS/CMakeLists.txt: add LIBGE_INCLUDE_DIRS
13:49.35CIA-52BRL-CAD: 03erikgreenwald * r44012 10/geomcore/trunk/CMake/FindLIBGE.cmake: we already refer to brlcad/header.h, so do not include the brlcad/ in the search path
13:53.54CIA-52BRL-CAD: 03erikgreenwald * r44013 10/geomcore/trunk/ (CMake/FindLIBGE.cmake src/GS/CMakeLists.txt): adjust include dir name to be consistent
13:56.26CIA-52BRL-CAD: 03erikgreenwald * r44014 10/geomcore/trunk/src/GS/CMakeLists.txt: link libraries from Find* variables
13:56.43``Erikthere we go
13:56.58CIA-52BRL-CAD: 03erikgreenwald * r44015 10/geomcore/trunk/tests/GS/CMakeLists.txt: add new libge stuff
13:59.10CIA-52BRL-CAD: 03erikgreenwald * r44016 10/geomcore/trunk/src/libNet/netMsg/GenericEightBytesMsg.cxx: fix type warning
14:01.14*** join/#brlcad sachinjain (~sachin@117.211.88.150)
14:28.31CIA-52BRL-CAD: 03starseeker * r44017 10/geomcore/trunk/tests/svntest/main.c: Start figuring out repo level commits, as opposed to doing it manually - not working yet
14:29.20*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
14:29.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:39.33brlcadfirst couple applications are in!
14:39.45brlcadthinks this cold nonesense needs to stop
14:40.59*** join/#brlcad Jesselnz (~jesse@ool-435573a5.dyn.optonline.net)
14:41.10*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011 Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011
14:41.23brlcadhello Jesselnz
14:41.28JesselnzHi
14:42.54JesselnzA summer of code application involves doing a small task and sending in a patch, correct?
14:42.56brlcadstarseeker: so a refresher from yesterday now that my head has cleared up a little bit and the tiny little hammers have taken a lunch break
14:43.12JesselnzDo you have any suggestions for a task to get started with?
14:43.12brlcadJesselnz: not *strictly* required, but highly highly recommended
14:43.29JesselnzAlright
14:43.32brlcadyou should get your proposal in first and say you're working on a patch at a minimum
14:44.06brlcadotherwise, I'd suggest just picking something tangible from our BUGS list or TODO file
14:44.29JesselnzOkay
14:45.12JesselnzI'm still trying to familiarize myself with the codebase for my proposal.
14:45.16brlcadsure
14:45.25CIA-52BRL-CAD: 03brlcad * r44018 10/brlcad/trunk/TODO: there is a pending patch from Guilherme Kunigami (kunigami-dev) that should fix this issue, so remove the todo on bu_basename()
14:45.27brlcadif you find some that sound easy and want confirmation, just speak up
14:45.54JesselnzI was planning to work on the conversion library, but I noticed it involves C++ (which I have no experience with)
14:46.29brlcadthe patch shouldn't take more than a couple hours -- we just want to make sure you can actually code, at it gives you the opportunity to shine above other applicants if everything else is equal
14:46.42brlcadJesselnz: what languages do you have experience with?
14:47.02brlcadit doesn't have to involve C++, it could be pure C
14:47.09JesselnzAside from scripting languages (Javascript, Per, Tcl), only C
14:47.16Jesselnz* Perl
14:47.30*** join/#brlcad willdye (~willdye@fern.dsndata.com)
14:47.42brlcadat least one of our converters has an implementation in C++, so that's why C++ is also listed, not because the library has to be in C or C++
14:47.50brlcada good design can arise from either
14:47.54JesselnzAlright
14:49.59brlcadso are you really from new zealand? :)
14:50.25JesselnzMe?
14:50.34brlcadyou
14:50.44JesselnzNo, I'm from New Jersey
14:50.52brlcadaha, k
14:51.23*** join/#brlcad Elrohir (~kvirc@p5B14B1EA.dip.t-dialin.net)
14:52.06brlcadJesselnz: how strong is your math?
14:52.34JesselnzWell, first-year university level
14:52.36JesselnzI'm a math major
14:52.38brlcadand do you have any computational geometry or computer graphics background?
14:52.47brlcadokay, cool
14:53.14JesselnzNot really, but I've researched the basics
14:54.06brlcadinstead of the geometry conversion library, you might want to consider proposing the image conversion library
14:54.28brlcador the de-tcl project
14:54.43JesselnzI'll look into those
14:54.50brlcadboth don't involve any c++
14:55.30brlcadwhat brought your interest to brl-cad?
14:55.50JesselnzI just find CAD interesting
14:56.00JesselnzSince I'm going into engineering, and I enjoy math
14:56.40brlcadhow'd you come to learn Tcl as a first-year?
14:56.55brlcadcovered in some first semester scripting class or something?
14:57.30JesselnzI haven't taken any programming classes - just projects I've done on the side
14:57.41brlcadinteresting
14:58.30JesselnzI tried to write a 2d CAD program in high school using Tcl's C library
14:58.47brlcadthen I'd definitely like to see some code or even work through some code with you, just to see exactly where you're at -- all skill levels are welcome if you have the passion, but need to make sure the project is scoped accordingly
14:59.55JesselnzFrom the project I just mentioned?
15:00.01brlcadhah, then removing Tcl C api calls from our core library would essentially be the opposite :)
15:00.25brlcadno, I mean in terms of developing a patch to go with your proposal
15:00.38brlcadand scoping your proposal appropriately
15:00.38JesselnzAlright
15:01.18JesselnzYeah, after looking through what exists of the gometry conversion library, it's a bit more algorithm-intensive than I was expecting
15:03.16brlcadand huge, that project entails wrangling up over 250k lines of code into an API
15:03.33brlcadthe image processing library is less than half that
15:18.01CIA-52BRL-CAD: 03davidloman * r44019 10/geomcore/trunk/ (4 files in 3 dirs): Implement FileDataSource's putObj() function.
15:31.00CIA-52BRL-CAD: 03davidloman * r44020 10/geomcore/trunk/tests/GS/ (CMakeLists.txt SimpleCoreInterfaceTest.cxx): Implement a simple core interface test.
15:36.39*** join/#brlcad |Elrohir| (~kvirc@p5B14B378.dip.t-dialin.net)
16:08.50*** join/#brlcad sachinjain (~sachin@117.211.88.150)
16:37.33CIA-52BRL-CAD: 03davidloman * r44021 10/geomcore/trunk/ (3 files in 3 dirs): GeometryChunk needs to be aware of its path. Added a path field, modified associated test.
16:42.54dlomanbrlcad:  i get a byte[] from a socket... whats the quickest way to turn it into a brlcad struct that i can write to disk as a .g ?
16:45.31dlomani just noticed that starseeker isn't around today.
16:51.16CIA-52BRL-CAD: 03r_weiss * r44022 10/brlcad/trunk/src/conv/dem-g.c: Fixed two bugs in the dem-g converter which were introduced in recent edits. One was a correction to the parameters for 'bu_calloc/bu_malloc' and the other was several duplicate 'bu_free'.
16:56.54starseekerbrlcad: I took a look at the red problems on OSX 10.6.7 - it's a bit scary
16:57.12starseekerit's not anything I can pin down - the gedp pointer itself seems to have corrupt information
16:57.40starseekerat least according to gdb, but if it were going to wipe out I would have expected it to do so sooner than what I saw
16:57.57starseekerdo you have a 10.6 mac by any chance?
17:02.06starseekerdloman: I'm around, just getting yanked here, there and everywhere
17:12.45brlcaddloman: you've really not spent any time reading g_transfer.c have you?  once again, the answer to your question is in there, server_geom()
17:13.52brlcadthere are a few ways you can turn (presumably bu_exported bytes) back into an object
17:14.04dlomani'm very tired, i got no sleep last night and am having trouble concentraiting.  thanks for the reminder where it was.
17:14.25brlcadsure :)
17:14.58brlcadtransfer uses a low-level method, cliff's test program used a slightly higher level function call that should work too
17:15.31brlcadstarseeker: I do, although I've not updated to .7 yet
17:15.50brlcadany specific reproduction steps to try?
17:22.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:27.29CIA-52BRL-CAD: 03brlcad * r44023 10/brlcad/trunk/ (doc/deprecation.txt include/raytrace.h): formally deprecate the GIFT field elements on rt_comb_internal objects: region_id, aircode, GIFTmater, and los. they are now stored as attributes.
17:31.58*** join/#brlcad Stattrav_ (~Stattrav@117.192.136.132)
17:38.52brlcadstarseeker: what steps were you using to debug the keep issue?
17:40.00*** join/#brlcad Stattrav (~Stattrav@117.192.150.102)
17:40.00*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:43.38brlcadman, the comb5 export function is messed up
17:43.58brlcadforcibly deconsts, clobbers data
17:44.04brlcadhate to fix this before a release
17:44.41brlcadstarseeker: all of that logic in comb.c doesn't even belong there
18:04.38*** join/#brlcad Stattrav (~Stattrav@117.192.139.178)
18:04.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:09.29starseekerbrlcad: for red, just try to edit a combination - hard crashes mged
18:09.47starseekerfor keep - tried a keep of computer in ktank.g
18:10.17starseekerwas watching the status of the avs list
18:10.38brlcadokay
18:11.17brlcadI'm getting a handle on the import/export problem
18:11.25starseekerawesome
18:11.41CIA-52BRL-CAD: 03brlcad * r44024 10/brlcad/trunk/TODO: two issues to resolve now
18:11.41starseekersorry we kept pestering you yesterday when you felt like crap :-/
18:11.53brlcadcomb export sucks, but that's old code so I don't want to edit any more than I have to this release
18:12.02starseekernods
18:12.15starseekerit's not any more broken than it ever was
18:12.27starseekeronly shows up when region_id and the comb struct aren't in sync
18:12.28brlcadno way to verify that :)
18:12.35brlcadwell, there is a way, but would take too much time
18:12.51brlcadso the question is exactly when/where they get out of sync
18:13.01brlcadbecause that export code is just fine assuming they are in sync
18:13.11brlcadstill sucks, but it's not wrong with that assumption
18:13.25brlcadso the problem is either during import or elsewhere
18:19.01starseekerI suppose in principle you might have some asc2g type thing where you import a comb and then set the region_id to -1 after creating the comb itself
18:20.36starseekeriirc red was capable of doing things like that before I added all that sync logic... and the .g files ktank.g and havoc.g are the product of running asc2g
18:22.09starseekerinteresting - getting a more useful backtrace
18:24.25starseekerhttp://pastebin.mozilla.org/1194067
18:26.15starseekerwooot - it DOES crash on my 10.5 mac
18:26.21starseekerwonder when that happened?
18:26.24starseekerok, phew
18:26.30starseekerstarts binary search
18:36.31brlcadwhile you're progressing from that direction, i'll see if I can find where the two get out of sync
18:37.40starseekerk - it looks like (surprise) some of the recent regex tweaking for red broke something
18:39.34starseekeryep - r43832
18:41.01brlcadhmmm, interesting
18:43.04brlcadso either freeing something that shouldn't be or not initializing something after free
18:46.40CIA-52BRL-CAD: 03brlcad * r44025 10/brlcad/trunk/src/libged/red.c: revert r43832 since it reportedly is causing red to crash. needs more investigating since this should have been a safe refactoring change.
18:48.09brlcadwaits for builds to recompile so he can debug appropriately
18:51.09CIA-52BRL-CAD: 03starseeker * r44026 10/brlcad/branches/cmake/ (14 files in 10 dirs): MFC r44025
18:51.46brlcadoh shizzle
18:51.51brlcadhow'd that happen
18:52.08brlcadlooks like an == 0 got turned into a != 0 in that commit
18:52.58starseekerah, line 164?
18:53.21brlcadyeah
18:53.50brlcadif that's the culprit, then r44025 should still crash
18:54.00brlcadsince it's still !=
18:54.21starseekerit's not - at least not in my build here - 44025 works
18:54.30starseeker(well, 44026 in cmake0
18:54.36brlcadhuh
18:55.09brlcadper the logic, == 0 should be right == if regex is successful
18:55.29brlcadi think :)
18:55.43starseekerit may not handle a matrix right, but it doesn't crash and does apply the changes in the simple case
18:56.58starseekerOhhhhh
18:57.21starseekerI think my logic on red.c around line 425 may be screwy
18:57.46starseekeryou have ret=0, and I was counting on -1 or 1
18:58.23brlcadit was ret 0 previously
18:58.26brlcadI see what i did
18:58.36brlcadI swapped the if/else so != become an == case
18:58.47brlcadhttp://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libged/red.c?r1=43830&r2=43832&pathrev=43832
18:58.53starseekeroh, ok
18:59.22brlcadso it's just back to being confusing as to why one works and the other doesn't
18:59.47brlcadfunctionally equivalent ... unless...
19:01.04starseekermatrix_substring is inited inside an if test...
19:01.34starseekerno, that doesn't look like it...
19:04.22brlcadsmelling more like red herring
19:10.03CIA-52BRL-CAD: 03starseeker * r44027 10/brlcad/trunk/src/libged/red.c: Take another stab at the refactor - this seems to work, but needs more testing
19:13.35brlcadhm, I just don't believe that to be the direct cause of any crash
19:13.46brlcadthat's functionally equivalent
19:14.10brlcadinit of the vls earlier was the only change, but that vls isn't accessed outside that one block
19:14.18starseekernods
19:14.27starseekercan you confirm the crash prior to 44025?
19:14.40brlcadhaven't tested
19:14.46starseekerk
19:16.00brlcadoh there's something different
19:16.12brlcadyou made it always return 1 :)
19:16.20brlcadignoring the ret var
19:17.07brlcadnow that I'd believe .. that code elsewhere is at fault for not handling other return values correctly
19:17.13starseekerah whooops
19:18.28CIA-52BRL-CAD: 03brlcad * r44028 10/brlcad/trunk/src/libged/red.c: return the value that was set
19:22.17starseekerurm... still working here
19:23.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:24.35starseekerI take that back - it's not handling an example with a matrix right
19:24.38starseekergrowl...
19:31.32*** join/#brlcad Stattrav (~Stattrav@117.192.133.184)
19:31.32*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:36.10starseekerblast it the full matrix regex isn't matching
19:36.18starseekerI could have sworn I tested all that
19:36.30CIA-52BRL-CAD: 03brlcad * r44029 10/brlcad/trunk/src/librt/db5_io.c: init the external before trying to fill it. random stack memory is evil.
19:36.43CIA-52BRL-CAD: 03brlcad * r44030 10/brlcad/trunk/src/librt/dir.c: save some time, don't init until we need to
19:36.56brlcadstarseeker: maybe also related to the [:blank:] vs [:space:] change
19:37.15brlcadshould be the same for any value that might continue to another line
19:37.27brlcadthis begs for a proper regression
19:37.35brlcadbunch of input red files
19:38.35CIA-52BRL-CAD: 03brlcad * r44031 10/brlcad/trunk/src/librt/db5_io.c: ws
19:39.28CIA-52BRL-CAD: 03brlcad * r44032 10/brlcad/trunk/src/librt/dir.c: ws cleanup
19:40.58starseeker"[[:space:]]+([+-]?[0-9]*[.]?[0-9]+([eE][+-]?[0-9]+)?[[:space:]]+) {15}([+-]?[0-9]*[.]?[0-9]+([eE][+-]?[0-9]+)?)"
19:42.02brlcadfor what it's worth, I get a rather different stack trace from yours
19:42.41brlcadsame all the way up to rt_db_put_internal5(), mine never gets to rt_db_free_internal()
19:43.10brlcadso it's going wrong somewhere before there
19:43.15starseekerhmm
19:45.35starseekerhates regex
19:48.23starseekerit's not blank vs space
19:49.15brlcadwe must gain deeper understanding as to what is failing and why, not just chase symptoms
19:49.39starseekerbrlcad: I know - I'm after why it's not matching the matrix
19:50.01starseekerthat has to be fixed toto
19:50.03starseekerto even
19:50.06brlcadnods
19:50.24starseekerI take it you're still crashing?
19:50.37brlcadi've been in the debugger on the same crash
19:50.44starseekerah
19:50.59brlcadcleaning up code as I review up and down the stack
19:50.59starseekerjeez what a lousy time for this
19:51.09starseekernods
19:58.35CIA-52BRL-CAD: 03brlcad * r44033 10/brlcad/trunk/src/librt/db5_io.c: cleanup rt_db_cvt_to_external5(). make sure we check all inputs and initialize our bu_externals.
20:09.09CIA-52BRL-CAD: 03starseeker * r44034 10/brlcad/trunk/src/libged/red.c: Ooops. one logical if statement error and a stray space in the full_matrix regex string
20:13.28kunigamibrlcad: I'm taking a look at your comments of my patch. How do I enforce that callers of bu_basename release memory? Are there something like smart_pointers in c?
20:14.03brlcadkunigami: no way to enforce, just have to give them a quick sanity check
20:14.14brlcads/way/need/
20:14.36brlcadit's only because it's an api change (and deviation from basename()) that it even needs to occur
20:14.49starseekerbhinesley: did you get a chance to play with the Tcl/Tk code?
20:15.56kunigamihmm, what do you mean by "sanity check"?
20:18.15brlcadkunigami: a grep through the code to find all the callers, make sure the string is released or copied and released
20:19.07brlcadiirc, that routine is not called in more than a couple places -- if it's more than 15 min work, lemme know
20:20.00kunigamiok!
20:20.00kunigamiOne thing: if we're going to change interface, I'd suggest we also change the input to non-const (like basename). I think it would do less harm. Also, it would be compliant with basename (3), which may change the input string.
20:20.49kunigamithen there's no need to allocate memory
20:28.02CIA-52BRL-CAD: 03starseeker * r44035 10/brlcad/branches/cmake/src/ (libged/red.c librt/db5_io.c librt/dir.c): MFC r44034
20:31.30bhinesleystarseeker: Yes, I changed the export->ASCII to a tk_getSaveFile. It stands alone without the bug fix, so I'm submitting it in a few minutes.
20:31.53bhinesleyI have gotten closer to finding the bug, but it is not in Tcl/Tk.
20:32.04starseekerbrlcad: awesome :-)
20:32.14starseekerer bhinesley: awesome :-)
20:32.41starseekernote to self - read then post :-P
20:33.12bhinesleyat least he wasn't talking about a family member dying or something
20:33.48starseekerheh
20:36.36brlcadkunigami: that's a good thought but then there are a couple issues
20:36.41bhinesleypart of the problem, is that Windows 7 moves files into VirtualStore that are exported anywhere but the user profile. To the user, they're just not there.
20:37.13brlcadone being that dirname/basename suck .. they're the way they are because they were implemented that way a LONG time ago and it's painful to change API that old
20:37.17bhinesleythe other problem is incorrect handling of windows paths, which is what I'm still tracking down
20:37.24brlcadthey're not re-entrant or thread-safe, for example
20:38.04starseekerbhinesley: ah yes, Windows paths
20:38.34starseekerbhinesley: how are you building on Windows?
20:38.40brlcadkunigami: the other issue is consistency -- we have to be self-consistent so whatever is done for bu_basename() needs to be done for bu_dirname() too
20:39.37brlcadkunigami: so either both match dirname/basename or both match each other, provide thread safety, but require callers to bu_free()
20:39.49bhinesleystarseeker: I started with Cygwin, but ran into build errors. Anyways, once I read that releases are built in Visual Studio, that's what I started using. I just finished building for the first time, and there are some errors. I have yet to see how bad.
20:40.48kunigamiwow I didn't think of these issues! ok. I'll keep the interface and add a commentary at bu.h and also perform sanity checks. do we have any such automatic checker, where I could add these tests?
20:42.04brlcadkunigami: what sort of tests?
20:42.05starseekerbhinesley: the cmake branch may be a good bet for building on Windows with Visual C++
20:42.35brlcadkunigami: bu_dirname() already takes const, returns nonconst, and documents the need for bu_free() so it would be a good example to follow
20:42.59brlcadthe issue is just making sure bu_basename() callers are calling bu_free() like bu_dirname() callers are
20:43.31bhinesleystarseeker: in the repo?
20:44.32kunigamibrlac: hhm nevermind I don't think such sanity checkings could be automated.
20:44.33bhinesleyI see it now
20:44.47kunigamibrlcad: ok. I'll follow that example
20:45.15starseekerbhinesley: svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/branches/cmake brlcad-cmake
20:46.47*** join/#brlcad siddharth_ (~siddharth@117.211.88.150)
20:47.31siddharth_brlcad, How to apply for gsoc brlcad?
20:48.17brlcadsiddharth_: see http://brlcad.org/wiki/Google_Summer_of_Code/2011
20:49.25starseekerbhinesley: you'll need cmake (2.8.4 is probably a good idea) and Visual C++ (or Visual Studio should work)
20:49.37starseekerIf you want to build the installer you'll also need NSIS
20:50.09CIA-52BRL-CAD: 03erikgreenwald * r44036 10/geomcore/trunk/src/interfaces/cl/ (. gsclient.asd gsclient.lisp): quick and dirty lithp client
20:50.17bhinesleystarseeker: alright, thank you
20:57.20*** join/#brlcad Marjo_ (~Marjo@71.141.133.50)
20:57.46starseeker``Erik: that's pretty cool, actually
21:04.08Marjo_Hello, everyone!
21:05.51brlcadhello Marjo_
21:23.21CIA-52BRL-CAD: 03brlcad * r44037 10/brlcad/trunk/src/librt/comb/comb.c: check in the order passed
21:26.47CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2777 10/wiki/MGED_CMD_who: displayed objects
21:38.25brlcadthere's a gsoc project I forgot to add .. syncronize wiki pages with doxygen pages ;)
21:39.35brlcader, docbook
21:40.04starseekeryeah! that's a really good candidate for those interested in web stuff
21:42.54Marjo_I'm very intersted in the code maintenance project. Filling out a proposal right now.
21:44.04brlcadMarjo_: fantastic, which one?
21:44.30CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2778 10/wiki/Google_Summer_of_Code/Project_Ideas: sync docbook and wiki docs
21:45.06Marjo_brlcad: I'm very interested with Code Reduction / General Tree Walker / Fixing Bugs under Code Refactoring Projects.
21:45.46Marjo_I'm only a 2nd year Computer Engineering Undergrad so I'm still a novice.
21:56.13CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2779 10/wiki/Synchronize_Wiki_with_Docbook: initial wikidocbook idea
21:56.21brlcadMarjo_: then code refactoring sounds like a great place to begin
21:56.30brlcadthat said, you could have 10 years experience and still be a novice ;)
21:57.33brlcadif experience is limited, I wouldn't necessarily recommend starting with code reduction since that usually entails a lot of careful testing and API design
21:57.36*** join/#brlcad adityag (~ADITYA@182.237.144.88)
21:57.45brlcadthe other two ideas, however, bug fixes and tree walking, are more tangible
21:58.11Marjo_brlcad: Haha, agreed. I would love to get a small taste of what real-world programming looks like.
21:59.11CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r2780 10/wiki/Main_Page: there is no support, neat showing dead links in red erik
22:00.36brlcadMarjo_: it's mostly about taking things to completion -- proof-of-concept is never enough
22:01.14brlcaddocs, testing, performance profiling, tweaking, more docs, more testing
22:02.54Marjo_brlcad: To test this code, what kind of IDE would you recommend? Is either Microsoft Visual C++ 2010 or Eclipse on Ubuntu a proper IDE?
22:03.17brlcadwhatever you're comfortable and productive with is fine
22:03.28brlcadit's worth investing the time and effort to learning how to use one of them well, though
22:03.51brlcadpersonally, I prefer emacs, eclipse, or vim (in probably that order)
22:04.49brlcadmost graphical IDEs are just a crutch, and tend to get in the way more than they help -- learn the underlying concepts first and it won't matter
22:07.56brlcadif you end up not understanding build failures or avoiding looking into compilation failures, then you probably shouldn't be using an IDE yet
22:11.16Marjo_How would students address code maintenance if they don't see the errors through an IDE? Throughout the duration of my 2 years we've only been using Eclipse and Visual Studio to write code and debug.
22:19.01brlcadMarjo_: your confusion is exactly what I'm referring to :)
22:19.22brlcadthe IDE isn't a magical black box, it's making calls and performing operations under the hood
22:20.06brlcadas a young developer, it's critical to learn what those things are otherwise "when things go wrong", deciphering what's going wrong can seem impossible
22:20.14brlcador worse, lead to cargo cult programming
22:20.45Marjo_brlcad: OH! I see what you're talking about. Does it basically boil down to white box testing?
22:21.25brlcadyou should be able to write and debug software with a simple text editor, a compiler, and a linker .. next learn a decent debugger and you'll be more experienced than most developers
22:22.12brlcadit's not related to white box testing -- it's knowing how your tools work
22:23.53Marjo_Ahh, my current Data Structures and Algorithms professor touched upon this subject during the beginning of the semester, but she said that is probably too advanced for our class right now.
22:23.54brlcadcar analogy: it's like being a car mechanic but not knowing how to use a wrench, avoiding wrenches or even anything with a bolt on it because you've never used a wrench before
22:24.39Marjo_I wonder why we didn't start out our curriculum by "learning the insides" first...
22:25.09brlcada power wrench might save time and effort, but damn .. it's just a wrench .. don't fear learning how to use a wrench first ;)
22:26.18brlcadMarjo_: that's because the average CS student is stupid (because the average person is stupid) and they try to not scare people away too quickly, ease them into core concepts
22:26.46Marjo_Haha, I fully understand. :)
22:26.48brlcaddecades of people before you learned the basic tools just fine, you'll do just fine too
22:34.24CIA-52BRL-CAD: 03brlcad * r44038 10/brlcad/trunk/include/raytrace.h: (log message trimmed)
22:34.24CIA-52BRL-CAD: yay understanding. document how RT_GET_TREE() and RT_FREE_TREE() are/were
22:34.24CIA-52BRL-CAD: working. it's basically a linked list that reuses free'd tree items so we never
22:34.24CIA-52BRL-CAD: allocate more than the largest amount in use at any one time. pretty nifty.
22:34.24CIA-52BRL-CAD: (allocating in batches might be even better) add a new RT_INIT_TREE macro that
22:34.25CIA-52BRL-CAD: will initialize a union tree to zero with the magic set, make RT_GET_TREE init
22:34.26CIA-52BRL-CAD: every tree returned so callers never have to deal with the magic number
22:35.13CIA-52BRL-CAD: 03brlcad * r44039 10/brlcad/trunk/src/librt/ (comb/db_comb.c db_tree.c tree.c): now that RT_GET_TREE initializes, we don't need to manually set RT_TREE_MAGIC any more. should also help guarantee that reused tree nodes have zero'd memory.
22:37.39Marjo_Wow, thank you for the inspiration. I will still apply for the project so that I can learn of the different ways to program.
22:45.58adityagbrlcad: is it cool if i have not submitted patches in BRL-CAD ? . i have submited a few patches in drupal. will that help ?
22:49.51brlcadMarjo_: great, look forward to seeing your application
22:50.52brlcadagain, you can use whatever you like
22:50.54brlcadwe'll only push you towards specific tools if you're taking too long
22:51.08brlcadthe tool is just a tool, better to obsess over code than over the tools :)
22:51.19brlcadadityag: are you serious? :)
22:53.25brlcad"is it cool if I didn't do the assignment for your class ? . i did the assignment for another class. will that help ?"
22:53.28brlcadyou tell me ;)
22:55.04adityag<PROTECTED>
23:01.20brlcada patch isn't technically "required", so you should submit your application with or without it regardless (you can attach a link to the patch later)
23:01.48brlcadbut trying to pawn off work for another org isn't cool or useful, the point is seeing how you deal with our code
23:04.37CIA-52BRL-CAD: 03brlcad * r44040 10/brlcad/trunk/src/librt/ (4 files in 3 dirs): no longer need to set RT_TREE_MAGIC now that RT_GET_TREE() sets it.
23:05.57CIA-52BRL-CAD: 03brlcad * r44041 10/brlcad/trunk/src/libged/ (8 files): no longer need to set RT_TREE_MAGIC in here too now that RT_GET_TREE() sets the magic.
23:09.22adityagbrlcad: yeah cool.
23:17.00CIA-52BRL-CAD: 03brlcad * r44042 10/brlcad/trunk/src/libged/red.c: functions that use zero for success result in reverse boolean expressions. less error-prone to explicitly test for zero. go a step further and document intent with matched/no match labels.
23:21.10CIA-52BRL-CAD: 03brlcad * r44043 10/brlcad/trunk/src/libged/red.c: aha, source of the errant space. auto-formatting sees the ){ and wants to clean up the formatting. break up the string.
23:57.09starseekerbrlcad: nice.  I didn't realize you could feed two separate strings into the printf logic like that
23:58.01adityagbrlcad: Im interested in these project ideas : Code Reduction, Fix Bugs, Benchmark Performance Database. Can i submit multiple applications ?
IRC log for #brlcad on 20110330

IRC log for #brlcad on 20110330

00:02.52brlcadadityag: you sure can
00:03.08brlcadyou can submit up to 20 apps total to any number of orgs
00:03.22brlcadI don't recommend submitting more than three
00:03.32brlcadfocus on quality, not quantity
00:03.53adityagok cool thanks
00:03.55brlcadbetter to have two really good applications with a strong patch than four crappy applications with a crappy patch ;)
00:05.16brlcadstarseeker: *nod*  all string literals are equivalent to the concatenation of them broken up like that
00:05.48brlcadso you can't use it to get over the 509 char limit in C90, but it is useful if you need to inject comments or assist with layout
00:07.33CIA-52BRL-CAD: 03starseeker * r44044 10/brlcad/trunk/src/libged/red.c: Rename to avoid confusion - the point of that regex is to look for anything except whitespace, not whitespace.
00:13.02starseekerplease please please let this be the last of the showstopper red bugs...
00:15.31brlcadi'm still chasing the logic through for how it was causing that crash in the first place
00:15.59brlcadfor my trace, it was deep in libbn checking if a mat is identity .. so it was bogus memory
00:16.06brlcadhopefully the zero-init will make that not happen
00:16.50starseekernods
00:17.08starseekermaybe that would explain why the different crash on 10.6 vs. 10.5?
00:19.26brlcadsure, it's just random memory
00:19.38brlcadsomething is wrong with the tree structure
00:19.50brlcadi'm guessing that the regex fails to parse a matrix, so it never sets the matrix
00:19.58brlcadthen gets to code that attempts to validate the matrix
00:20.10brlcadand boom
00:20.38brlcadbut you could also get a boom from any of the other fields too, or the tree structure might happen to be a valid previous tree node and you'd get further, etc
00:22.18brlcadso far, though, I don't see how we've actually fixed a bug yet other than you finding the space in the regex
00:25.38starseekerone if the if statements was backwards too
00:25.57starseekerbut yeah, neither of those seem to relate directly to that weird issue
00:28.40brlcadit wasn't though, the return statements was swapped
00:28.47brlcadunless it was wrong before all of this too
00:28.57brlcadhttp://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/libged/red.c?r1=43830&r2=43832&pathrev=43832  flipped them
00:34.18CIA-52BRL-CAD: 03brlcad * r44045 10/brlcad/trunk/src/ (30 files in 12 dirs): consistently call BU_GETUNION() to allocate a new union tree node and RT_INIT_TREE() to initialize that node instead of setting the magic value directly.
00:36.20brlcadokay, now to rebuild and see if that makes any difference whatsoever
00:52.05starseekerbrlcad: oh, I was referring to a different one - I think it was wrong to start with
00:54.46brlcadstarseeker: so recap, you can't change the name during red right?
00:57.57brlcadalso, matrix edits during red are not working in my testing, they get ignored
00:58.34brlcadgood/bad news, though .. can't get it to crash
01:00.49CIA-52BRL-CAD: 03brlcad * r44046 10/brlcad/trunk/TODO: keep seems to be working, red is no longer crashing but isn't editing matrices either
01:01.03brlcadat least, keep tested clean on linux
01:09.08*** join/#brlcad yukonbob (~bch@S0106002129e399fc.ok.shawcable.net)
01:09.18yukonbobhello, #brlcad
01:11.02*** join/#brlcad crazy_imp (~mj@a89-182-208-48.net-htp.de)
01:27.03*** part/#brlcad adityag (~ADITYA@182.237.144.88)
01:57.29brlcadhowdy yukonbob
01:57.54brlcadstarseeker: just noticed that your crash report was on the same tree node member, the matrix
01:58.10brlcadso undoubtedly related to setting it during red
02:09.48*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca)
02:26.28CIA-52BRL-CAD: 03brlcad * r44047 10/brlcad/trunk/src/libbu/stat.c:
02:26.28CIA-52BRL-CAD: treat empty strings the same as null, i.e., a special case similar to NaN
02:26.28CIA-52BRL-CAD: implying not a file so never will match true even if stat() might. similarly,
02:26.28CIA-52BRL-CAD: for comparing to files, empty strings should never match. (two empty string
02:26.29CIA-52BRL-CAD: filenames are not the same file, they are no file).
02:29.38starseekerbrlcad: that's very odd - I was able to edit a matrix earlier today...
02:30.17starseekeryeah, logic for name change isn't present yet
02:30.30CIA-52BRL-CAD: 03brlcad * r44048 10/brlcad/trunk/include/bu.h: document the behavior on empty strings
02:31.25brlcadk
02:31.36CIA-52BRL-CAD: 03brlcad * r44049 10/brlcad/trunk/src/libged/red.c:
02:31.38CIA-52BRL-CAD: another attempt at a logic cleanup, this time consolidating the memory cleanup
02:31.38CIA-52BRL-CAD: and unlinking of the temp file to one place so that the file is consistently
02:31.38CIA-52BRL-CAD: closed. some conditions weren't closing the file. this only modifies ged_red()
02:31.38CIA-52BRL-CAD: and shouldn't be a change to flow logic.
02:34.12starseekerunfortunately, something about the ged string handling results in the error messages from ged_red getting squashed
02:34.27starseekerI recall Bob saying something about why that was once, but I don't recall
02:34.59brlcadall part of the refactoring suck
02:35.10brlcadsome ged functions reset the result string, some don't
02:35.23brlcadso if you have a ged func that calls another ged func, it may or may not reset the result
02:35.30starseekerah
02:35.45brlcadif the clean refactoring was complete, there'd be no need to reset the result in any func
02:36.13brlcadexcept the one top-level wrapper executing the main command
02:36.32brlcadif even then, could be a result array
02:39.29CIA-52BRL-CAD: 03starseeker * r44050 10/brlcad/branches/cmake/ (46 files in 19 dirs): MFC r44049
02:39.42brlcadstarseeker: another curiosity, I edited a region with red and it listed rgb and color as an attribute
02:39.55starseekerboth of them?
02:39.57brlcadlooking at the logic in write_comb(), that shouldn't be possible since it's a standard attribute
02:40.01brlcadyep
02:40.08starseekergrowl...
02:40.34starseekerit might be doing that if a pre-existing region has both... I don't recall
02:41.02brlcadfwiw, it was havoc, rt_r.pyl1
02:41.41brlcadattr show only lists rgb
02:42.25starseekerif it's pulling color from the comb struct and rgb from attributes that MIGHT do it
02:42.29starseekermore likely I screwed up
02:42.55brlcadlooks like write_comb() doesn't look at the struct members
02:43.35starseekerit's probably in the standardization routines then
02:46.15brlcadcurious that you manually list the standard attributes just to get the max length for pretty printing
02:47.38starseekerbrlcad: those routines are certainly candidates for improvement
02:49.22brlcadif I'm reading the correctly, it looks like it may even potentially update a read-only database
02:49.44starseekerwinces
02:50.02brlcadah, it'll try but then get bitched at lower-level by librt
02:50.16brlcadstill.. the in-mem is modified
03:01.40CIA-52BRL-CAD: 03brlcad * r44051 10/brlcad/trunk/TODO: note a few of the red issues remaining
03:04.32CIA-52BRL-CAD: 03brlcad * r44052 10/brlcad/trunk/src/libged/ (ged_private.h put_comb.c): delims is only used in put_comb.c so it doesn't need to be an extern'd global. same for ged_tmpcomb.
03:05.49CIA-52BRL-CAD: 03brlcad * r44053 10/brlcad/trunk/src/libged/red.c:
03:05.49CIA-52BRL-CAD: delims was moved to put_comb, not used here. refactor the Combination Tree
03:05.49CIA-52BRL-CAD: separator so it's only in one place. put the matching regexp up next to it so
03:05.49CIA-52BRL-CAD: changes to one can be reflected in the other, otherwise will be brittle to
03:05.49CIA-52BRL-CAD: future edits.
03:07.12CIA-52BRL-CAD: 03brlcad * r44054 10/brlcad/trunk/src/libged/red.c: if the regex is going to have the newline, make the separator have it too
03:30.12CIA-52BRL-CAD: 03brlcad * r44055 10/brlcad/trunk/src/libged/red.c: ouch. write_comb() needs a rewrite. it's modifying data it should not be modifying at this point in our processing. just asking for trouble.
03:42.08CIA-52BRL-CAD: 03brlcad * r44056 10/brlcad/trunk/NEWS: with r44022, richard fixed two memory management issues introduced during a code audit that reduced the size of an allocation after a conversion from bu_malloc to bu_calloc as well as double-free on exit.
03:47.24CIA-52BRL-CAD: 03brlcad * r44057 10/geomcore/trunk/src/GS/FileDataSource.cxx: if one iterator needs it, don't they both?
04:00.46CIA-52BRL-CAD: 03brlcad * r44058 10/geomcore/trunk/src/GS/ (25 files in 2 dirs): attack of ws indent format consistency. remove useless header metadata.
05:26.37*** join/#brlcad adityag (~ADITYA@182.237.144.88)
05:41.45*** part/#brlcad adityag (~ADITYA@182.237.144.88)
06:16.51*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:18.19*** join/#brlcad siddharth__ (~siddharth@117.211.88.150)
06:33.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:00.27*** join/#brlcad siddharth_ (~siddharth@117.211.88.150)
07:07.53*** join/#brlcad siddharth__ (~siddharth@117.211.88.150)
08:51.39*** join/#brlcad pawleeq (~pavel@pc119.iabrno.cz)
10:21.28*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
10:58.10dlomanMerin all
11:10.05*** join/#brlcad siddharth__ (~siddharth@117.211.88.150)
11:21.04dlomanbrlcad: Is there some 'good coding practice' that I am unaware of coming to play at FileDataSource.cxx:53 ?  Why do we need to incr the iterator if its not going to be used again?
11:28.10*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
11:34.37CIA-52BRL-CAD: 03davidloman * r44059 10/geomcore/trunk/ (include/Portal.h src/libNet/Portal.cxx): Add convenience method for sending a typeonly msg to client.
11:38.14CIA-52BRL-CAD: 03davidloman * r44060 10/geomcore/trunk/ (include/DataManager.h src/GS/DataManager.cxx): Stub in BRLCAD::Object <-> GeometryChunkMsg functions. Simplfy Msg handling by using new Portal::sendTypeOnly() method.
12:23.17brlcaddloman: not really, only if someone came to that block later and turned it into a loop
12:27.43brlcadI presume that function is incomplete in some fashion?
12:27.43CIA-52BRL-CAD: 03brlcad * r44061 10/geomcore/trunk/src/GS/FileDataSource.cxx: not a loop, no need to increment. odd pulling first 'top' object though.
12:27.58*** join/#brlcad Elrohir (~kvirc@p5B14A416.dip.t-dialin.net)
12:33.11dlomanbrlcad: just the way the core interfaces are setup leads to the only real way to arbitrarily get top objects is via an iterator and the only way to get the iterator is to use the TopObjectIterator()
12:33.39dlomanwhen i have the time, i plan on expanding the ConstDatabase/Database/MemoryDatabase functionality.
12:34.40dlomangetObj() assumes you only want 1 object, and that's because in our design, many of the .g files in the repo are going to only have 1 object.
12:37.10dlomanFFA question:  If i want to use memcpy to copy to a char*, but start at the 5th char into the array, can i word it like:  memcpy(dest+4,src,length) ?
12:38.32brlcadI saw getObj as give me any object from a .g, not necessarily a top object
12:39.26brlcadand yes re. memcpy
12:41.08dlomanthe coreInterface classes don't allow you to directly get an object with out knowing its (string) name, and there is no way to get that name unless you iterate, starting at the top.
12:42.09dlomantree walking to build an array of Objects hasn't been implemented yet, but thats ultimately what getObjs will do.
12:42.17brlcadsure, that's the same with librt too
12:42.20dlomanlikely get to that today.
12:42.30brlcadthat getObj() routine sounds like a routine to get a specific named object
12:43.40dlomanthe fn documentation will come soon, no worries.
12:43.43brlcadso if it has the name, there should be no involvement of TopObjectIterator()
12:44.43brlcadheh, so fix the problem by changing the function definition? .. the name alone implied that (which is a good thing)
12:46.29dlomandude, its a name.  can be changed at any time.  small potatoes at this point, especially when everything isn't solidified quite yet.
12:47.47brlcadof course, that's expected
12:47.53brlcadjust looking for clarification
12:48.31brlcadtrying to work on the code too, and if that's not a function that gets an object by name, then that obviously changes things
12:49.42brlcadif it is supposed to get an object by name, which is what seemed the more plausible (and useful) .. then the implementation didn't seem right
12:50.06dlomangetObj() gets the single object at the repo 'path'
12:50.21dlomangetObjs() gets multiple object at the repo 'path'
12:51.10dlomanafter implementing things now, it seems the use of getObj is nearly nothing, since getObjs can perform the same funciton by returning a list with one element.
12:51.22brlcadnods
12:51.29brlcadokay, that makes more sense then
12:51.34dlomanperformance and memory wise i am sure they are different.
12:51.38brlcadmeh
12:51.44dlomanbut im just going to leave them both for now
12:52.15brlcadseems error prone to allow a getObj when there may be more than one object to randomly be given "the first one"
12:53.59dlomanexactly why im thinking its going to go away soon, provided some profound reason to keep it.
12:54.58brlcadnow a general getObj() that returns a specific object by name would be more useful
12:55.16brlcadbut that gets into what you've named a path there and how that differs from a geometry path
12:55.51brlcadsomething to talk about later perhaps
13:22.15CIA-52BRL-CAD: 03brlcad * r44062 10/brlcad/trunk/src/librt/db5_types.c:
13:22.15CIA-52BRL-CAD: add a new routine that will return a standard attribute name by an index number,
13:22.15CIA-52BRL-CAD: so that we have a way to iterate over all the standard attribute names. this
13:22.15CIA-52BRL-CAD: simplifies db5_is_standard_attribut() iteration and lets us reuse the iteration
13:22.15CIA-52BRL-CAD: elsewhere.
13:27.37CIA-52BRL-CAD: 03brlcad * r44063 10/brlcad/trunk/src/librt/db5_types.c: swap los and air so that the index coincidentally matches the ATTR_* returned from db5_standardize_attribute()
13:31.49dlomand_rossberg: are you around?
13:34.42CIA-52BRL-CAD: 03brlcad * r44064 10/brlcad/trunk/src/librt/db5_types.c: even better, make the index-based lookup exactly match the ATTR_* index value. convert to an enum for proper numeric indexing.
13:38.18CIA-52BRL-CAD: 03brlcad * r44065 10/brlcad/trunk/src/librt/db5_types.c: document the need for these needing to not have gaps in their value. only specify the starting point to make is less error prone. add null case so gcc thinks we're covering all our bases.
13:50.36CIA-52BRL-CAD: 03brlcad * r44066 10/brlcad/trunk/src/librt/db5_types.c: simplify db5_standardize_attribute() by unrolling the loops. we have to perform all the comparisons anyways until we get a match, so just list them.
13:54.48dlomand_rossberg: I'm having an issue with a Database.Get() call.
13:55.34dlomanwhenever i get an Object using .Get(), the object's internal db_i* and diectory* are NULL.
13:56.11CIA-52BRL-CAD: 03brlcad * r44067 10/brlcad/trunk/src/librt/db5_types.c: shorten to attr
13:58.37dlomanConstDatabase::Get(char*)->ConstDatabase::get(char* ObjectCallback)->ObjectCallbackIntern::operator()->Arb8::Clone()->Arb8::Arb8->Object::Object->Object::Copy()
13:58.41dlomanthats the stack trace
13:59.20dlomanI don't ever see the m_dbip, m_pDir, or m_ip get copied.
13:59.24dloman...is that by design?
14:01.18brlcadstarseeker: can you help?  what is db5_standardize_avs() supposed to do?  I don't understand the comment
14:01.57starseekerbrlcad: one sec...
14:03.47CIA-52BRL-CAD: 03starseeker * r44068 10/brlcad/branches/cmake/ (6 files in 3 dirs): MFC r44067
14:04.17starseekerhrm... yeah, looks like brain backfired on that comment
14:04.21starseekerchecks code...
14:05.20starseekerOK, I think this was the thinking...
14:05.30brlcadsee if that says it
14:05.34CIA-52BRL-CAD: 03brlcad * r44069 10/brlcad/trunk/src/librt/db5_types.c: update comment for db5_standardize_avs(). is my understanding correct?
14:06.14starseekeryeah, that's pretty much it
14:06.41starseekerI think it might remove the old attribute that it's replacing with the new one, but will leave additional matches alone
14:06.45starseekerlet me check that though
14:07.08brlcadyeah, I was thinking it should remove all the matches
14:07.25starseekerthe problem with that is if an existing comb has both color and rgb
14:07.29starseekerwith different values
14:07.41brlcadsure, but what does that mean?
14:08.06starseekerwho knows?  but picking one means destroying one of the color settings, if we erase both of the old ones
14:08.41starseekeryesh, looks like that one isn't doing any erasing
14:08.47starseekerso your comment is right
14:08.50brlcadokay,that's cool
14:09.05brlcadi'd think we'd either wipe them all out with the new or leave them all intact and add new
14:09.30brlcadwe don't know what that data is but technically "we own it" because it's in the reserved namespace
14:09.37starseekernods - that MIGHT be why you were seeing multiple color settings on that havoc region...
14:09.51brlcadpossibly
14:10.12brlcadthough later in red, you go through the whole update/apply thing that should have consolidated
14:10.17brlcadmaybe
14:10.28brlcadhello hyarion
14:10.57hyarionhi
14:11.52d_rossbergdloman: see the docu of Get() in ConstDatabase.h: this method returns a copy of the object
14:12.09dlomanthe copy is disconnected from any database then?
14:12.15dloman...by design?
14:12.18d_rossbergthis seams to be a good idea because you close the database after each operation ;)
14:13.02dlomanrighto, that part is sensible.
14:13.26dlomanjust want to make sure I'm understanding your code correctly.
14:14.48d_rossbergthe deeper reason is the following:
14:16.27d_rossbergrt_db_get_internal() (as used in the Get()) always gives you a copy of the database object on a rt_db_internal structure
14:17.39d_rossbergtherefore you have to carefully choose the moment when to write back rt_db_internal into the database
14:17.49starseekerbrlcad: yeah, it looks like what's happening is db5_update_std_attributes is ensuring that all of the standard attributes correspond to the comb structure values - in the process, it's creating any that aren't already there (like color in the case of rt_r.pyl1)
14:18.47d_rossbergi'm doing it usually when the callback returns (see the callback version of Get())
14:19.21d_rossbergi.e. the non-const Get() in Database.h
14:19.32starseekerbut since I was trying to go with the "don't destroy information" policy, rgb got left
14:20.46brlcadthat's great
14:21.04brlcaddefaulting to don't destroy is always right :)
14:21.20d_rossberganother possibility is to take a copy of the Object explicitely (as you did) and leave it to the user to write it back to the database with Set()
14:21.41starseekeralso, I don't think db5_apply_std_attributes will remove excess extra settings...
14:21.48starseekerso that part of the comment may need updating
14:21.53brlcadk
14:22.17starseekerwe can make a function to do that, but I'd prefer it to be a separate call so the decision to possibly destroy data is isolated
14:22.17brlcadi'm simplifying standardize_avs() a bit now, given there's a function that will return the name by type
14:22.23starseekercool
14:22.35brlcadreduces almost all of the cases to just add
14:22.47d_rossbergor for short: Object is the C++ form of rt_db_internal which contains a copy of an database element
14:23.06starseekernow remember why that took so long... lots of annoying little questions to sort out...
14:23.37*** join/#brlcad Stattrav (~Stattrav@117.192.156.60)
14:23.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:23.59dlomand_rossberg: awesome, thanks man.  I figured out that in order to properly extract a bu_external from an Object, i should use an ObjectCallback
14:24.34starseekerbrlcad: probably the correct thing to do is if there is just one color attribute (e.g. rgb) it should get renamed
14:24.40starseekerso that may be a bug
14:25.04brlcadhm
14:25.19starseekerI thought I had some "first hit for type T" logic that would rename, but maybe I took it out as too complicated in the inital cut
14:25.32brlcadit's half in there :)
14:25.37brlcadsome of the types don't use it
14:25.50starseekerah, crud
14:26.02d_rossbergdloman: btw: Object has full attribute support including iteration
14:26.44starseekerwe can get fancier by checking the value of subsequent hits of the same type against the stored standard type, and only keep them (and display them) if they're different
14:27.05brlcadstill, I see this as an in-memory "upgrade my avs" routine .. so it can convert any it finds, consolidate any that are the same value, and otherwise rename the first to standard form
14:27.06starseekerthat's probably the best case - preserve and display conflicting data if it actually conflicts, otherwise standardize
14:27.22starseekerer, yeah :-)
14:33.24brlcadhad a memory leak in there bu_avs_add() already copies the value for you
14:33.49starseekerah
14:34.02CIA-52BRL-CAD: 03starseeker * r44070 10/brlcad/trunk/include/raytrace.h: Update db5_is_standard_attribute in raytrace.h
14:39.13CIA-52BRL-CAD: 03starseeker * r44071 10/brlcad/trunk/src/libged/red.c: fix red.c extern too
14:40.29d_rossbergdloman: ps: this way you can copy an Object from one database to another: Get() from the first one and Add() to the other one
14:40.53dlomanexcellent
14:41.14dlomanI am actually looking to properly create a bu_external, which requires a valid db_i* and directory*
14:41.59brlcaddloman: only that one routine required a db_i, there are other routines that work with data in other stages of the i/o process
14:42.13brlcadmight be something else that can be used
14:42.33brlcadlooks
14:45.38brlcadwhat data do you have now?
14:45.47brlcadan rt_db_internal *?
14:47.08dlomanwell, if hook into ab Object before it gets .Clone()-ed, then i will have everything (db_i, rt_db_internal*, resource* and directory*)
14:47.16dlomanotherwise, i have none of those.
14:47.46brlcadnone?  if it made a copy, you ahve at least the rt_db_internal I'd think
14:48.00d_rossbergdloman: for low level operations you should consider to use the C API directly, the C++ interface is definitely not the place for such tasks
14:49.10d_rossbergno, he has nothing because the database will be closed after getting the object
14:49.30brlcadd_rossberg: we could still encapsulate serialization as something inherent to an Object, a Serialize() routine that returns a bu_external for example
14:50.17brlcadd_rossberg: then how'd it 'get' the object?  extracts values into private member data from the db_intern?
14:52.25d_rossbergit has a private char* for the name, bu_attribute_value_set for the attributes and rt_~_internal for the element specific stuff
14:53.10brlcadah, so it fully uncracks the rt_db_internal
14:53.19d_rossbergand serialization isn't trivial, it depends on the protocol used and purpose
14:53.51d_rossberge.g. i would prefer a serialization in xml
14:54.10brlcadheh
14:54.36d_rossbergor with other words: this is something for the level above the core interface
14:55.34brlcadand/or below it
14:56.24brlcadi could still see it providing some default serialization capability that it could use for persistence and reconstruction
14:56.26d_rossbergfor the network my first idea would be to use something like corba
14:57.13brlcadbut that's so much overhead ...
14:57.45brlcadand nobody likes writing corba code :)
14:58.00d_rossbergthis point is on you :)
14:58.01brlcadexcept businesses that are paid/forced to :)
14:59.15*** join/#brlcad Elrohir (~kvirc@p5B14A416.dip.t-dialin.net)
15:01.27dlomanwho knew the Dune soundtrack makes cood coding music.....
15:02.18d_rossberghowever, the "default serialization" should >mainly< (whatever this will mean) be database independend because it is used in an abstraction layer
15:03.21brlcadyeah, I'd think you'd want it to be a black box serialization
15:04.11brlcadeither to a generic form (like xml, shudder!) or to an opaque type that you aren't supposed to inspect beyond passing to a Deserialize() call
15:04.47brlcadI was thinking more the latter and just ganging up on the existing serialization routines used for disk since they're compact and really fast
15:05.29starseekeryeah... I thought the external disk format was a serialization - is there some situation where that's not appropriate?
15:05.45starseekerxml I can see only as an archival ascii format (maybe)\
15:05.54brlcadstarseeker: it's "not appropriate" if you don't want to deal with binary data :)
15:06.06starseekerah heh
15:06.20brlcador want to pass it through some other parsing engine
15:06.49brlcadconverting to asc is technically a serialization too, just a not very interesting one
15:07.42d_rossbergit is the most interesting one: ican read it
15:08.02brlcadhow about json then?  even easier to read ;)
15:08.14brlcadand less verbose
15:08.18d_rossbergjson who?
15:08.20brlcadruns and hides
15:08.40dlomanshould I call BU_INIT_EXTERNAL on a bu_external prior to passing the bu_external into db_get_external(..) ?
15:09.16d_rossbergwasn't there a windows ini-file format?
15:09.53brlcaddloman: not necessary
15:10.11brlcadd_rossberg: heh, now you're just talking crazy ;)
15:10.50brlcadthat's about as bad as a self-unarchiving shell script
15:12.44starseekerd_rossberg: http://www.json.org/
15:13.33starseekerhttp://oss.metaparadigm.com/json-c/ would probably be useful
15:13.46brlcadI think he was being facetious
15:13.52starseekerah
15:19.27starseekerbrlcad: fwiw, a comb with only one entry and a matrix on that entry DOES allow me to save the change
15:19.44starseekerit's where there are multiple entries in the comb tree with matricies that I can confirm the failure
15:19.52brlcadokay
15:23.12dlomananyone familiar with a Segfault dealing with _dl_fixup() in /lib64/ls-linux-x86-64.so.2 ?
15:29.12*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
15:29.26brlcader... ld is trying to dynamically load something and it can't?
15:29.39brlcadshouldn't be any dynamic loading that I know if
15:30.05dlomani hate this crap :/
15:30.35brlcadwhat'd you change that got you into that state?
15:31.03brlcadjust back up to the previous commit, work forward in smaller steps
15:31.13dlomani literally copy/pasted a class, changed the guts of one function.
15:32.59brlcadare you using run-time type inference?
15:33.06brlcadin that class
15:34.30dlomani don't think i am
15:34.57dlomannoob question:   is subclassing considered type inferencing?
15:35.30brlcadthen it "probably" was more than a simple copy/paste change, even if that's all you may have intended ..
15:35.57brlcadin general no, but subclassing a class that uses rtti might get you into trouble
15:35.58dlomanheh, obviously something got messed up. :/
15:36.58brlcadwithout sitting at a debug console, "back it up" is probably the easiest debug route to see where you went wrong
15:37.33dlomani've got it isolated down to a function call, but it doesnt make sense atm.  still trying to figger it out.
15:37.44brlcadthat error sounds like the dynamic linker saying "I can't find a class I'm told to use"
15:39.45dlomanhrm, if I comment out the call to db_get_external(), everything works .....
15:40.13brlcadare you linking librt?
15:40.46brlcadcould be a bonefide crash due to bad data or bug and the _dl_fixup is just a red herring
15:48.33brlcadstarseeker: I think I see how the attibute got double-listed
15:48.55brlcadrewriting db5_standarize_avs() is pretty tricky with all of the various cases
16:05.25dlomanso its not a linker issue... i'm linking ALL of brlcad libraries.
16:05.46dlomanbut _dl_fixup is throwing the segfault, according to gdb
16:11.41dlomanbrlcad: you still around?
16:14.35brlcadyep
16:15.00brlcadwhere's it segfaulting, what's the rest of the stack?
16:15.04dlomanPro tip:  Turns out that bu_malloc is handy for allocating memory for pointers.
16:15.09dlomanjust fyi
16:15.14dlomanfacepalms
16:15.24brlcadhaha
16:15.33brlcadbu_calloc() is even better
16:15.43dlomanyeah, whats the diffference?
16:15.48brlcadzeros the memory
16:16.10dlomancosts a bit more cpu time?
16:16.15brlcadmalloc will allocate you a memory buffer, but there could be any random garbage in that buffer
16:16.28brlcadinsignificant
16:16.49dlomanso there really is no reason to ever use anything other than calloc?
16:16.53brlcadthe system call itself is two orders more expensive, so might as well spend one or two clock cycles and have fresh zero'd memory
16:17.31brlcadwell, if the very first thing I was going to do with the memory was clear it or set it, then bu_malloc makes sense
16:18.01brlcadbut talking full-allocation set, which doesn't happen very often
16:19.30brlcadbasically, if you want to be a little more cautious and avoid some obscure bugs, use bu_calloc() until you know better :)
16:20.00brlcadit's never "wrong", it just might be unnecessary
16:20.04dlomanbugs like me, thus i like calloc
16:20.31brlcadit's like initializing all your variables when you declare them
16:20.38dlomanright on
16:20.39brlcadI tend to init to zero and/or NULL
16:20.52brlcadbut if the very next thing I'm going to do with them is set their value, it was pointless
16:21.19brlcadif I don't set their value until later down in the function, it might actually save my butt some day to init them
16:21.29brlcadit might save me down the road anyways if I just init them
16:22.15brlcadstarseeker: if you care to double-check my logic on this, I think I have it
16:24.12CIA-52BRL-CAD: 03davidloman * r44072 10/rt^3/trunk/ (4 files in 2 dirs): Added the ability to get a bu_external* from a ConstDatabase and Object. Needed for serialization
16:25.42CIA-52BRL-CAD: 03brlcad * r44073 10/brlcad/trunk/ (include/raytrace.h src/librt/db5_types.c):
16:25.42CIA-52BRL-CAD: document the db5_standard* functions, pulling comments from source to header and
16:25.42CIA-52BRL-CAD: expanding with a note that they're new/private. reimplement
16:25.42CIA-52BRL-CAD: db5_standardize_avs() using simple two-pass logic so standard attributes take
16:25.42CIA-52BRL-CAD: precedence. use db5_standard_attribute() in conjunction with
16:25.42CIA-52BRL-CAD: db5_standardize_attribute() in leu of tables so we don't have to repeat any
16:25.43CIA-52BRL-CAD: values or even be aware of what is standard or not.
16:25.47brlcadthat should prevent the double-listing
16:46.50*** join/#brlcad Stattrav (~Stattrav@117.192.156.60)
16:46.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:15.22starseekerbrlcad: looks good
17:25.02CIA-52BRL-CAD: 03davidloman * r44074 10/geomcore/trunk/ (7 files in 4 dirs): Clean up a few bugs in ByteArray. Added ByteArray copy cstr. Converted GenericMultibyteMsg and GeometryChunk to use ByteArray objects (since they are thin wrappers around bu_vls)
17:26.32CIA-52BRL-CAD: 03starseeker * r44075 10/brlcad/trunk/src/libged/red.c: Looks like this might be the culprit - combtree_op_regex with blank seems to work for matricies
17:27.04starseekerbrlcad: does that let you edit matricies?
17:43.19CIA-52BRL-CAD: 03erikgreenwald * r44076 10/brlcad/trunk/src/libged/red.c: include raytrace.h for prototype. remove extern func decl
17:52.42CIA-52BRL-CAD: 03davidloman * r44077 10/geomcore/trunk/ (include/DataManager.h src/GS/DataManager.cxx): put in bu_external<->GeometryChunkMsg conversion functions.
18:06.54CIA-52BRL-CAD: 03davidloman * r44078 10/geomcore/trunk/include/GeometryChunkMsg.h: Forgot a file in the ByteArray cleanup....
18:20.15brlcadstarseeker: testing
18:24.26starseekerbrlcad: I see you listed red comb renaming as something to support for the next release?
18:25.10brlcadwith all this attention needing to go towards red, might as well finish it while it's all in context
18:25.33brlcadotherwise it'll never get done unless there's another set of bugs
18:25.36starseekerso we should make write_comb work on copies as well?
18:26.17brlcadyeah, I was basically reviewing from top to bottom
18:26.48brlcadgot to the attr stuff, and a bit more to finish up in there
18:27.40brlcadsorting out what this std avs api should look like now
18:29.05brlcadif you want to hit up write_comb in the meantime, you're welcome to but might be less conflict if you work either on recognizing the name change or making sure the read-in is robust
18:29.28starseekeris working on the rename
18:30.04brlcadbasically just trying to get things to a no-hack "done" state without adding any new functionality/features
18:30.48brlcadnice work on the std avs stuff by the way -- the functions work pretty well together
18:30.57brlcadjust that one missing so far, and maybe some name cleanup
18:31.12starseekerthanks :-)
18:32.07CIA-52BRL-CAD: 03brlcad * r44079 10/brlcad/trunk/include/raytrace.h: add the other 'new' attr funcs that are needed for the symbols to get published. still a work-in-progress.
18:32.49CIA-52BRL-CAD: 03brlcad * r44080 10/brlcad/trunk/include/raytrace.h: private funcs till names get changed
18:32.59starseekeris there a case-insenstivie version of the bu string comparison macro?
18:33.54brlcadwe use something in a few other places, maybe strcasecmp
18:35.48brlcadyeah, we surprisingly don't do a lot of string-insensitive comparisons
18:35.59brlcadlibfb options
18:39.08brlcadmight be simple enough to add a BU_STRI_EQUAL and friends
18:39.40brlcador BU_STRCASE_EQUAL
18:45.16brlcadstarseeker: the other thing I wanted to change .. you have all that logic in write_comb for pretty-printing, but standard printf has options that do most of that built-in
18:48.32*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
18:49.16AbhijitKanebrlcad: do you have any info on the old material database / website?
18:52.12brlcadAbhijitKane: yes, I do
18:52.13CIA-52BRL-CAD: 03erikgreenwald * r44081 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: Flush output buffer at end of msg write. Implement implement ping, info, fail, ok, rualive and imalive.
18:52.52AbhijitKanebrlcad: i've started with a draft proposal, and was wondering what i could add to it
18:58.39kunigamihi, which string should be passed to bu_malloc and bu_free?
18:59.17``Erikanything that explains what the memory is for, it's to help in debugging
19:00.34brlcadAbhijitKane: the existing dev interface is at mater.brlcad.org
19:00.56starseekerbrlcad: ah, figures
19:01.16AbhijitKanenods
19:01.24starseekerwades into the rename logic...
19:01.31kunigamiok. I'll pass the name of the first pointer for which the memory is being allocated
19:01.36starseekerlet there be build failures!
19:02.04brlcadkunigami: just something short but descriptive "alloc foo", "free foo"
19:02.35brlcadthe bu_calloc/bu_malloc string should pair up with the bu_free() string
19:03.15brlcadnot necessarily the same string, but if you were reading a log file, some reasonable pairing so you could check the pairings if you needed to
19:04.26kunigamihmm what if I allocated in bu_basename as bu_malloc(..., "foo"), then I tell in the documentation that bu_free(..., "foo") should be called?
19:05.09brlcadnot necessary
19:05.39brlcadmaybe "bu_basename alloc"
19:08.40kunigamithen bu_free(..., "bu_basename free")?
19:10.39brlcadwell the free happens in userland code, not library code so you don't really have any control over that
19:14.26kunigamihmm, understood. so I'll just do bu_free(var, "var free"). sounds good?
19:15.33brlcadkunigami: but where are you calling bu_free?
19:15.57AbhijitKanebrlcad: regarding the materials site, could there be google/openID integration as well?
19:15.57AbhijitKane<PROTECTED>
19:16.27kunigamiright before the scope of the variable returned by bu_basename ends
19:16.28CIA-52BRL-CAD: 03davidloman * r44082 10/geomcore/trunk/src/libNet/NetMsgRouter.cxx: Use the word 'routing' instead of 'forwarding' when talking about the routing of NetMsgs. Confused some people, this is better.
19:16.32brlcadAbhijitKane: the issue there is we presently have accounts in drupal and mediawiki ... there was an effort to integrate them into one ldap but that's incomplete
19:17.35brlcadadding in google/openID adds more account auth but doesn't integrate with the other two, so not much of a benefit integration-wise
19:17.52brlcadnow if you also update our drupal/MW installs to use google/openID, then that'd be different
19:18.07brlcadcould be a little subtask
19:18.59AbhijitKaneok
19:19.00brlcadotherwise, auth is a much lesser concern to getting add/edit/inherit/view/delete working cleanly
19:20.14AbhijitKaneyes, getting the crud operations working properly will be the first priority
19:20.57brlcadcrud? :)
19:22.30AbhijitKanecreate read update delete. but i'm not sure whether i'm using it in the right context, lol
19:22.36CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2781 10/wiki/NetMsgTypes: add more info
19:23.48kunigamiin brlcad_path.c there's a line: return bu_basename(bu_progname);  --- where bu_progname is a global variable. how to proceed?
19:24.27CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2782 10/wiki/GeometryReqMsg: New page: Message sent to the server to request data. Single GSString with a URI/URN style encoding of the geometry (path/to/file.g/top). (Should this be a multistring message?)
19:26.27brlcadkunigami: probably something similar to bu_argv0_full_path() where it has an internal static buffer, get the basename, copy into buffer, free the basename, return the buffer
19:27.42CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2783 10/wiki/GeometryManifestMsg: New page: Sent after a geometry req is recv'd, but before the chunks are sent. uint32 number of objects/strings/chunks. List of GSStrings for returned objects. ReUUID is the same as the GeometryR...
19:30.24CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2784 10/wiki/GeometryChunkMsg: New page: Actual raw binary V5 .g goodness. ReUUID is the same as the associated GeometryReqMsg's UUID. There will be the same number of these as there were entries in the GeometryManifest. NOT ...
19:31.41CIA-52BRL-CAD: 03Erik 07http://brlcad.org * r2785 10/wiki/GeometryChunkMsg: mention length in stream
19:33.24kunigamibrlcad: hmm good idea
19:33.35CIA-52BRL-CAD: 03starseeker * r44083 10/brlcad/trunk/src/libged/red.c: Add the ability for changing name assignment in the red.c text file to rename the comb being edited.
19:33.41starseekerbrlcad: there we go
19:33.50brlcadstarseeker: awesome
19:34.22brlcadbtw, just found (and hopefully fixed) a particularly egregious bu avs iterator bug
19:34.23starseekerneeds another set of eyes, but it seems to work here
19:34.39starseekerin red or in libbu?
19:34.45brlcadlibbu
19:34.50starseekerow
19:34.58brlcadthe BU_AVS_FOR() macro iterates from the end to the front, from count-1
19:35.08brlcadso if count == 0 ... poof
19:35.14starseekerwinces
19:35.31starseekeryeah, that's not good...
19:38.04CIA-52BRL-CAD: 03starseeker * r44084 10/brlcad/trunk/TODO: r_weiss fixed dem-g crashes
19:38.14CIA-52BRL-CAD: 03brlcad * r44085 10/brlcad/trunk/include/bu.h:
19:38.14CIA-52BRL-CAD: bad AVS, no donut for you. BU_AVS_FOR() macro iterator starts from the end of
19:38.14CIA-52BRL-CAD: the avs to the beginning. however, if the avs is empty, this would result in
19:38.14CIA-52BRL-CAD: indexing into a -1 index and potentially cause a segfault. make the loop safe
19:38.15CIA-52BRL-CAD: by setting it to null if count is zero, so it should kick right out of the loop.
19:39.21brlcadhm, that's insufficient
19:43.47CIA-52BRL-CAD: 03davidloman * r44086 10/geomcore/trunk/ (include/SvnDataSource.h src/GS/SvnDataSource.cxx): Implement required functions for SvnDataSource as spelled out by IDataSource
19:50.56CIA-52BRL-CAD: 03davidloman * r44087 10/geomcore/trunk/ (3 files in 2 dirs): Update data sources to pass back bu_externals instead of Objects. This isn't optimal, nor do i think it will be permanent, but its the best approach at the moment.
19:52.40CIA-52BRL-CAD: 03erikgreenwald * r44088 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: implement geomreqmsg and geommanifestreq. stub geomchunkmsg.
19:54.37CIA-52BRL-CAD: 03davidloman * r44089 10/geomcore/trunk/src/GS/DataManager.cxx: Make DataManager handle bu_externals rather than Objects
19:56.46CIA-52BRL-CAD: 03brlcad * r44090 10/brlcad/trunk/include/bu.h: need to make sure we don't enter the loop with that NULL pointer. halt if iterator or target is NULL
19:57.54brlcadthere, that should allow looping over empty avs
19:57.58CIA-52BRL-CAD: 03davidloman * r44091 10/geomcore/trunk/tests/GS/ (CMakeLists.txt FileDataSourceTest.cxx): lots of cascading changes to FileDataSourceTest
20:01.37CIA-52BRL-CAD: 03brlcad * r44092 10/brlcad/trunk/include/bu.h: go a step further and don't try to dereference the avs if we get handed a NULL pointer. one more example of the lengths we go to for you. because we care.
20:04.34dlomanlol nice one.
20:04.51dlomanthat's a bumper sticker if i've ever seen one.
20:06.29*** join/#brlcad volock (~chatzilla@174.46.225.138)
20:07.39CIA-52BRL-CAD: 03brlcad * r44093 10/brlcad/trunk/include/bu.h: document BU_AVS_FOR() macro with an example code snippet.
20:10.59CIA-52BRL-CAD: 03brlcad * r44094 10/brlcad/trunk/include/bu.h: tweakage
20:11.52kunigamiin nirt/if.c there's a external array, ValTab. There are at least two elements of ValTab that store the output of bu_basename. should I use the static buffer trick?
20:13.37CIA-52BRL-CAD: 03brlcad * r44095 10/brlcad/trunk/src/librt/db5_types.c: use db5_standard_attribute() instead of hard-coding the standard attribute names in db5_apply_std_attributes(). also check our inputs in db5_standardize_avs().
20:16.17volock<PROTECTED>
20:16.18volock...though I've also used BSP and Oct Trees.  I'm trying to think out how an API like is asked for should work. IE. What kind of data it'd be expecting, etc for crafting my proposal
20:16.49brlcadkunigami: at a glance, you can either wrap the output in bu_strdup() then free the memory at the end (see 'need_to_free' for similar issue) ... or you can reuse the existing regionPN buffer presuming ValTab is not used after that function
20:16.54brlcadhello volock
20:17.44volockhello brlcad. You're Chris right?
20:18.03brlcadsome people call me that
20:18.06brlcadmost call me Sean :)
20:19.09volockAh. I was going from memory from reading the wiki you set up for us prospective GSoC people. You guys definitely have a lot of interesting coding to do, that looks like a lot of fun. Then again as an Applied Math and CS double major, my view may be a little skewed.
20:20.58brlcadthanks, most of us tend to think it's a lot of fun too
20:21.24brlcadas for the spatial partitioning project, the #1 difficulty there is going to be careful integration
20:22.26brlcadthat gets at the very heart of our core library, which is highly optimized for our current purposes, customers, raytracing, etc
20:23.22brlcadideally, you'd not only have pretty good familiarity with spatial partitioning but also with our LIBRT library and how it does what it does currently
20:24.15brlcadeven something as simple as abstracting out what it currently does without affecting performance could be very tricky
20:24.46brlcadmuch harder to implement a completely different modular partitioning scheme that actually out-performs :)
20:25.15brlcadso that's not mean to scare or entice you, it's just the matter-of-facts surrounding that particular project
20:26.39volockYeah. I have experience with Spatial Partitioning both from a raytracer and working for someone doing particle physics. Those were considerably simpler than this would be obviously. Not only because your problem contains performance constraints compared to what has probably been highly optimized code over years, but in the variety of data you'd want to easily send to the API
20:32.07brlcadthe other kicker is that our spatial partitioning has to be at least partially aware of the construction hierarchy since we use constructive solid geometry (CSG) where there may be void regions or unknown overlap conditions
20:32.15brlcadwe only rarely deal with polygons so all you really have for binning things together is a primitive's overall bounding box or bounding sphere
20:32.17brlcadso, what brought you to brl-cad's ideas list?
20:32.21brlcador not
20:32.41*** join/#brlcad volock (~chatzilla@174.46.225.138)
20:33.21kunigamibrlcad: is there any guarantee that after the 'need_to_free' region the memory allocated won't be used?
20:33.45brlcaddidn't look through the code that closely, good question :)
20:36.06kunigamiwell, yesterday you said that if refactoring the code would take more than 15 minutes I should tell you :P I think I spent at least an hour on it :)
20:38.06*** join/#brlcad volock (~chatzilla@174.46.225.215)
20:38.29volockSorry my internet connection decided to go out
20:38.57brlcadkunigami: yes, fair enough -- it's a task for someone, that doesn't necessarily need to be you right now
20:39.25brlcadif you're selected, maybe you can finish the job on your own patch if someone else hasn't by then :)
20:41.05kunigamihmm, ok. that's the only file that is not that trivial to change. All other ocurrences of bu_basename I've already changed. Should I re-submit the patch with this new changes for registration?
20:42.35brlcadabsolutely
20:43.04brlcadhelps to give them new name either on the file or the comment, so can tell which is the latest
20:56.32CIA-52BRL-CAD: 03erikgreenwald * r44096 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: implement chunking protocol. Add "getgeom" conviencience function
20:58.50kunigamibrlcad: ok, I'll append a version on it
21:11.03kunigamiIf I write more than one proposal and both are accepted, will you take into consideration the priority of my choices?
21:13.50brlcadboth can't be accepted -- we'd narrow it down to one or the other
21:14.15brlcadbut that said, your interest definitely matters too, so write down your priority in the proposal too
21:15.54kunigamihmm ok
21:17.52brlcadproposals often do get changed throughout the course of the summer too, so long as we're both in agreement on the goals and approach as things change
21:18.43brlcadagain, we care more about integrating new developers than we do about getting a particular chunk of code written
21:22.21CIA-52BRL-CAD: 03starseeker * r44097 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r44096
21:25.33kunigamiperfect!
21:27.31kunigamihmm, does anyone know if melange allows editing the proposal? or if I want my proposal to be reviewed I should write it in other place (google docs for example) and send only the final revision to melange?
21:28.57brlcadyes, you can continue to edit up to the deadline
21:29.09brlcadwe will write questions and comments there too
21:29.28brlcadif you want feedback beforehand, suggest wiki or google docs
21:29.50brlcadotherwise, not much difference when/where the comments occur -- other than the earlier the better
21:30.01brlcadgets really hectic in the last few days
21:39.48*** join/#brlcad ``Erik (~erik@BRLCAD.ORG)
21:39.51CIA-52BRL-CAD: 03erikgreenwald * r44098 10/geomcore/trunk/src/interfaces/cl/ (gsclient.asd gsclient.lisp gsnet.lisp): break GS net ops into seperate package
21:56.29CIA-52BRL-CAD: 03starseeker * r44099 10/geomcore/trunk/tests/svntest/ (CMakeLists.txt main.c): Get as far as deleting and adding files via the commit editor - still don't have the ability to apply diffs.
22:01.28CIA-52BRL-CAD: 03brlcad * r44100 10/brlcad/trunk/src/librt/db5_types.c: check our inputs for sanity on all the avs standard attribute functions
22:06.04volockHow many people can BRL-CAD hire through GSoC? And how many typically apply (out of curiosity)?
22:17.26brlcadvolock: we don't consider them as "hires", it's not just a summer job
22:17.47brlcadif it's just a summer job to you, then GSoC (with any org) might not be right for you
22:18.18brlcadthe intention is to get you involved in open source development as a long-term contributor
22:20.12brlcadotherwise, we talk about it some at http://brlcad.org/wiki/Google_Summer_of_Code and this year's slot count specifically at http://brlcad.org/wiki/Google_Summer_of_Code/2011
22:25.16CIA-52BRL-CAD: 03starseeker * r44101 10/geomcore/trunk/tests/svntest/main.c: OK, this creates a new file and gets contents into it. Next step will be to change the contents of an existing file.
22:41.25*** join/#brlcad piksi (piksi@pi-xi.net)
23:01.09*** join/#brlcad ibot (~ibot@rikers.org)
23:01.09*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011 Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011
23:14.33*** join/#brlcad b0ef (~b0ef@157.26.202.84.customer.cdi.no)
23:25.13CIA-52BRL-CAD: 03starseeker * r44102 10/geomcore/trunk/tests/svntest/main.c: grr - need to figure out how to handle svn_txdelta_run, apparently...
23:31.40brlcadfor anyone that missed our logo limelite: http://imagepaste.nullnetwork.net/viewimage.php?id=1980
23:32.33brlcadto be repeated in a few hours :)
23:33.28CIA-52BRL-CAD: 03starseeker * r44103 10/geomcore/trunk/tests/svntest/main.c: Hmm - doesn't look like reading file contents from the repo was the issue - maybe the md5 checksum is really necessary.
IRC log for #brlcad on 20110331

IRC log for #brlcad on 20110331

01:10.50*** join/#brlcad crazy_imp (~mj@a89-182-194-151.net-htp.de)
01:38.13*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
03:20.51*** join/#brlcad sachinjain (~sachin@117.211.88.150)
03:26.31*** join/#brlcad sachinjain (~sachin@117.211.88.150)
03:57.24dlomangetting a failure in libged/list.c
03:57.36dloman../../../brlcad-trunk/src/libged/list.c: In function ?_ged_do_list?:
03:57.36dloman../../../brlcad-trunk/src/libged/list.c:146: error: the address of ?avs? will always evaluate as ?true?
03:57.49dlomanreplace ? with '
03:58.31*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
04:02.55*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
04:05.30brlcadlooking
04:09.25brlcaddloman: try that
04:09.37CIA-52BRL-CAD: 03brlcad * r44104 10/brlcad/trunk/include/bu.h: attempt to quell warning about stack avs reference address always evaluating as true.
04:10.12dlomankk
04:12.01dlomancompile has gotten farther than i did last time, so itink u got it.
04:12.39brlcadlil ridiculous
04:25.14CIA-52BRL-CAD: 03brlcad * r44105 10/brlcad/trunk/include/bu.h: add parens
04:37.54sachinjainhey brlcad
04:38.28sachinjainI am trying to do one of the "quickies" to understand BRL-CAD
04:40.10sachinjainthere is this project "Fix 'analyze' command output formatting"
04:40.33sachinjainI have made some changes in the file "src/libged/analyze.c"
04:40.58sachinjainbt when I am compiling, I am not able to see those changes
04:41.19sachinjainI think...there is problem with compiling part
04:41.42sachinjaincan you tell me what are all the files that I need to recompile
04:41.43sachinjain?
04:43.01sachinjainplease help me
04:43.23sachinjainI have already run the "makefile" of "libged" directory
04:47.56dlomanfrom the root of the project, all you should have to do is type 'make'
04:48.13dlomanand any changes to source should recompile and link autojmaticaly
04:50.04sachinjainbt that is taking so much time
04:50.33dlomando yo uhave a multi core computer?
04:51.12sachinjaincore 2 duo
04:51.19dlomanokay then
04:51.33dlomantry using the command: 'make -j2' or 'make -j3'
04:51.53dlomanthat will start 2 or 3 compiling jobs simultaneously.
04:51.54dlomanthings go a lot faster that way
04:51.59sachinjainok
04:52.07dlomanmany things in brlcad rely on others being compiled.
04:52.17sachinjainhmmm....
04:52.22dlomantake the time and do a full compile and things will work better.
04:52.30sachinjainI thought of recompiling the whole thing earlier
04:52.44dlomanhave you compiled the entire suite yet?
04:52.48sachinjainyup
04:52.52dlomankk
04:52.54dlomanso 'make
04:53.06dlomanfrom the root of the checkout dir shouldn't take too long
04:53.45sachinjaingonna ask one question....
04:53.54sachinjainif I would do this project....
04:54.12sachinjainthen...your requirement of "making a patch" will be fulfilled
04:54.24sachinjainor do I need to do something more?
04:55.19dlomanI'll defer that question to brlcad himself, he's the GSoC Admin for us.
04:55.34sachinjainyeah...I am asking to him only
04:55.39sachinjainno offence to you dloman
04:55.40sachinjain:)
04:55.44dlomannon taken
05:28.49brlcadpoor sachin
05:32.01bhinesleylol
05:36.13CIA-52BRL-CAD: 03davidloman * r44106 10/rt^3/trunk/ (5 files in 2 dirs):
05:36.13CIA-52BRL-CAD: Stub in MinimalDatabase and MinimalObject. After some thought, reading and
05:36.13CIA-52BRL-CAD: notes, a cleaner/simpler way to interface GS and CoreInterface with eachother is
05:36.13CIA-52BRL-CAD: needed. These two classes will form the bulk of this new approach.
06:18.24brlcadcalls it a night
06:24.59*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:24.59*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:52.26*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
07:39.42*** join/#brlcad sachinjain (~sachin@117.211.88.150)
07:47.24sachinjainhey brlcad
07:51.11sachinjainbrlcad : are you there?
08:05.55sachinjainhey...is there a way to decrease the compiling time?
08:06.33*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:19.19*** join/#brlcad sachinjain (~sachin@117.211.88.150)
08:24.48CIA-52BRL-CAD: 03davidloman * r44107 10/rt^3/trunk/ (4 files in 2 dirs): Match up cstr and dstr signatures with superclass.
08:29.51sachinjainhey...dloman
08:29.58sachinjainthat recompiling is taking so much time
08:47.49sachinjaindloman : I am getting some error while recompiling
10:33.02*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:49.34dlomansachinjain: .....and the error is?
11:10.25sachinjain"libtool: link: `../../src/libwdb/libwdb.la' is not a valid libtool archive
11:10.25sachinjainmake: *** [libged.la] Error 1"
11:10.30sachinjainthis is the error
11:17.51sachinjaindloman : are you there?
11:18.38CIA-52BRL-CAD: 03davidloman * r44108 10/rt^3/trunk/ (6 files in 4 dirs): Add tests into build. Clean up remnants of old cmake system. Add libge tests.
11:21.47dlomansachinjain: did you do a clean prior to the rebuild?
11:24.43sachinjainno
11:25.10dlomantry a 'make clean'
11:25.17dlomanthen a 'make -j3'
11:25.24dlomanactually
11:25.29dloman'make clean'
11:25.32dloman'svn up'
11:25.38dlomanthen 'make -j3'
11:27.56sachinjainwhy am I not able to see those changes which I had made in a file?
11:28.19dlomanwhat file?
11:28.38sachinjain/src/libged/analyze.c
11:30.22sachinjaindo I have to recompile the whole thing....
11:30.51sachinjainor can I run just the "makefile" in  /src/libged directory
11:37.00CIA-52BRL-CAD: 03davidloman * r44109 10/rt^3/trunk/ (include/MinimalDatabase.h src/libge/MinimalDatabase.cxx): Stub in desired functions for MinimalDatabase
11:38.18dlomanall you should have to do is type 'make' form the top level directory for any changes.
11:38.26``Erikyou can do it in just the libged directory, but you'll need to make sure the dependancies for libged are built first... we usually do a big "make" after configure, then just keep running make when we update things. Make won't rebuild files it doesn't have to (my old mac takes about 14 seconds over nfs)
11:43.31CIA-52BRL-CAD: 03davidloman * r44110 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Fill out MinimalObject fields and associated Getters.
11:46.59*** join/#brlcad sachinjain (~sachin@117.211.88.150)
11:49.56CIA-52BRL-CAD: 03davidloman * r44111 10/rt^3/trunk/include/MinimalObject.h: Protect MinimalObject cstr, should not be public.
11:54.56CIA-52BRL-CAD: 03davidloman * r44112 10/rt^3/trunk/tests/libge/ (CMakeLists.txt GeometryEngineTest.cxx): Add libge to cmake link list. Flesh out GE Test a bit more. Make fn for standard db generation for testing.
11:55.43CIA-52BRL-CAD: 03davidloman * r44113 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Add a temporary debug fn for printing MinimalObject's internal state.
11:57.30CIA-52BRL-CAD: 03davidloman * r44114 10/rt^3/trunk/src/libge/MinimalDatabase.cxx: Stub in NULL returns in all functions till implemented.
12:12.24brlcadsachinjain: you can rebuild in just the subdir, but you may have to run make depends first
12:12.38brlcad``Erik: all sorts of tinyproxy errors
12:22.20*** join/#brlcad sachinjain (~sachin@117.211.88.150)
12:25.32sachinjaindloman : did you get my messages?
12:26.02dlomannope.  /msg here or email or.... ?
12:26.23sachinjainI have made some changes to the file "/src/libged/analyze.c"
12:26.30sachinjainand then rebuild the whole thing
12:26.38sachinjainbt now...when I am running "analyze" command through mged terminal...
12:26.46sachinjainI am not able to see those changes
12:27.04starseekersachinjain: are you running from the build directory or the install directory?
12:27.08starseekere.g. did you run make install?
12:27.30sachinjainfrom the root directory?
12:27.42starseekerhow are you running mged?
12:27.46starseekerjust typing mged?
12:27.59sachinjainyeah
12:28.14starseekertype "which mged" (no quotes)
12:28.19starseekerwhat does it report?
12:29.38sachinjain/usr/brlcad/bin/mged
12:30.04starseekerthat's why your not seeing changes - when you type mged you're getting the installed version
12:30.12sachinjainso?
12:30.28starseekeryou either have to run make install so your altered version is installed, or specifically run the version in the build directory
12:30.29sachinjainwhat do I do now?
12:31.19starseekerjust typing "make" does not put mged in /usr/brlcad/bin/mged
12:31.41sachinjainokie...
12:31.44sachinjainI got you
12:31.46sachinjainlet me try now
12:35.55sachinjainstarseeker : thanks a lot....it worked
12:55.28``Erikbrlcad: errors? there was a bit of a fit getting it installed and configured right (used to use crit for that...  how's the user migration, btw?)
13:01.41*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:04.43brlcadd_rossberg: you raise a lot of good points, I'm responding to the them now -- some conceptual, some more short-term work-in-progress mes
13:15.48sachinjainbrlcad : I am working on one of the quickies "Fix 'analyze' command output formatting"....
13:16.25sachinjainwill that complete your requirement of "making a patch"
13:16.27sachinjain??
13:20.04brlcadsachinjain: it's not our requirement, it's you showing us how well you code
13:20.32brlcadwhen you're satisfied that you've shown your ability, submit it
13:21.05sachinjainokie
13:32.20*** join/#brlcad sachinjain (~sachin@117.211.88.150)
13:33.26d_rossbergbrlcad: i've a lot of ideas for if you plan to support a new API, e.g. a NetDatabase which implements the client side and provides an application the same interface as the other Databases in coreInterface
13:34.09d_rossbergthis makes it easy to write client programs for stand-alone and network applications
14:07.31dlomand_rossberg: Didn't mean to cause you alarm.  I'm simply trying to find a way to leverage your coreInterface work for what we need the GeometryService to do.   Cleanup to follow shortly.
14:34.29*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
14:39.56CIA-52BRL-CAD: 03davidloman * r44115 10/rt^3/trunk/ (8 files in 4 dirs):
14:39.56CIA-52BRL-CAD: New approach on getting bu_externals out of coreinterface. last idea broke the
14:39.56CIA-52BRL-CAD: API and encapsulation. Using private methods this time around in a
14:39.56CIA-52BRL-CAD: non-intrusive manner. CoreInterface should be returned to its previous state.
14:45.48d_rossbergdloman: i just got an idea on how to solve all your problems with the coreInterface but the page margin is to small to write it down here ;)
14:46.31dlomanthe approach I just committed involved extending MemoryDatabase with my own class, outside of coreInterface
14:46.52d_rossbergthat's why i will write it in a reply to Sean's mail
14:50.09d_rossbergthe core of the idea was to get the memory out of the memory database, this would be analogous to getten a file from the FileDatabase
14:50.34dlomanrighto, i just want the bytes
14:51.27d_rossbergsending this data over a network and reloading it into a MemoryDatabase would give you the database (or a single element in it) back
14:52.36dlomancorrect.  The only stipulation is that we are not enforcing the need to use a MemoryDatabase object on the other end.  client could be written in another language.
14:53.29d_rossbergbut then you need a specific data format (not black box)
14:54.20dlomancorrect.  We have a protocol defined to transport the data across the network.
14:54.53dlomanin the case of transporting the geometry, the protocol equates to a header + geometrydata.
14:55.12d_rossbergit is not about the protocol, it is the data the client must be able to decipher
14:56.01dlomanokay then.  Is there something incomplete about the data contained in a bu_external?  (something i missed?)
14:57.10d_rossbergyou need BRL-CAD core's C API to decipher bu_external
14:57.39dlomannods, that makes sense :)
14:58.08d_rossbergi.e. at least a part of the client has to be written in C
14:58.41starseekerd_rossberg: unless you want to use asc2g, I don't think we have anything suitable that isn't bu_external for this kind of thing...
14:59.13dlomanI believe there is some java code that can decipher an external, but for the most part yes, use the brlcad libs or implement their own version of them in the language of choice
15:00.32d_rossbergand then you are not far away from reinventing the wheel (now in Java, not C++)
15:00.35starseekerwe could update our database format definition document...
15:01.01starseekerthen there's a spec people can code deserializers to
15:01.27CIA-52BRL-CAD: 03davidloman * r44116 10/rt^3/trunk/tests/CMakeLists.txt: Cmake file for the libGE tests needed to include the BRLCAD include dirs
15:02.13CIA-52BRL-CAD: 03davidloman * r44117 10/rt^3/trunk/tests/libge/CMakeLists.txt: Cmake file for the libGE tests needed to include the BRLCAD include dirs (Missed a file)
15:04.07d_rossbergmy approach would be to have a high level interface to the database in C++ to the programmers with the other languages
15:04.40starseekerthen they still need one or more of our libraries to decode it though
15:04.49*** join/#brlcad adityag (~ADITYA@182.237.144.88)
15:05.42d_rossbergfor a good Java programmer it isn't easy to understand all the rt_~ and bu_~ but it is easy to wrap coreInterface with some Java classes
15:06.16d_rossbergit is simply straight forfard
15:07.53starseekerthat might make it simpler for people to wrap functionality in other languages, but isn't that orthogonal to the question of how to do a language agnostic wire protocol?
15:08.24CIA-52BRL-CAD: 03davidloman * r44118 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Drop filename as its redundant with filePath.
15:08.29d_rossbergor look at my .net example: it requires some typing to write the wrapper but not much thinking
15:09.36d_rossbergi wouldn't call bu_extern language agnostic, it is quit C
15:10.17d_rossbergon the other side, simply reading the messages isn't very useful
15:10.31CIA-52BRL-CAD: 03starseeker * r44119 10/geomcore/trunk/tests/svntest/main.c: grr. Try a different approach to svn changes.
15:10.47dlomanstarseeker: if the network stuff was in the CoreInterface and a 'bunch of other languages' could then use it... in theory at least ;)
15:10.55d_rossbergyou had to reimplement all the knowledge about the elements and their behavior
15:11.45d_rossbergand all this to come out with something veri similar to coreInterface
15:12.13starseekerthat's true for anyone wanting to do a client that doesn't use our libraries though - are you saying bu_external is worse than some other encoding for transporting that information?
15:14.45d_rossbergthe problem is that i have to go now ;} and the yort answer to your question is: yes and no; i'll try to clarify it tomorrow
15:15.10dlomanbah, i *hate* cliff hangers
15:15.15dlomanba-doom ching
15:15.27*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
15:28.19CIA-52BRL-CAD: 03starseeker * r44120 10/geomcore/trunk/tests/svntest/main.c: Get set up to test application of diffs - early results promising
15:37.39*** part/#brlcad sachinjain (~sachin@117.211.88.150)
15:43.22CIA-52BRL-CAD: 03davidloman * r44121 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Fill out protected constructor properly. This cstr is the one that the MinimalDatabase will use to instantiate MinimalObjects
15:48.42CIA-52BRL-CAD: 03davidloman * r44122 10/rt^3/trunk/ (include/MinimalDatabase.h src/libge/MinimalDatabase.cxx):
15:48.42CIA-52BRL-CAD: Add/override Load() and Save() as well as make loading and non loading
15:48.42CIA-52BRL-CAD: constructors. This must be done in order to preserve filename + path in the
15:48.42CIA-52BRL-CAD: MinimalDatabase object. filename and path is required to have so that
15:48.42CIA-52BRL-CAD: MinimalObjects generatedd by this MinimalDatabase have all they required
15:48.42CIA-52BRL-CAD: information to be transmitted across a network
16:16.23CIA-52BRL-CAD: 03davidloman * r44123 10/rt^3/trunk/ (TODO src/libge/MinimalDatabase.cxx): Implement getAllTopObjects(). Inefficient, but quick. Time is of the essence. Added TODO item for tracking purposes.
16:42.37*** join/#brlcad Stattrav (~Stattrav@117.202.21.195)
16:42.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:11.09CIA-52BRL-CAD: 03davidloman * r44124 10/rt^3/trunk/ (3 files in 3 dirs): Implemented getAllObjects(), getAllTopObjects, getAllObjectsBelow(). Updated test to reflect.
17:13.47CIA-52BRL-CAD: 03davidloman * r44125 10/rt^3/trunk/tests/CMakeLists.txt: Remove some debug console printing that accidently made it in.
17:33.07CIA-52BRL-CAD: 03starseeker * r44126 10/geomcore/trunk/tests/svntest/main.c: move things around a bit so we can test whether changes to a .g are actually applied.
17:33.10CIA-52BRL-CAD: 03davidloman * r44127 10/geomcore/trunk/src/GS/ (CMakeLists.txt GeometryProcessor.cxx GeometryProcessor.h): Drop GeometryProcessor. We have the GeometryEngine for this.
17:37.50starseekerwooot!
17:38.11dlomanstarseeker > svn ?
17:40.52*** join/#brlcad Stattrav_ (~Stattrav@117.192.138.254)
17:40.58starseekerkinda
17:42.02starseekerI still can't get svn to do it's diff logic, but as long as individual objects aren't crazy huge it doesn't matter too much - I'm just checking to see whether the in-repository binary contents match the incoming binary contents, and if they don't overwrite the old with the new
17:42.43*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
17:43.08starseekerstill need a refinement in that each object diff is currently its own commit (bad if you just changed 3000 objects) but the proof-of-concept is there
17:43.51starseekerif you take ktank, edit a couple objects and combs and save that as ktank2.g (e.g. keep the original ktank.g too, just edit the copy)
17:44.32starseekeryou can do ./svnTest ktank.g ktank2.g
17:44.40starseekerit will 1. check in all of ktank.g
17:45.02starseeker2.  iterate through ktank2.g comparing objects found there to those in the repository
17:45.19starseeker3.  apply any modifications
17:45.39starseeker4.  re-assemble the repository into GS_staging/ktank.g
17:46.45starseekerstill haven't handled globals yet
17:50.43CIA-52BRL-CAD: 03davidloman * r44128 10/rt^3/trunk/src/libge/CMakeLists.txt: Change where some libge headers get installed to. brlcad/include instead of brlcad/include/brlcad
17:56.27*** join/#brlcad Stattrav (~Stattrav@117.192.145.2)
17:56.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:01.40*** join/#brlcad adityag (~ADITYA@182.237.144.88)
18:06.22*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
18:09.23CIA-52BRL-CAD: 03davidloman * r44129 10/geomcore/trunk/ (8 files in 2 dirs): Add a recursion flag to IDataSource::getObjs() and make the cascading changes.
18:12.16*** join/#brlcad Stattrav_ (~Stattrav@117.192.129.35)
18:12.26CIA-52BRL-CAD: 03davidloman * r44130 10/rt^3/trunk/ (include/MinimalObject.h src/libge/MinimalObject.cxx): Implement helper method: MinimalObject::getFullRepoPath(). This fn combines the path to the .g file, the .g file name and the object's name.
18:13.56kunigamihi, one of my proposals will be on the project "consolidate image processing". the idea is rectoring the code so all individual tools on src/util will be part of a library? if yes, should them be part of image.c or libicv?
18:14.21CIA-52BRL-CAD: 03davidloman * r44131 10/geomcore/trunk/src/libNet/netMsg/GeometryChunkMsg.cxx: Consolidate code by using helper function.
18:18.45kunigami*refactoring
18:24.52CIA-52BRL-CAD: 03davidloman * r44132 10/rt^3/trunk/include/MinimalObject.h: MinimalObject cstr need not be protected any longer. GeometryService classes will need to instantiate MinimalObjects.
18:25.20CIA-52BRL-CAD: 0346.251.64.228 07http://brlcad.org * r2787 10/wiki/User:391_buy_cialis:
18:45.20CIA-52BRL-CAD: 03starseeker * r44133 10/geomcore/trunk/tests/svntest/main.c: refactor logic that gets bu_external from svn file into its own function.
18:53.15starseekerhuh - https://github.com/tpaviot/oce
19:02.53CIA-52BRL-CAD: 03davidloman * r44134 10/geomcore/trunk/ (2 files in 2 dirs): Rename chunk<->ext converters to chunk<->obj converters. Updated implementation for new data types.
19:20.17CIA-52BRL-CAD: 03davidloman * r44135 10/geomcore/trunk/CMake/FindLIBGE.cmake: Forgot to update the libGE search logic.
19:36.32CIA-52BRL-CAD: 03erikgreenwald * r44136 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: Fix readuint64. Return t instead of type for automagically handled packets. Handle disconnect requests. Fix method mapping.
19:39.58*** join/#brlcad sachinjain (~sachin@117.211.88.150)
19:54.13CIA-52BRL-CAD: 03davidloman * r44137 10/geomcore/trunk/src/libNet/netMsg/GeometryChunkMsg.cxx: Worked out a silly allocation bug in GeometryChunkMsg::chunkToObj()
19:56.41CIA-52BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:46.251.64.228]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
20:07.59CIA-52BRL-CAD: 03erikgreenwald * r44138 10/geomcore/trunk/src/interfaces/cl/ (gsserver.asd gsserver.lisp): basic server
20:11.04CIA-52BRL-CAD: 03davidloman * r44139 10/geomcore/trunk/tests/ (GS/CMakeLists.txt libNet/CMakeLists.txt): Fix libs linked.
20:13.35CIA-52BRL-CAD: 03davidloman * r44140 10/geomcore/trunk/ (include/FileDataSource.h src/GS/FileDataSource.cxx): Start wiring up FileDataSource to GeometryEngine
20:16.19CIA-52BRL-CAD: 03davidloman * r44141 10/geomcore/trunk/src/GS/DataManager.cxx: Add a list of strings to use to build a manifest.
20:17.09CIA-52BRL-CAD: 03davidloman * r44142 10/geomcore/trunk/tests/GS/FileDataSourceTest.cxx: Update test with all recent changes
20:17.31kunigami#2 question: I suppose libicv stands for image conversion. I saw there's already a rotation implementation there, so, it the objective provide all sort of transformations such as filter, scaling, threshold?
20:18.30kunigami#3 question: will it contain conversion between different types of image (such as bw and pix)?
20:23.08CIA-52BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2793 10/wiki/User:Bhinesley: /* BRL-CAD Project Proposal */ Updated progress
20:26.04CIA-52BRL-CAD: 0399.125.83.101 07http://brlcad.org * r2794 10/wiki/User:Bhinesley: /* Who I am / Experience */ Reworded
20:33.34CIA-52BRL-CAD: 03starseeker * r44143 10/geomcore/trunk/tests/svntest/main.c: No clue if this is correct, but it compiles so checkpoint
20:37.53*** part/#brlcad adityag (~ADITYA@182.237.144.88)
IRC log for #brlcad on 20110401

IRC log for #brlcad on 20110401

00:03.25*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
00:14.18starseekerto my considerable surprise, that actually seems to have worked
00:26.08CIA-52BRL-CAD: 03starseeker * r44144 10/geomcore/trunk/tests/svntest/main.c: whoops, double free
01:11.32*** join/#brlcad crazy_imp (~mj@a89-182-208-175.net-htp.de)
01:23.40CIA-52BRL-CAD: 03starseeker * r44145 10/geomcore/trunk/src/other/uuid/CMakeLists.txt: This should probably be sleep, not Sleep? need to check
01:24.30CIA-52BRL-CAD: 03starseeker * r44146 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Don't need pkg.h here anymore
01:28.43CIA-52BRL-CAD: 03starseeker * r44147 10/geomcore/trunk/src/ (4 files in 2 dirs):
01:28.44CIA-52BRL-CAD: Start setting up for a library to handle subversion like we need it to be
01:28.44CIA-52BRL-CAD: handled. Lots more to do here that a test program didn't have to worry about -
01:28.44CIA-52BRL-CAD: svn error handling and making sure memory handling is sane are high on the list.
01:36.20CIA-52BRL-CAD: 03starseeker * r44148 10/geomcore/trunk/src/libgeomsvn/breakout.c: Add a few more notes on things that need to be done.
01:42.58*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca)
01:44.40starseekerok, yeah - there's quite a bit of work here
02:01.10CIA-52BRL-CAD: 03starseeker * r44149 10/geomcore/trunk/src/libgeomsvn/breakout.c: There's going to be a fair bit of sanity checking needed...
02:29.16*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
03:03.09*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
03:05.24brlcadkunigami: libicv but they work with image.c (and that file may need to move to libicv)
03:06.34brlcadkunigami: #2 yes
03:07.18brlcadkunigami: #3 yes, that probably being the most important aspect of the library and important to "get it right"
03:08.17brlcadconsiderably time should be allotted to design, review, and critique of the API for libicv (e.g., writing all the headers before any implementation code, having a plan for how to plug in new formats)
03:09.16brlcads/considerably/considerable/!
03:33.48*** join/#brlcad WhiteCalf (MK@2607:f0d0:3001:68::2)
03:34.38brlcadSTUDENTS: you really should try to get draft versions of your applications uploaded to google by friday so mentors can review and comment on them before next week
03:36.17bhinesleyHi, brlcad. I'm working on a proposal for the MGED to Archer Command Migration project. I'm still figuring out how things work, but so far it seems that much of the migration should be pretty straightforward.
03:36.27bhinesleyI'm trying to ascertain what level of detail would be appropriate for the proposal. For the section in which I'm explaining my migration "plan", am I just supposed to tell you what you need to understand what I plan to do, or should I elaborate to show that I know what I'm doing?
03:36.43bhinesleys/am I/should I
03:37.13bhinesley*/
04:22.56brlcad"yes"
04:23.33*** join/#brlcad bhinesley (~bhinesley@adsl-99-30-66-238.dsl.bkfd14.sbcglobal.net)
04:23.40brlcadbhinesley: "yes"
04:24.06bhinesleyyes, I should elaborate?
04:24.07brlcadthe more detail the better but if you like, you can put up what is needed to understand the plan
04:24.21brlcadthen if more detail is needed, someone will ask for it
04:24.53brlcadmore important to have good testable milestons defined
04:25.17bhinesleyOkay, sounds good. By having a draft up tomorrow, do you mean on the wiki or submitted to Google?
04:25.27bhinesleyn/m
04:25.37bhinesleyreread it
04:25.45brlcadyeah, would get it up to google by this point
04:25.54brlcadjust to have the app "in"
04:26.30bhinesleyAlright, thank you, that's all I needed to know.
07:43.44*** join/#brlcad sachinjain (~sachin@117.211.88.150)
08:31.37*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
08:31.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:39.53*** part/#brlcad sachinjain (~sachin@117.211.88.150)
10:06.24*** join/#brlcad crazy_imp (~mj@a89-182-208-175.net-htp.de)
10:37.30*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
11:36.28*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:40.58*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:01.14kunigamihi, one more question: is there any possibility to rewrite image library in c++?
13:19.06brlcadkunigami: can't be rewritten because it's not written yet
13:22.50brlcadkunigami: you'd have to sell your case design-wise, what the benefits would be, what that design would look like
13:23.21brlcadlibicv could be designed with a c++ implementation backend, but the front-end API (i.e., the public headers) needs to provide a pure C interface so C codes don't have to turn into C++ codes during refactoring
13:24.51brlcadthat'd basically be like implementing full libicv in C++, then wrapping the whole library with a C API .. which may or may not actually be beneficial depending on how strong your C and C++ magic are ;)
13:24.53starseekernotes to take a look at this if he needs mph code for C++ someday... https://github.com/sile/mphf
13:26.44brlcadstarseeker: interesting in itself that it's a simple hash container .. might make for a good libbu bu_hash generic bucket container
13:27.00kunigamihmm, perfect. I'll include that as a possibility on my proposal. I think we can delay this decision when designing
13:27.15kunigami... the proposed library
13:29.20brlcadit'd basically be doubling the amount of design work, so it might not be worth it (or doable) for the timeframe given
13:29.53brlcadmost of the time is really going to be spent refactoring and moving code around .. and API design
13:30.31brlcad(better to get a solid design with only one or two concepts refactored than to get a half-assed design with 100 concepts factored in
13:30.47kunigamihaha ok :)
13:31.53kunigamihmm... could you tell me for which reason you want to unit all those stand-alone applications into a single library?
13:32.46kunigamidoesn't it go against the philosophy that programs should do one thing and do it well?
13:58.05``Erikthose programs would still exist, but there's been demand for our image generating tools to output to a variety of formats, and we'd like to reduce the duplication of read/write code
13:58.47``Erik(so pix-png would turn into 'bu_image *b = read_pix; write_png(b);', etc)
14:14.30*** join/#brlcad sachinjain (~sachin@117.211.88.150)
14:18.09*** join/#brlcad adityag (~ADITYA@182.237.144.88)
14:36.18*** join/#brlcad adityag (~ADITYA@182.237.144.88)
14:45.36CIA-52BRL-CAD: 03erikgreenwald * r44150 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: implement reading the file and sending it as a chunk msg
15:12.58kunigamiok, thanks for the clarification
15:15.57*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
16:13.07CIA-52BRL-CAD: 03bob1961 * r44151 10/brlcad/trunk/ (9 files in 2 dirs): Added the dm_reshape function to struct dm. This splits out the bits of code in dm-ogl and dm-wgl that reconfigure the openGL window after a resize.
16:56.48willdyeJob openings at Google!  http://www.google.com/intl/en/jobs/uslocations/mountain-view/autocompleter/index.html
16:57.25willdyeAnd for fans of object-oriented programming: http://blog.mezeske.com/?p=377
17:17.17kunigamiouch, I'm having a bad time with melange auto-formatting "feature" :P
17:27.47kunigamiI've submitted my first proposal. Please, let me know if it's accessible for mentors. Suggestions are mostly welcome :) Thanks
17:38.15*** part/#brlcad adityag1 (~ADITYA@182.237.144.88)
17:47.02CIA-52BRL-CAD: 03starseeker * r44152 10/geomcore/trunk/src/libgeomsvn/ (CMakeLists.txt geomsvn.h repo.c): Checkpoint again - got a ways to go here. Take Sean's suggestion and work on the API/header first.
17:52.44kunigamiI'm working on the proposal of http://brlcad.org/wiki/Vector_output_from_raytracing project.
17:55.24kunigamiIf I understood the information well, it's possible to calculate vector forms from models *with* raytracing
17:58.05kunigami... but not with rtedge not. So an alternative is to interpolate rtedge output into splines since splines would be vector representation. Is that right?
18:28.09*** join/#brlcad Ralith (~ralith@d142-058-173-143.wireless.sfu.ca)
19:03.50CIA-52BRL-CAD: 03bob1961 * r44153 10/brlcad/trunk/ (18 files in 4 dirs): Begin refactoring relevant code in libtclcad and libdm to live in libged.
19:13.48CIA-52BRL-CAD: 03bob1961 * r44154 10/brlcad/trunk/src/libtclcad/ (Makefile.am ged_obj.c tclcad_obj.c): Move ged_obj.c to tclcad_obj.c in libtclcad.
19:13.50CIA-52BRL-CAD: 03starseeker * r44155 10/geomcore/trunk/src/libgeomsvn/geomsvn.h: List out some more possible functions, tweak structures, etc...
19:41.07*** part/#brlcad willdye (~willdye@fern.dsndata.com)
20:03.04*** part/#brlcad sachinjain (~sachin@117.211.88.150)
20:15.24*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
20:24.00CIA-52BRL-CAD: 03erikgreenwald * r44156 10/brlcad/trunk/src/libged/red.c: quell uninitialized variable warning
20:33.08CIA-52BRL-CAD: 03starseeker * r44157 10/geomcore/trunk/src/libgeomsvn/geomsvn.h: Checkpoint again.
20:35.26CIA-52BRL-CAD: 03starseeker * r44158 10/geomcore/trunk/src/ (8 files in 2 dirs): Stake the claim - Geometry Version Management library - libgvm
20:36.27CIA-52BRL-CAD: 03erikgreenwald * r44159 10/geomcore/trunk/ (src/libNet/CMakeLists.txt tests/libNet/CMakeLists.txt): add libge info
20:36.32CIA-52BRL-CAD: 03starseeker * r44160 10/geomcore/trunk/src/libgvm/ (geomsvn.h gvm.h): rename the header before we change anything else (conflicts suck)
20:54.24CIA-52BRL-CAD: 03starseeker * r44161 10/geomcore/trunk/src/libgvm/gvm.h: De-svnify gvm.h
20:58.56CIA-52BRL-CAD: 03starseeker * r44162 10/geomcore/trunk/src/libgvm/gvm_svn.h: Add the specific subversion bits as a private header.
21:02.38CIA-52BRL-CAD: 03erikgreenwald * r44163 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: add info message. fix manifest message off by 1 bug.
21:05.10CIA-52BRL-CAD: 03starseeker * r44164 10/geomcore/trunk/src/libgvm/gvm.h: repository, not svn
21:08.58CIA-52BRL-CAD: 03erikgreenwald * r44165 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: cleanup
21:26.21CIA-52BRL-CAD: 03erikgreenwald * r44166 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: use read-sequence instead of looping with read-byte
21:55.20CIA-52BRL-CAD: 03erikgreenwald * r44167 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: fix warnings, use read-sequence instead of iterating bytes
21:58.26CIA-52BRL-CAD: 03erikgreenwald * r44168 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: fix handshake. use write-sequence instead of looping on write-byte.
21:59.02CIA-52BRL-CAD: 03erikgreenwald * r44169 10/geomcore/trunk/src/interfaces/cl/gsserver.asd: force serial loading, since gsserver depends on gsnet
23:33.09*** join/#brlcad bhinesley (~bhinesley@adsl-99-30-66-238.dsl.bkfd14.sbcglobal.net)
IRC log for #brlcad on 20110402

IRC log for #brlcad on 20110402

00:35.53*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
01:11.19*** join/#brlcad crazy_imp (~mj@a89-182-193-252.net-htp.de)
02:15.47bhinesleyWhew, my proposal is in. Best of luck to you all. I'm taking the rest of the night off.
02:49.13brlcadbhinesley: awesome!
02:49.31brlcadperfect timing too
02:57.24brlcadkunigami: that's sort of the gist ... but not exactly interpolating rtedge output
02:58.09brlcadrtedge shoots a grid of rays, one ray per pixel, keeping track of what is hit
02:59.26brlcadanywhere there are two neighboring rays that hit two different objects, it colors one of the two pixels so an edge is drawn
02:59.47brlcadrepeat over all pixels and you have an edge outline of the model in raster image form
03:00.38brlcadto make a vector image instead of a raster image, you need spline curves, so you're trying to evaluate and "fit" a curve that will match the edges that you detect
03:01.39brlcadyou could use rtedge's output, but that will generally result in a very crappy set of curves unless you shoot a very very dense grid (i.e., a big image)
03:03.22brlcadbetter would be to detect edges at a given resolution, then refine to even higher resolution so you "hone in" on the real edge, then use that for the spline curve control points, trying to find a balance of not too many or too few control points, and producing a vector image within a reliable timeframe
03:11.44starseekerbrlcad: would it be correct to say that the focus for an image conversion library would be on robustness and efficienty rather than covering a lot of formats?
03:16.54starseeker(robustness referring to things like handling very large images without wiping out on ram limitations and dealing with corrupt data...)
03:29.30brlcadstarseeker: my priorities would be on 1) API design, 2) robustness, 3) breadth of support, and 4) performance
03:30.12brlcadit's hard to perform slow image processing, I'm not too worried about that unless it's abysmal :)
03:30.38brlcadgetting the API right is the hardest part that probably deserves a couple solid weeks attention
03:31.33brlcadsurveying and overviewing/reviewing all of the current image processing tools, figure out how they might fit into the API ...
03:31.54brlcadfigure out a way to make the library emminently extensible pluggable
03:32.41brlcadbhinesley: really nice work on your proposal, additional feedback should be sometime this weekend
03:37.09starseekerwas under the impression that handling really large images in low memory situations was something of a problem...
03:40.19brlcadsure, I think every one of our image converters presently assumes the image will fit in-core
03:40.36brlcadif the API is right, then it's just an implementation detail to optimize that later
03:40.47starseekerah, k
03:40.48brlcadwhere you tile and use scratch disks or whatever
03:41.12brlcadwe don't exactly hit that limit very often
03:41.48starseekertrue
03:42.22starseekerguess I'm thinking about it due to those gargantuan scans from the National Archives, but that's a one-off situation
03:43.33brlcadyeah, you scan data that big .. but you rarely render an image that big :)
03:43.58starseekerheh - high res posters ftw
03:44.49brlcadstill if it's done right, then merging in support for a given filter or conversion format could make sure the iterators are all 64bit unsigned ints
03:45.43brlcador at least 32bit unsigned ints .. 4294967295 x 4294967295 is a pretty big image..
04:11.39bhinesleybrlcad: thank you, I look forward to it
04:28.46*** join/#brlcad adityag (~ADITYA@182.237.144.88)
04:36.05*** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net)
05:02.12*** part/#brlcad adityag (~ADITYA@182.237.144.88)
06:50.03*** join/#brlcad adityag (~ADITYA@182.237.144.88)
07:26.02*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
07:34.18*** join/#brlcad adityag (~ADITYA@182.237.144.88)
08:02.22*** part/#brlcad adityag (~ADITYA@182.237.144.88)
08:08.56*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
09:33.10*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
10:39.33*** join/#brlcad adityag (~ADITYA@182.237.144.88)
11:08.43*** part/#brlcad adityag (~ADITYA@182.237.144.88)
12:05.09*** join/#brlcad crazy_imp (~mj@a89-182-193-252.net-htp.de)
14:49.15*** join/#brlcad WhiteCalf (MK@whitecalf.net)
14:52.43*** join/#brlcad ``Erik__ (Here@c-69-140-109-104.hsd1.md.comcast.net)
15:12.09``Erikhuzzah, I has intarwebz again
15:57.52*** join/#brlcad adityag (~ADITYA@182.237.144.88)
16:11.09*** part/#brlcad adityag (~ADITYA@182.237.144.88)
17:22.45starseeker``Erik: do you know of any lisp or scheme implementation that bootstraps itself using only assembly and has no C code?
17:23.42``Erikmost schemes
17:23.49``Erikoh, wait, no C? hrm, no
17:24.18``ErikC is lingua de franca, it's hard to find anything at all that doesn't use it to bootstrap :/
17:24.53``Erikooooold lisp 1.5 is asm only, but for the, uh, ibm 704 and pdp1 iirc
17:25.42``Erikgraham says you can be working with 7 primitives, right? self-bootstrapping shoudln't be TOO hard
17:25.53starseekeryeah, that's why I was wondering if someone had done it
17:26.03starseekermaybe movitz, have to check
17:27.11``Erik(mebbe we shoulda asked sbcl to submit a self-bootstrap to gsoc O.o)
17:27.36starseeker7 primitives is very basic though - don't know if you can get to threads or system file io stuff with that...
17:27.39starseekerhehe
17:28.15starseekeris goofing off by digging around the whole "minimal bootstrap, literate lisp" thing again
17:29.26starseekertwo most interesting sources so far are the islisp spec (which unlike ANSI is explicitly public domain, albeit quite a bit smaller) and sacla
17:29.47``Erikgiven that on most os's, any syscall is a C function, I don't know how well you'll do avoiding C without working directly on the metal
17:30.14starseekerwhat about writing directly in assembly?
17:30.40``Erikdoable, if you happen to match the kernels call convention... which can be tricky
17:31.18``Erikmy brainfuck compiler to asm has "if mac, do this, if bsd, do this, if this version of linux, do this, if that versino of linux, do that..."
17:31.56starseekerhmm
17:32.20``Erikmost of that is just frontmatter... generally, it breaks down to unix/bsd/mac style vs linux/dos style... but there're still gotchas
17:32.43``Erik(yes, linux is closer to dos than unix at that level.)
17:32.48starseekerow
17:34.31starseekerhuts for old lisp 1.5 sources...
17:34.46``ErikI got mine at the simh site
17:39.59starseekerhah - no license info though http://www.softwarepreservation.org/projects/LISP/lisp1.5/
17:41.06starseekerthis one still has unisys propritary notes on it:  http://www.frobenius.com/source.htm
17:52.55starseekerah:  ftp://ftp.informatimago.com/pub/free/develop/lisp/lisp15-0.0.2.tar.gz
17:54.04starseekerprobably would have to check with MIT, but that might be usable...
18:11.03starseekerhmm.  http://c2.com/cgi/wiki?LispImplementationsWrittenInLisp
18:40.53kunigamibrlcad: thank you for the clarification. I couldn't get a draft of the proposal. I'm considering focusing in the two other proposals I've submitted.
20:13.47CIA-52BRL-CAD: 0399.30.66.238 07http://brlcad.org * r2795 10/wiki/User:Bhinesley: GSoC proposal information removed (has been submitted)
20:25.19*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
20:25.43AbhijitKaneI've submitted a draft proposal on the GSOC website.
21:40.23kunigamihi, is there some reference on rt stand-alone usage? I've seen mged reference, but I'm confused with rt, specially with defining the objects. thanks!
21:44.40*** join/#brlcad Ralith (~ralith@d142-058-173-143.wireless.sfu.ca)
22:21.28*** join/#brlcad Ralith (~ralith@d142-058-173-143.wireless.sfu.ca)
22:21.50kunigamisorry, I was too hasty in asking that. I found a lot of documentation in brlcad/doc/.
22:24.04brlcadnp
23:28.36*** join/#brlcad dassouki (~ahmed@142.167.162.112)
23:29.39dassoukithis might seem like a silly question, but where can I find sets of plans for architecture related projects
23:29.42dassoukilike full projects
23:51.11*** join/#brlcad dassouki (~ahmed@142.167.162.112)
IRC log for #brlcad on 20110403

IRC log for #brlcad on 20110403

00:48.14*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
01:08.39*** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
01:11.07*** join/#brlcad crazy_imp (~mj@a89-182-205-145.net-htp.de)
01:33.14brlcaddassouki: I've heard about this place called the internet, there might be some plans there
02:22.03dassoukibrlcad: I've heard of that place too but can't find any architectural full sets ..
04:24.00*** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net)
04:52.53*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
05:36.19*** join/#brlcad adityag (~ADITYA@182.237.144.88)
08:33.54*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
08:37.01*** part/#brlcad adityag1 (~ADITYA@182.237.144.88)
09:25.23*** join/#brlcad adityag (~ADITYA@182.237.144.88)
09:28.44*** join/#brlcad adityag (~ADITYA@182.237.144.88)
10:56.35*** part/#brlcad adityag (~ADITYA@182.237.144.88)
13:53.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:15.21*** join/#brlcad kunigami1 (~kunigami@187.106.4.220)
14:35.30*** join/#brlcad adityag (~ADITYA@182.237.144.88)
15:16.38*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
15:17.45*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
15:18.53adityag1brlcad : can i submit the application today ?
15:49.39brlcadadityag1: yes, the sooner the better
16:02.30*** join/#brlcad AbhijitKane (~Abhijit@111.93.5.194)
17:26.39CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2796 10/wiki/MGED_Commands: /* B */
17:31.11CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2797 10/wiki/MGED_Commands: /* C */
17:36.22CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2798 10/wiki/MGED_Commands: /* D */
17:37.46CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2799 10/wiki/MGED_Commands: /* D */
17:40.40CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2800 10/wiki/MGED_Commands: /* E */
17:42.12CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2801 10/wiki/MGED_Commands: /* F */
17:47.40CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2802 10/wiki/MGED_Commands: /* G */
17:48.24*** part/#brlcad adityag1 (~ADITYA@182.237.144.88)
17:50.26CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2803 10/wiki/MGED_Commands: /* L */
17:54.03CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2804 10/wiki/MGED_Commands: /* M */
18:21.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:37.21CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2805 10/wiki/MGED_Commands: /* N */
18:39.40CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2806 10/wiki/MGED_Commands: /* P */
18:42.50CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2807 10/wiki/MGED_Commands: /* Q */
18:52.12CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2808 10/wiki/MGED_Commands: /* R */
18:55.55CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2809 10/wiki/MGED_Commands: /* S */
18:57.41CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2810 10/wiki/MGED_Commands: /* U */
19:29.21*** join/#brlcad Stattrav (~Stattrav@117.192.130.12)
19:29.21*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:29.39*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:35.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:52.26CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2811 10/wiki/MGED_Commands: /* R */
19:53.43CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2812 10/wiki/MGED_Commands: /* D */
19:56.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:02.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:37.53kunigami1hi, I learning to use the rt tool and noticed that when using incremental mode (-i), the image is not saved if we specify output. I know it doesn't make sense to use incremental mode if we're not visualizing the output, but is this behaviour expected? Would be bad if we just ignore flag -i whenever -o is specified?
22:15.49CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2813 10/wiki/MGED_CMD_closedb: Initial import from markhobley.yi.org
22:49.08*** join/#brlcad juanman (~quassel@201.255.61.144)
22:49.18*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
22:52.40CIA-52BRL-CAD: 03Markhobley 07http://brlcad.org * r2814 10/wiki/MGED_CMD_dbversion: initial import from markhobley.yi.org
23:53.10*** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net)
23:54.07*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20110404

IRC log for #brlcad on 20110404

00:06.54*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
00:38.22*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
00:38.43*** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201)
00:39.38*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
01:11.52*** join/#brlcad crazy_imp (~mj@89.182.223.38)
02:55.29*** join/#brlcad vtts_ (~vytautas@diz.ktu.lt)
02:55.51*** join/#brlcad piksi (piksi@pi-xi.net)
03:01.45*** join/#brlcad kanzure_ (~kanzure@bioinformatics.org)
03:01.45*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
03:01.45*** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201)
03:01.45*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
03:01.45*** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ)
03:04.51*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
03:44.43*** join/#brlcad ibot (~ibot@rikers.org)
03:44.43*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011 Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011
04:04.54*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
04:06.15*** join/#brlcad kanzure__ (~kanzure@bioinformatics.org)
04:07.11*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
04:07.17*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
04:20.17*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
04:38.50*** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net)
05:43.33*** join/#brlcad adityag (~ADITYA@182.237.144.88)
07:00.00*** join/#brlcad adityag (~ADITYA@182.237.144.88)
07:25.28*** join/#brlcad adityag (~ADITYA@182.237.144.88)
07:25.57*** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net)
07:46.25*** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net)
08:23.38*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
08:23.38*** join/#brlcad CIA-105 (~CIA@208.69.182.149)
08:23.38*** join/#brlcad dtidrow__ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
08:23.38*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
08:23.39*** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net)
08:23.39*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
08:23.39*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
08:23.39*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
08:23.39*** join/#brlcad kanzure__ (~kanzure@bioinformatics.org)
08:23.39*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
08:23.39*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
08:23.39*** join/#brlcad piksi (piksi@pi-xi.net)
08:23.39*** join/#brlcad vtts (~vytautas@diz.ktu.lt)
08:23.39*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
08:23.39*** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net)
08:23.39*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
08:23.39*** join/#brlcad WhiteCalf (MK@whitecalf.net)
08:23.39*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
08:23.39*** join/#brlcad yiyus (1242712427@je.je.je)
08:23.39*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
08:23.39*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
08:23.39*** join/#brlcad hyarion (c05ben@peppar.cs.umu.se)
08:23.39*** join/#brlcad kanzure (~kanzure@131.252.130.248)
08:23.39*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
08:23.39*** join/#brlcad ChanServ (ChanServ@services.)
08:23.39*** mode/#brlcad [+o ChanServ] by verne.freenode.net
08:45.14*** join/#brlcad adityag (~ADITYA@182.237.144.88)
09:11.20dlomanreads GSOC proposals.....
09:17.18dlomanWhoa, a Head System Admin for a university doesn't know what IRC is?  oh dear.....
09:35.05*** join/#brlcad adityag (~ADITYA@182.237.144.88)
09:37.36dlomanokay, now that's done.
09:37.39dlomaninteresting reads
09:39.14dlomanneeds about 10 more cores in my laptop :)
09:44.00*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
09:44.41*** join/#brlcad vtts (~vytautas@diz.ktu.lt)
09:45.06*** join/#brlcad yiyus (1242712427@je.je.je)
10:46.35kunigamihi, any comments on my proposals? thanks :)
10:47.46CIA-105BRL-CAD: 03davidloman * r44170 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: GSConnection need not extend Thread. Limits implementation and restricts the end user's design.
10:51.56CIA-105BRL-CAD: 03davidloman * r44171 10/geomcore/trunk/src/interfaces/java/test/org/brlcad/geometryservice/ (LoginTest.java SerialTest.java UUIDSerialResearch.java): Add in some tests and research. These were created some time ago but were never committed.
10:53.34CIA-105BRL-CAD: 03davidloman * r44172 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Update for starting of worker thread.
11:06.46dlomankunigami: other than the lisencing issues starseeker mentioned, I'd offer the idea of providing a detailed list of the standalone apps you are consolodating.
11:07.41kunigamiok! could you confirm that my proposal for 'shader enhancements' is visible for you?
11:08.23*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
11:08.33dlomani can see it yes.
11:09.19kunigamiok, thanks. I'll edit my proposal ASAP
11:10.34dlomana detailed list of apps provided in the begining gives you a better way to gauge your progress and, overall, helps to more definitively determine success or not.
11:10.38dlomanjust an idea
11:12.00kunigamiperfect, I agree
11:13.09*** join/#brlcad kasuga5 (~kasuga5@wlnt-02-042.dsl.netins.net)
11:37.36*** join/#brlcad kasuga5_ (~kasuga5@wlnt-02-042.dsl.netins.net)
11:40.16*** join/#brlcad adityag (~ADITYA@182.237.144.88)
11:43.36*** join/#brlcad sachinjain (~sachin@117.211.88.150)
11:56.21*** part/#brlcad sachinjain (~sachin@117.211.88.150)
11:57.56*** part/#brlcad adityag (~ADITYA@182.237.144.88)
12:17.08*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:33.25CIA-105BRL-CAD: 03brlcad * r44173 10/brlcad/trunk/src/libged/screengrab.c:
12:33.25CIA-105BRL-CAD: identify that this is a major encapsulation problem. this introduced a new
12:33.25CIA-105BRL-CAD: dependency on libdm/libfb, which totally sucks and blows library encapsulation.
12:34.55CIA-105BRL-CAD: 03brlcad * r44174 10/brlcad/trunk/src/libged/Makefile.am: gah, as expected, this introduced a new dependency. regression fail. maybe need a test to prevent this from occurring on all the core libraries (making calls to libraries that shouldn't be linked.
12:39.43brlcadis really in disbelief ... seriously? there shouldn't have to be training wheels to prevent this sort of crap coding
12:52.01CIA-105BRL-CAD: 03brlcad * r44175 10/brlcad/trunk/TODO: cliff added support for name changes on red (needs NEWS). still need to indep test matrix edit. more importantly, need to undo the mess added to libged.
12:59.28``ErikO.o
13:08.44brlcadwonders how libged is even compiling without a libdm link, is it all really header macros?
13:10.01brlcadbegs for further separation of include into subdirs, so you can't get away with this so easily
13:10.56``Erik<-- has always been a fan of keeping the headers with the source, src/libbu/bu.h etc
13:11.13brlcadbut then you can't distinguish public from private
13:11.53brlcadat least without making it stupid obvious like bu_private.h or bu_don_t_use_me.h
13:11.58*** join/#brlcad adityag (~ADITYA@182.237.144.88)
13:12.06``Eriknot without having a convention in naming or looking at the .am, but *shrug* hasn't bothered me
13:12.31brlcadthen someone just renames the file or worse, just includes it
13:12.45``Erikheh, tieprivate.h librt_private.h ged_private.h :D
13:13.02brlcadexactly, taking double measures to make it stupid obvious
13:13.29``Erikso what're you thinking, include/bu/bu.h ?
13:13.43brlcadand how many of those are STILL bing included where they shouldn't be  .. #include "../librt/librt_private.h"
13:14.52``Erik*ponder* #ifndef BUILDING_LIBRT #error "Stopit." #endif
13:15.17brlcadyeah, exactly that, then adding include/bu to the cppflags so "bu.h" still works, maybe BU_CPPFLAGS
13:15.51brlcadmight have to do something that obtuse really
13:16.37brlcadseriously, I totally expect better .. that sort of training wheels shouldn't be needed
13:17.55brlcadthere's only one or two commiters that might not know better and they're not even the ones doing this
13:20.23CIA-105BRL-CAD: 03brlcad * r44176 10/brlcad/trunk/TODO: need to group together library headers into public subdirs. will need to set up proper cppflags as well similar to the LIBS flags.
13:21.07``Erikknow anything about, uh, .dot and graphviz? I wonder if we could use the DEPENDS line to generate a map
13:21.40CIA-105BRL-CAD: 03brlcad * r44177 10/brlcad/trunk/TODO: help cliff not go bald.
13:21.42``Erik(assuming that line is generally correct... it's manual, so it does get out of sync on occasion)
13:21.56brlcadyes, I used graphviz to visualize the CSG graph before .. pretty awesome for small models
13:22.17brlcadhad a g-dot script I wrote up (didn't commit it)
13:22.24brlcadhavoc was insane
13:23.00brlcada graphviz of the libs would be interesting
13:23.05``Erikso when is the cmake merge? I've been using his branch on fbsd mac and win32 without issue
13:23.17brlcadafter release
13:23.38brlcadwhich was today, but now have to undo bob's junk and mabye move screengrab
13:27.54CIA-105BRL-CAD: 03brlcad * r44178 10/brlcad/trunk/TODO: if we do the subdir, then there's risk of people going lazy and including via subdir. add a regression to make sure it's clean code using CPPFLAGS.
13:36.16CIA-105BRL-CAD: 03brlcad * r44179 10/brlcad/trunk/ (10 files in 2 dirs): (log message trimmed)
13:36.16CIA-105BRL-CAD: I get it. It was an April Fool's Joke, right?? Revert to r44152 since it makes
13:36.16CIA-105BRL-CAD: all sorts of calls to LIBDM macros and the dm struct, requires libdm header.
14:04.00*** part/#brlcad adityag (~ADITYA@182.237.144.88)
14:04.33``Erikahm, that commit removed struct tclcad_obj, which is flipping out libtclcad/tclcad_obj.c
14:14.50brlcadhrm,k
14:15.35brlcadah, I apparently wasn't up to date
14:17.59brlcadnow to hunt down a couple tires before I blow out my slicks
14:18.18``Erikheh, noticed that :) I need to order a full set, myself :/
14:20.17CIA-105BRL-CAD: 03brlcad * r44180 10/brlcad/trunk/src/libdm/ (Makefile.am adc.c axes.c grid.c labels.c rect.c scale.c): rest of revert to r44152. helps to be fully up-to-date during merge. continuation of r44179.
14:27.52CIA-105BRL-CAD: 03bob1961 * r44181 10/brlcad/trunk/src/libged/ged.c: typo in comment
14:39.51CIA-105BRL-CAD: 03Erik 07http://brlcad.org * r2815 10/wiki/NetMsgTypes: add bot geometry request
14:45.27CIA-105BRL-CAD: 03erikgreenwald * r44182 10/geomcore/trunk/ (3 files in 3 dirs): add GeometryBoTReqMsg
14:53.03CIA-105BRL-CAD: 03erikgreenwald * r44183 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp gsserver.lisp): add geombotreqmsg
15:18.34Raliththere's a CL API? awesome
15:19.17``Erikit's just me dorking around with the protocol, it's a keen test bed :)
15:24.15CIA-105BRL-CAD: 03erikgreenwald * r44184 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: break the connection loop out so it can be updated with a live session going
15:25.25*** mode/#brlcad [+o brlcad] by ChanServ
15:58.49dlomanfeels like garbage. might have to take the rest of the day as leave ....
16:10.40*** join/#brlcad adityag (~ADITYA@182.237.144.88)
16:27.54brlcadkunigami: which of those two proposals is your main interest?
16:31.13kunigamibrlcad: I prefer shader enhancement!
16:31.42brlcadoh really?
16:31.51brlcadwouldn't have guessed that from the proposals :)
16:32.06brlcadyou plan on filling out the rest of the details you'd left out then?
16:32.38kunigami:P I think I mentioned somewhere on "shader enhancement" that this one would have the greatest priority. let me check
16:33.13brlcadyou may have, hadn't gotten to reading it word-for-word yet
16:34.09kunigamihmm ok. And yes, I'm planning to filling out the details. I just wanted to submit the draft for possible reviews. I've been studying rt's code this weekend and I already learned something to add on there :)
16:34.33brlcadas they currently stand written, at a glance, the image processing is much more clearly composed with goals, scope, integration, plan of attack, etc
16:34.41brlcadokay, good to know
16:36.26kunigamioh yes, I had a much clearer idea on what to do on image processing. I think I had the necessary knowledge to write the proposal. For the shader enhancement one, I have some research to do yet :)
16:37.57kunigamibut anyway, I think that the shader enhancement is more challenging. Since I'm not sure if will be able to write a compelling proposal for this one, I also did one for the image processing.
16:40.07brlcadit definitely is more challenging :)
16:40.47brlcadso part of the reason is so that we scope to the summer timeframe accordingly so you can actually make progress and enjoy what you're working on :)
16:41.33brlcadwouldn't want you to get accepted to work on a hard task and then spend all summer flailing about in liboptical not making any progress, getting frustrated in a sea of code :)
16:42.05brlcadyou won't likely keep working on that code after the money stops, and that's not something either of us benefits from :)
16:47.53brlcadbhinesley: comments posted
16:50.40kunigamihmm my idea was actually to keep working (there are a couple of other rt-related projects that I got interested), but unfortunately I don't know how will be my time after I finish my masters.
16:51.23kunigamibut let us see what can I offer until the end of the week so you can better judge if I'll be able to do that in a summer
16:52.52brlcadapplication deadline is friday so we'll have the following two weeks to review and elaborate
16:55.03kunigamicool! I din't notice that during after deadline we could add further details to the proposal!
16:56.05brlcadit's supposed to be more to elaborate, but yes -- there is still some time to elaborate but at that point it should be in response to our questions
16:56.49brlcadI wouldn't bank on it -- your proposal should be substantially "done" (i.e. fully written) by Friday from your perspective
16:57.18brlcadno telling what sort of restrictions the new google-melange interface may impose after the deadline
16:59.00kunigamihmm ok!
17:03.53CIA-105BRL-CAD: 03erikgreenwald * r44185 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: Enable multi-threading. New 'stop' function. Hoist session loop. Use specified dir for geometry instead of cwd.
17:05.22brlcadkunigami: have you read the shaders presentation?
17:05.30brlcadit's on the website somewhere
17:15.42brlcadkunigami: in order to get a quick grasp on shaders for your proposal, I'd recommend taking the following steps:
17:15.59*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
17:16.04brlcad1) download http://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf and perform at least lessons 1 through 4
17:17.31brlcad1a) through lesson 7 to get to some basic (phong) shader options
17:17.41brlcad2) download and read http://brlcad.org/w/images/2/2c/Optical_Shaders.pdf
17:19.01brlcad3) download and read appendix B in  http://brlcad.com/downloads/documentation/BRLCAD_VolumeIII.pdf
17:22.29brlcadthat should give a pretty good survey of what's presently available, should help reading the code
17:23.25kunigamiwow, thanks for the links! I'll surely read them! I've already taken exactly lessons 1 to 4 on /doc/lessons and learned how to use the basics of mged and rt :) I'll read the other ASAP
17:24.14CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2816 10/wiki/Shader_Enhancements: add documentation references
17:26.21brlcadthe shaders are unfortunately some of our least documented portions of the code (because being a content modeling and rendering system are completely secondardy concerns)
17:27.06brlcadthat said, we have support for quite a lot .. some of more hacked and research quality than other portions, but most all working for a specific purpose at some point in time
17:29.01brlcadOSL has the ability to replace our current shader string with a more formal and descriptive shader parameterization, with the description living as either as a new database object or keeping the string and passing through to a new liboptical shader
17:30.41kunigamihmm interesting
17:31.36brlcadshader objects are the way to go :)
17:31.49brlcadhow to deal with them is the bigger question
17:36.44*** part/#brlcad adityag1 (~ADITYA@182.237.144.88)
17:45.33*** join/#brlcad sachinjain (~sachin@117.211.88.150)
17:46.07dlido we still need openNURBS then?
17:46.16brlcadwhat?
17:48.07dlibrlcad or you mean shader is only for displaying, ray-tracing.
17:48.37brlcadshaders only pertain to optics, displaying geometry via raytracing
17:49.26dlibrlcad, I was thinking to save all internal geometry as shaders and leave some computation to GPU
17:49.50dlithat sounds too ambitious anyway
17:50.28brlcadI'm not sure you're using the same terminology or there is a big misunderstanding of some concept
17:50.38brlcad"I don't think that means what you think it means" :)
17:51.40dlibrlcad, don't worry, I don't understand the 'shader' part anyway
17:51.47brlcadeven if you're thinking of a GPU shader, you still have to have a geometric representation that goes with it
17:52.07brlcadshading merely answers "how" to draw .. not what
17:52.09dlomandli: How many fingers do you have on your right hand?
17:52.23brlcadsix!
17:52.36dlomanegads.
17:52.42dli101
17:53.43brlcaddli: speaking of 101, http://en.wikipedia.org/wiki/Shader ;)
17:54.24brlcador even better, http://en.wikipedia.org/wiki/Shading
17:55.32dlibrlcad, I thought shader also includes manipulating objects
17:55.48brlcadyou have to have objects to manipulate in the first place
17:55.55CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2817 10/wiki/Shader_Enhancements:
17:56.16CIA-105BRL-CAD: 03erikgreenwald * r44186 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp gsserver.lisp): fix off by one weirdness in chunk request
17:56.21brlcadand it doesn't modify the object, it only modifies how it's displayed
17:57.55dlibrlcad, thanks
18:04.33CIA-105BRL-CAD: 03erikgreenwald * r44187 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: remove packet type display
18:04.55CIA-105BRL-CAD: 03erikgreenwald * r44188 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp): fix malformed expressions
18:06.28*** join/#brlcad adityag (~ADITYA@182.237.144.88)
18:09.03*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
18:21.34bhinesleybrlcad: cool, I responded
18:21.50brlcadbhinesley: do you get e-mail notification?
18:22.02bhinesleybrlcad: oops, not to you. page must have cached...
18:22.15bhinesleyno, how do I enable that? I was looking everywhere...
18:23.47brlcadI just mean if we post a comment, do they notify you
18:23.49brlcadmight not be a feature
18:24.04brlcadwas in the past, but it's a new interface this year
18:24.04bhinesleyunfortunately, they don't
18:24.10brlcadk
18:25.34bhinesleyit seems like setting up a end-user editable plain text file with command aliases might not be a bad idea
18:25.57bhinesleynot for the project, but in the future
18:26.47brlcadusers can (and do) do that now with their .mgedrc file
18:27.07bhinesleyoh alright, I had no idea (obviously)
18:27.14brlcadit would be nice to formalize that into specific packages, though
18:27.28brlcadit's basically akin to using the alias command and your .profile now
18:28.09bhinesleyah
18:28.15brlcadmore useful would be command alias "packages" for things like "legacy mode commands", "dwayne's extensions", etc
18:28.36starseekerthinks that's the way to go if we "clean up" our existing commands - a "legacy.tcl" file or some such
18:29.33brlcadthey should register as plugins, though, and then get enabled via the options gui
18:30.13brlcadso we can ship multiple configurations that you can just checkbox on/off, or they can toss in their own subdir into an install or homedir and get listed too
18:30.25bhinesleythat sounds good
18:30.32bhinesleyis it just the alias token, or is there a way to change the default command names?
18:30.48brlcadthere's a way to change the default names
18:31.02bhinesleyokay, that's what I was getting at
18:31.08brlcadso in theory these packages could override everthing
18:31.27bhinesleysounds like a good GSoC project ;)
18:31.43brlcadgetting libged cleaned up is more important right now :)
18:31.48bhinesleysure
18:32.18brlcadthat establishes the command baseline, one reusable across applications
18:32.48bhinesleyyeah, I see that it makes sense to do that first
18:33.53brlcadthat gets at the command registration I was referring to in my comment, so commands would register themselves with libged as an extension of the library, describe their capability, implement functionality -- then each command would get mapped to one or more names for scripting purposes, various GUI widgets, and into the help system
18:35.48bhinesleythat would be ideal
18:35.54bhinesleyhighly modular
18:36.12brlcadthat's the long-term goal
18:36.27brlcadso lots of cleanup, LOTS of refactoring to get there
18:37.54bhinesleyso the idea is to keep things as contained as possible, for now
18:38.05bhinesley?
18:38.22brlcadwhat do you mean?
18:38.39brlcadthe idea is to move towards that completely modular goal :)
18:39.20CIA-105BRL-CAD: 03starseeker * r44189 10/brlcad/branches/cmake/ (19 files in 6 dirs): MFC r44188
18:39.25brlcadgetting the command logic all in one place, making the two main apps (archer and mged) call through to libged to get at that command -- ideally without being aware of that command directly
18:41.57*** join/#brlcad Ralith (~ralith@d142-058-173-143.wireless.sfu.ca)
18:42.03*** join/#brlcad sachinjain (~sachin@117.211.88.150)
18:42.07bhinesleyI thought that you were implying that these capabilities were not yet possible
18:42.54bhinesleynevermind...
18:47.55CIA-105BRL-CAD: 03starseeker * r44190 10/brlcad/branches/cmake/src/libtclcad/CMakeLists.txt: Update libtclcad CMakeLists.txt file
18:48.02brlcadwhich is where your gsoc proposal comes in ..
18:48.58brlcadyou can override commands and do things to them now, but there's no system in place for managing them and the commands are listed all over the place
18:50.05CIA-105BRL-CAD: 03starseeker * r44191 10/brlcad/branches/cmake/src/libtclcad/CMakeLists.txt: Ah, right - add tclcad_obj.c
18:50.44kunigamibrlcad: I commented on your question about my time during the summer. Could you see what do you think? thanks
18:59.24bhinesleybrlcad: at this point, I would feel more comfortable starting with the command migration. Perhaps after the GSoC I could take on the goal of highly modular commands.
19:01.45brlcadkunigami: sure, it'll be a while though
19:02.08brlcadbhinesley: fair enough -- even working on command migration is moving towards modular commands
19:09.57sachinjainbrlcad : how to upload a patch on sourceforge
19:11.37brlcadsachinjain: I suggest searching the web, there are LOTS of tutorials on how to create a patch using subversion, and how to upload to our patches tracker should be outright obvious (search for it)
19:16.21CIA-105BRL-CAD: 03bob1961 * r44192 10/brlcad/trunk/ (include/ged.h include/tclcad.h src/libtclcad/tclcad_obj.c): Mods to get libtclcad compiling again.
19:27.20bhinesleybrlcad: okay, comment posted now. I'm leaving for class.
19:27.26CIA-105BRL-CAD: 03starseeker * r44193 10/brlcad/branches/cmake/ (include/ged.h include/tclcad.h src/libtclcad/tclcad_obj.c): MFC r44192
19:30.09CIA-105BRL-CAD: 03starseeker * r44194 10/geomcore/trunk/src/libgvm/gvm.h: Add a few more possible gvm header entries.
19:30.13*** join/#brlcad adityag (~ADITYA@182.237.144.88)
19:34.09*** part/#brlcad sachinjain (~sachin@117.211.88.150)
19:44.09CIA-105BRL-CAD: 03starseeker * r44195 10/geomcore/trunk/src/libgvm/gvm.h: will probably want to populate lists from repositories to have an easy format to send over the wire.
19:49.52*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
20:08.33*** join/#brlcad adityag (~ADITYA@182.237.144.88)
20:25.25starseekerwonders wy db_update_ident is used to update both title and units - why not just one function for title and another for units? or even just have _GLOBAL use normal bu_avs pairs?
20:33.50starseekeror does it...
20:33.51starseekerhmm
20:36.55brlcad_GLOBAL is just an attribute object
20:38.10CIA-105BRL-CAD: 03erikgreenwald * r44196 10/geomcore/trunk/src/interfaces/cl/ (brlcad.asd brlcad.lisp): start up a cffi wrapper for librt
20:38.27brlcaddb_update_ident() is historic behavior, combining title and units together was that way in all previous db versions iirc
20:39.14brlcadmaybe even to reduce two i/o operations to one, but only speculative
20:39.47*** part/#brlcad adityag (~ADITYA@182.237.144.88)
20:39.48brlcadseparating them would make sense now
21:02.12*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
21:02.12*** join/#brlcad yiyus (1242712427@je.je.je)
21:02.12*** join/#brlcad CIA-105 (~CIA@208.69.182.149)
21:02.12*** join/#brlcad kanzure__ (~kanzure@bioinformatics.org)
21:02.12*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
21:06.01CIA-105BRL-CAD: 03erikgreenwald * r44197 10/geomcore/trunk/src/interfaces/cl/brlcad.lisp: Fix magic sizes (this may be a bug in librt?). Fix up the rt-open func.
22:46.38CIA-105BRL-CAD: 03bob1961 * r44198 10/brlcad/trunk/src/libged/title.c: Should be using local2base instead of base2local here.
23:45.37*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20110405

IRC log for #brlcad on 20110405

00:30.13starseekerWoot!
00:30.20starseekernow has 3 Neo1973 phones
01:11.30*** join/#brlcad crazy_imp (~mj@a89-182-208-247.net-htp.de)
02:03.50*** join/#brlcad sachinjain (~sachin@117.211.88.150)
02:27.04*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
02:46.18*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca)
03:22.50*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
03:58.55brlcadstarseeker: haha
04:49.44*** join/#brlcad adityag (~ADITYA@182.237.144.88)
04:50.07*** part/#brlcad adityag (~ADITYA@182.237.144.88)
05:57.41*** join/#brlcad sachinjain (~sachin@117.211.88.150)
06:04.45*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
06:39.26*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:39.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:10.42*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
09:00.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:03.59*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
10:29.15dlomanMernin all
10:36.32kunigamigood morning
10:38.54``Erikyargh
10:49.23dlomanso hows the lisp thing going =D
10:58.01``Erikawesome, files are moving back and forth, etc
10:58.54``Erikthe next trick is tesselating geometry to send out on the fly, which is the brlcad.lisp shtuff (which'll also do images, wireframes, parts of files, etc)
10:59.25dlomanare there svn libs for lisp?
10:59.57``Erikprobably, but cffi is quick and easy to write, way nicer than jni
11:00.55dlomankewl
11:02.15``Eriklibrt is very macro and struct heavy, so it's tricky to interface it :/ almost temped to write getter/setter type funcs for some of the librt stuff :D
11:02.36dloman...write it in what language?
11:02.56``ErikC, in raytrace.h
11:03.12dlomani'd say go for it :)
11:03.28``Erikrt_set_ray(point_t origin, vect_t dir); etc
11:03.40``Eriker, with an application sturct somewhere in there
11:12.56CIA-105BRL-CAD: 03davidloman * r44199 10/geomcore/trunk/ (2 files in 2 dirs): Add in an optional replyMsg arg to the objToChunk converter
11:22.39CIA-105BRL-CAD: 03davidloman * r44200 10/geomcore/trunk/src/GS/FileDataSource.cxx: Oops, forgot to commit FileDataSource::getObjs() ! It's implemented.
11:23.31CIA-105BRL-CAD: 03davidloman * r44201 10/geomcore/trunk/src/GS/DataManager.cxx: Cleanup/fixup DataManager::handleGeometryReqMsg. Now uses the shiney, new, and improved FileDataSource.
11:29.27CIA-105BRL-CAD: 03davidloman * r44202 10/geomcore/trunk/src/GS/GeometryService.cxx: Make GeometryService objects route GEOMETRYMANIFEST NetMsg's to the Datamanager
11:41.25CIA-105BRL-CAD: 03davidloman * r44203 10/geomcore/trunk/ (3 files in 3 dirs): Stub in GetCmd (client cmd) for getting geometry from server.
12:16.25dloman``Erik: whats with the GeometryBotReqMsg ?
12:17.04dlomanlook identicle to GeometryReqMsg
12:17.18``Erikso far, eventually it should tesselate the geometry into an inmem db and send that
12:17.41``Erikto feed ogl, isst, vsl, etc
12:18.23dlomanwhy is a *Msg doing any work other than serialization and deserialization?  tesselation is the job of the GE... isn't it?
12:19.19``ErikI d'no how ya have things wired up, I was just mimicking what I saw :D I imagine the msg would have to ask ge for a facetized version, no?
12:20.12dlomanperhaps, but that's not the way the gs is architected.
12:21.11``Erikokie, it's hard to read through all that inheritance, d'no where exactly it should fit... I just figured I'd put SOMETHING there so you could fix it up later :D
12:21.14dlomansome function being executed by some thread would 1) get the geometry from the DataManager, 2) use the GE to tesselate it and 3) make a GeometryManifest/Chunk to send the results to the requestor.
12:21.22dlomankk
12:21.40dlomanthere isn't that much inheritance :)  Nothing compared to stuff like QT and Boost.  heh.
12:21.47dlomanthose make me cry
12:21.58``Erikat least they're documented :>
12:22.16dloman:P  They're also stable and released
12:23.41dloman..weren't created by one person, weren't created by someone doing their first soft dev project, etc, etc.
12:23.46dlomanthe list is long.
12:24.05``Erik(and the only machine I have with doxygen can't configure geomcore :/ )
12:24.21dlomancmake fails?
12:24.36``ErikFindBRLCAD.cmake can't see the (system) tcl
12:25.14dlomanbummer
12:25.15starseeker``Erik: if that's using our custom FindTCL there should be a way to expand the search paths
12:26.08``Erikis that pushed into rt^3, too?
12:26.24starseekeruh, dunno
12:26.44starseekerI was waiting until the ge/gs/gui reshuffle to go through all that
12:29.56*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:10.36*** join/#brlcad adityag (~ADITYA@182.237.144.88)
13:34.36CIA-105BRL-CAD: 03erikgreenwald * r44204 10/geomcore/trunk/src/interfaces/cl/brlcad.lisp: bind libgcv. do RT_APPLICATION_INIT stuff. use &key to fill some of the struct.
13:35.05CIA-105BRL-CAD: 03erikgreenwald * r44205 10/geomcore/trunk/src/interfaces/cl/ (gsnet.lisp gsserver.lisp): clean up conditional stuff
13:57.34*** join/#brlcad adityag (~ADITYA@182.237.144.88)
14:18.29CIA-105BRL-CAD: 03davidloman * r44206 10/geomcore/trunk/src/libNet/netMsg/GenericMultiByteMsg.cxx: Removed some stray debugging lines.
14:19.44brlcadso my joking rant was apparently taken much more to heart than was intended
14:20.16brlcadif anyone in here had a part in conveying how 'upset' I was, I really wasn't
14:21.34brlcadthe initial crap coding comment was totally meant to be tongue-in-cheek playful, the rest was simple matter-of-fact
14:21.42CIA-105BRL-CAD: 03davidloman * r44207 10/geomcore/trunk/ (include/GetCmd.h src/GS/cmds/GetCmd.cxx): Implement GetCmd for the test client.
14:22.13brlcadparticularly with release preparations under way
14:23.11dlomanWell, if you want honesty, i was working remotely yesterday and only had IRC to go by, but you came across as genuinely upset.  Just how I read it.
14:23.32dlomanbased on your above comments I assume others read it incorrectly also eh?
14:23.38brlcadapparently
14:23.56brlcaddislikes conflict, generally very happy-go-lucky
14:24.47brlcadI was annoyed by the timing, and that probably made some of my remarks more cynical than usual
14:24.55CIA-105BRL-CAD: 03davidloman * r44208 10/geomcore/trunk/src/libNet/netMsg/GeometryChunkMsg.cxx: Typo fix.
14:25.48dlomaneh, it happens.  As adults we all (should) have thick enough skin to weather someone's irritation, be it misinterpreted or not.
14:25.51brlcadeither way, the internet sucks at conveying emotion and intent -- I should (and do) know better and should have known better yesterday
14:26.35brlcadalso don't know if this played any part
14:26.44brlcadbut for the record
14:26.46brlcadreverts should have NO NEGATIVE CONNOTATION
14:27.17brlcadparticularly for open source software projects, something I was taught long ago that is different from closed development
14:27.37brlcadWhen there is dispute or need, it's supposed to encourage communication without any negative connotation.
14:27.46brlcadYou have just as much right to revert something I've done if a need arises.
14:27.53brlcadIf you un-revert something I've reverted, then we both stop and discuss since that implies there are conflicting needs.
14:28.05brlcadjust an FYI for everyone :)
14:28.59dlomandid i miss a revert war?
14:29.05brlcadnope
14:29.25brlcadbut I did revert something yesterday and don't know if that played any part in people "interpreting" my upsetness
14:29.49dlomankk.  I've been trying to pay atention to the commit emails and thought I'd missed yet another important bit of info
14:30.29dloman"SO i heard brlcad  was so mad that he punched three old ladies in the face."
14:30.40brlcadit was four dammit!
14:30.43dlomannice
14:32.08CIA-105BRL-CAD: 03davidloman * r44209 10/geomcore/trunk/src/GS/GeometryService.cxx: Make sure the DataManager point is initialized to something other than 0x0 prior to attempting to use it.
14:34.19CIA-105BRL-CAD: 03davidloman * r44210 10/geomcore/trunk/src/GS/DataManager.cxx: Add some error logging so that DataManager won't handle a GeometryReqMsg silently anymore.
14:43.18CIA-105BRL-CAD: 03davidloman * r44211 10/geomcore/trunk/src/ (3 files in 2 dirs): Make test client handle geometry data sent by server.
14:45.48dlomanwoot, back to where i was before the qt rip out :)
14:46.24``Erikstarts looking for something else to break O:-)
14:46.35dlomanlol
14:46.45dlomanno need, i'm already too good at breaking things.
14:47.01``Erikso ya found the segfault?
14:47.08dlomanoh, and take that damned halo off your head.  you're not fooling anyone :P
14:47.10dlomanyeah
14:47.31dlomankeith was right on with the pointer pointing at garbage
14:59.52CIA-105BRL-CAD: 03Markhobley 07http://brlcad.org * r2818 10/wiki/MGED_Commands: /* E */
15:11.55CIA-105BRL-CAD: 03davidloman * r44212 10/geomcore/trunk/src/libNet/NetMsgFactory.cxx: Make NetMsgFactory log an error when an unknown MsgType is encountered. (Rather than just returning NULL)
15:16.00CIA-105BRL-CAD: 03davidloman * r44213 10/geomcore/trunk/src/GS/DataManager.cxx: Fix DataManager's error reporting to the client. Was sending back error codes as MsgTypes. Now sends MsgTypes as MsgTypes!
15:20.04*** join/#brlcad adityag (~ADITYA@182.237.144.88)
15:20.36``Eriknow there's a cab: http://www.youtube.com/watch?v=OiKFCzMxJik
15:21.37dlomannice
15:23.50dlomanquestion: int bu_file_readable(const char *path)
15:24.05dlomanthe int that is returned.... is it 0 == readable ?
15:39.30``Eriknonzero is readable, src/libbu/stat.c ... if(bu_file_readable(file)) { do stuff to it; } else { bu_log("u y no has read?"); }
15:41.13dlomankk, that's what I was thinkging, just got confused.
15:41.14dlomandanke!
15:53.49CIA-105BRL-CAD: 03davidloman * r44214 10/geomcore/trunk/include/FileDataSource.h: Add in a util function that determines if the supplied path exists and if it does, whether or not its a file or dir.
15:54.18CIA-105BRL-CAD: 03davidloman * r44215 10/geomcore/trunk/src/GS/FileDataSource.cxx: Woops, forgot a file on the last commit.
16:03.00CIA-105BRL-CAD: 03davidloman * r44216 10/geomcore/trunk/src/GS/FileDataSource.cxx: Make FileDataSource filter out all paths except paths ending in files.
16:12.01*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
16:12.37CIA-105BRL-CAD: 03davidloman * r44217 10/geomcore/trunk/src/GS/cmds/GetCmd.cxx: Update the GetCmd::getHelp() method to display correct help
16:22.33*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
16:30.54brlcaddloman: there is no guarantee that <0 means files doesn't exist
16:31.27brlcadheader documents 0 (i.e., false) if doesn't exist, and >0 for exists .. <0 is undefined
16:31.43dlomandidn't see that in the header :/
16:31.52*** join/#brlcad hyarion_ (c05ben@peppar.cs.umu.se)
16:32.05dlomanjust saw one sentence, so i read the code and asked to confirm. =D
16:32.21brlcadthey're meant to be simple if (bu_file_exists(file)) then do something else don't
16:32.23*** join/#brlcad bhinesley_ (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net)
16:32.51brlcadcomplex return values usually indicate API weaknesses
16:32.58brlcadso it's just a simple boolean
16:33.02dlomankk
16:34.07*** join/#brlcad roberthl_ (~robert@v1.rhl.me.uk)
16:35.49*** join/#brlcad roberthl (~robert@v1.rhl.me.uk)
16:35.49*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
16:37.15*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
16:37.58*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
16:39.19brlcaddloman: fwiw, things like FileDataSource::existsFileOrDir() really belong up in libbu (at least the implementation of it does)
16:39.32brlcadso we're portably consistent and we get reuse
16:39.40dlomanright on.
16:40.03dlomani'm pushing getting functionally complete and debugged to stable.  Then I plan on doing a ****ton of clean up =D
16:40.15brlcadif the API is lacking, then it's just as much work to make things fit cleanly into libbu as they do somewhere else
16:41.47*** join/#brlcad roberthl (~robert@v1.rhl.me.uk)
16:41.47*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
16:43.14brlcadyeah, with the current code, I think we just hadn't had a need yet to distinguish dirs beyond bu_file_exists() and bu_count_path()
16:43.49brlcadif that need is there, then it's trivial to extend another call like bu_dir_exists() or bu_is_directory()
16:43.57dlomanwell if the esistsFileOrDir(char*) is usefull then i can push it down there.
16:44.14brlcadthere's a whole class of posix file node matches like that
16:44.38brlcadI wouldn't push it as it -- right now you only care if it's a file or a dir, but there are other types
16:44.41brlcadcould be a link
16:44.43brlcada pipe
16:44.44brlcada socket
16:45.04brlcadexistsFileOrDirOrSymbolicLinkOrPipeOr ...
16:45.19brlcadeach having useful purpose
16:46.47brlcadthat's why the current just followed the posix class ("man bash", jump down to CONDITIONAL EXPRESSIONS to see a list)
16:47.11dlomankk
16:48.52brlcadyou could get a nearly identical result to your function with something like bu_file_type() that returns an enum type for regular file, dir, link, named pipe, etc
16:49.39dlomanbu_file_type(), got it.
16:49.51brlcadthat way you're still only implementing support for the types you need now but have the API in place that will extend to future node types
16:49.54*** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net)
16:55.56CIA-105BRL-CAD: 03erikgreenwald * r44218 10/brlcad/trunk/src/conv/g-egg.c: eliminate as many globals as possible. pack the rest in the global struct.
16:57.11brlcadpretty awesome: http://www.youtube.com/watch?v=xFrMl_5T0Rc&feature=player_embedded
16:59.04brlcadopen source cars
17:01.39starseekeris that anything like these guys? http://www.40fires.org/
17:02.09starseekeror the commerical side:  http://www.riversimple.com/
17:05.16starseekerhuh - http://www.onawi.org/
17:05.27starseekerthat could be kinda cool
17:05.40dlomanam i reading g_transfer.c:server_geom() correctly?  wdb_export_external() doesn't write to disk there?
17:05.58dlomanbrlcad: Nice video, that guys a good speaker :)
17:13.23brlcaddloman: wdb_export_external() writes to the "database instance", whatever that is
17:13.34brlcadin g_transfer's case, it's an in-memory-only database
17:13.49dlomanyeah, figgered that out just now, heh.
17:13.56brlcadso it doesn't write to disk, but only because it's in-mem
17:14.29dlomanif i instantiate a different type of db, then wdb_export_external to that, then that will get me writing to disk...... correct?
17:14.56brlcaddepends what kind of dbip you make, but if it's a file-based dbip, then yes -- it'll write out to disk
17:19.29dlomandb_open() with a RT_WDB_TYPE_DB_DISK flag?
17:27.47brlcadsounds about right
17:27.56dlomanright on
17:28.14CIA-105BRL-CAD: 03starseeker * r44219 10/geomcore/trunk/src/ (6 files in 2 dirs): Get some renaming done, get a couple files building.
17:37.57CIA-105BRL-CAD: 03erikgreenwald * r44220 10/brlcad/trunk/ (configure.ac src/Makefile.am src/java/): no implementation, abandoned 8 years ago, unused, gone.
17:39.00dlomanhttp://www.local-motors.com/checkup.php?c=6998
17:39.01dlomanawesome.
17:41.53``Erikhttp://ecoroamer.com/drupal/CAD-files  dwg for the thing
17:42.13dloman....do i smell a new addition to the db library?
17:42.44``Erikdwg is all engineering line drawings, no solid geometry, right?
17:42.55starseekerright
17:43.10starseekergood material for modeling, but not a solid model itself
17:44.24starseekerlicense statement is... less than clear
17:44.39starseekersomeone should suggest one of the creative commons licenses to him
17:44.53CIA-105BRL-CAD: 03erikgreenwald * r44221 10/brlcad/trunk/src/conv/g-egg.c: quell warning that showed up on fbsd but not mac
17:46.34CIA-105BRL-CAD: 03starseeker * r44222 10/geomcore/trunk/src/libgvm/ (gvm_svn.h mem.c): Ah, right - we'll be using memory pools for the internals.
17:48.00``Eriklooks like it's just a stretched f650 with a camper O.o
17:49.00starseekerprobably
17:49.12dlomanyeah *JUST* a streched f650
17:50.10``Erikthey started with a 2007 f650 with a c7 diesel engine, stretched it, slapped a custom built camper on, run the camper on solar cells and heat captured off the exhaust O.o
17:52.34CIA-105BRL-CAD: 03starseeker * r44223 10/geomcore/trunk/src/libgvm/ (breakout.c gvm.h): move header entrys around, remove breakout.c (deal with that later)
17:52.59``Erikany news on red testing for release?
17:53.29CIA-105BRL-CAD: 03brlcad * r44224 10/brlcad/trunk/src/libged/wdb_obj.c: if ged_title() is wrong, then this one is probably wrong too since it's the daddy. make title not clobber units.
18:00.13starseekerwe've also got a report rtwizard isn't working... let me check...
18:00.46starseekercrud
18:03.14*** join/#brlcad Stattrav (~Stattrav@117.192.142.251)
18:03.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:05.06CIA-105BRL-CAD: 03brlcad * r44225 10/brlcad/trunk/NEWS:
18:05.06CIA-105BRL-CAD: bob found/fixed a bug with the title command. presumably, this would convert
18:05.06CIA-105BRL-CAD: the working units to mm if you tried to set the title via the units command.
18:09.50CIA-105BRL-CAD: 03brlcad * r44226 10/brlcad/trunk/TODO: libged encapsulation issue reverted for release, schedule backlog task to restore with libdm/libfb decoupling addressed. similar decouple needed for screengrab command (though that command may just end up migrating?).
18:11.42*** join/#brlcad adityag (~ADITYA@182.237.144.88)
18:19.40CIA-105BRL-CAD: 03davidloman * r44227 10/geomcore/trunk/include/FileDataSource.h: Add a //TODO about swapping out existsFileOrDir with bu_file_type()
18:31.40CIA-105BRL-CAD: 03davidloman * r44228 10/geomcore/trunk/src/GS/DataManager.cxx: Add server side logging for geometry requests
18:38.56CIA-105BRL-CAD: 03davidloman * r44229 10/geomcore/trunk/src/GS/FileDataSource.cxx: Make note about the Logger failing after the call to BRLCAD::MinimalDatabase cstr.
18:42.00CIA-105BRL-CAD: 03davidloman * r44230 10/geomcore/trunk/src/GS/GSClient.cxx: Display the name of the GeometryChunk as it comes in from the server
18:44.26CIA-105BRL-CAD: 03brlcad * r44231 10/brlcad/trunk/TODO: file node entity type support to libbu
19:21.22CIA-105BRL-CAD: 03brlcad * r44232 10/brlcad/trunk/TODO: red matrix edit works!
19:26.59CIA-105BRL-CAD: 03brlcad * r44233 10/brlcad/trunk/TODO: red is looking better, doesn't seem to list rgb/color attributes multiple times any more, but now seems to be wiping out the shader and region_id at least when set to plastic and -1 respectively.
19:42.57*** part/#brlcad adityag (~ADITYA@182.237.144.88)
20:38.54*** join/#brlcad Wildstar (42bd9f25@gateway/web/freenode/ip.66.189.159.37)
20:39.05WildstarHello
20:39.35WildstarIs there a PDP-11 source code for BRL-CAD?
20:41.13WildstarBBL
20:44.13CIA-105BRL-CAD: 03starseeker * r44234 10/geomcore/trunk/src/libgvm/ (CMakeLists.txt mem.c objects.c): Add preliminary stab at repository_object conversion routine.
20:45.44dliPDP-11 is 16bit, amazing request for brl-cad :(
20:50.48CIA-105BRL-CAD: 03erikgreenwald * r44235 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp gsserver.lisp): macros!
IRC log for #brlcad on 20110406

IRC log for #brlcad on 20110406

00:40.24*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ)
01:11.07*** join/#brlcad crazy_imp (~mj@89.182.193.239)
01:27.24*** join/#brlcad crazy_im1 (~mj@a89-182-193-239.net-htp.de)
01:28.00*** join/#brlcad vtts_ (~vytautas@diz.ktu.lt)
01:28.24*** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
01:30.39*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca)
01:32.29*** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net)
01:51.55*** join/#brlcad hyarion (c05ben@peppar.cs.umu.se)
01:53.46*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
01:54.23*** join/#brlcad dtidrow_ (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
02:14.14*** join/#brlcad sachinjain (~sachin@117.211.88.150)
02:14.44sachinjaindloman : I have uploaded a patch on sourceforge
02:15.02sachinjainwhat do I do next?
02:24.47*** join/#brlcad sachinjain (~sachin@117.211.88.150)
04:15.35*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
04:17.49*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca)
05:09.07*** join/#brlcad adityag (~ADITYA@182.237.144.88)
06:18.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:31.57*** part/#brlcad adityag (~ADITYA@182.237.144.88)
06:38.37*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:45.17bhinesleyare there any requests for commands to migrate to Archer?
06:45.39bhinesleyhard for me to tell what is useful
07:12.25*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
07:23.14*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
07:28.10*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
09:42.11bhinesleydloman: I'm not sure if it alerts you; I have updated my proposal.
12:17.34CIA-105BRL-CAD: 03davidloman * r44236 10/geomcore/trunk/include/ByteArray.h: Fix typo!
12:20.56*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
12:34.10tofuwoo hoo, e-mail notifications are wroking
12:34.25brlcadbhinesley: it sends notifications now
12:35.09brlcaddli: not really an amazing request -- that's about when BRL-CAD was started, on 16-bit systems
12:35.18brlcadvax 11/780, pdp-11, etc
12:38.40brlcadbhinesley: an intersting list of 13 to start with .. some of those will be hard, some are dead easy, some will require a complete rewrite... :)
12:39.20brlcadI wouldn't put read_muves on that list myself
12:39.48brlcadreid and remat are very useful commands, but they're actually presently coded as simple tcl scripts
12:42.23brlcadthe rcc-* commands really warrant being grouped into a single command with various sub-commands, but sorting out a useful naming convention hasn't happened
12:42.54brlcadprj-add is a hack simply because the projection shader is complicated (still a useful command, but stupid API-wise)
12:43.08brlcadeither way, a very interesting list :)
12:43.59brlcada simple way to narrow in on 10 to migrate is to look at the MGED quick reference sheet and simply go by any of those that aren't in LIBGED yet, those are core useful commands
12:44.31brlcadseveral of which you list: closedb, journal, man)
12:44.44brlcadnice work
12:46.31``Erikvax11/780 was a 32b system
12:50.01``Erikthought that by the time the first hints of raytracing code hit rcs in '85, the pdp was gone and it was done on vax
13:13.57brlcadit was done on the vax, but the pdp wasn't gone just yet iirc
13:19.32*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:25.33*** join/#brlcad adityag (~ADITYA@182.237.144.88)
13:30.57dlomanhttps://www.ibm.com/developerworks/mydeveloperworks/blogs/InsideSystemStorage/entry/ibm_japan_mailbag_of_interesting_reactions7?lang=en
13:54.22*** part/#brlcad adityag (~ADITYA@182.237.144.88)
14:38.02*** join/#brlcad adityag (~ADITYA@182.237.144.88)
15:02.51CIA-105BRL-CAD: 03bob1961 * r44237 10/brlcad/trunk/src/tclscripts/mged/openw.tcl: Added a wrapper for the call to dbupgrade from the Tools menu. This catches the call and prints the results to the command window. The catch prevents a possible error window popping up.
15:15.46*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
15:27.00*** join/#brlcad adityag (~ADITYA@182.237.144.88)
15:34.27*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
15:43.59CIA-105BRL-CAD: 03brlcad * r44238 10/brlcad/branches/STABLE/ (81 files in 28 dirs): merge trunk to STABLE from r43921 to HEAD r44237
15:49.12*** part/#brlcad adityag1 (~ADITYA@182.237.144.88)
16:34.57CIA-105BRL-CAD: 03indianlarry * r44239 10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c:
16:34.57CIA-105BRL-CAD: Having issues with 'size_t' declaration of some variables within function
16:34.57CIA-105BRL-CAD: rt_bot_makesegs_(). Variables need signed values so converted to 'ssize_t'. Only
16:43.27*** join/#brlcad adityag (~ADITYA@182.237.144.88)
16:59.32bhinesleybrlcad: Should I avoid the rcc commands, then?
16:59.32bhinesleyThere are ~50 commands on the quick reference that aren't currently available in archer. I've found that several appear to be obsolete, and some are nearly migrated already (sometimes just missing aliases).
16:59.32bhinesleyBesides those already listed, what remains is: dbfindtree, geometree, rtabort, ill, sill, matpick, facedef, mirface, permute, extrude, orot, rotobj, oed, orientation, accept, reject, qorot, eqn, eye_pt, mrot, vrot, and area.
16:59.32bhinesleyI hate to ask, but are there any that you would recommend?
16:59.33bhinesleyFailing that, I've identified another ~90 commands based on the source. There are probably more, that simply aren't in the usual places.
17:01.53indianlarry
17:06.36brlcadbhinesley: many of 50+ commands are available in archer, but under a different name
17:06.53brlcadthere shouldn't be too many actually obsolete
17:07.07*** part/#brlcad adityag (~ADITYA@182.237.144.88)
17:08.05bhinesleyI tried to remove them If I could find that the name was just changed
17:08.41bhinesleyas for obsolete commands, I found <5 from the quick reference.
17:09.57brlcadokay, that sounds about right
17:10.12brlcadgeometree would be one, archer has its own tree view
17:10.36bhinesleyI did make that note :)
17:10.47brlcadaccept/reject pertain to stateful editing, which archer attempts to move away from
17:11.04bhinesleyso oed is probably obsolete too
17:11.25brlcadyes and no
17:11.34brlcadwhat it does definitely need to be in libged ...
17:11.44brlcadbut the way it does it might not necessarily be an 'oed' command
17:11.52bhinesleynods
17:12.14brlcadoed would be one of my top-picks to sort out migrating
17:12.38brlcada whole tutorial is dedicated to oed because it's the main way to perform matrix editing on the command line in mged
17:13.44brlcadarcher presently doesn't have a mechanism defined for matrix editing on the command line iirc, which relates to all of the transformation and illumination commands you listed: ill, sill, matpick, orot, rotobj, qorot, mrot, vrot
17:14.10bhinesleythat's what I thought :-/
17:14.12brlcadwhich are rather ridiculous
17:14.21brlcadthere should be one "rotate" command
17:14.35bhinesleyhas this been done?
17:14.36brlcadwith various suboptions for the different ways you might want to rotate
17:15.10brlcadof course not, it's basically refactoring those command names listed into one command when they migrate to libged
17:15.34brlcadorot+rotobj+qorot+mrot+vrot+rot -> rotate [options]
17:16.09brlcadyou're going to get pretty nut and bolty with the commands remaining :)
17:16.33brlcadall the easy ones are already done
17:16.49bhinesleyso it seems
17:17.09brlcadfyi, there are approximately 700 commands in mged last time I counted
17:17.37brlcadthe goal is to consolidate that down to less than 200 without loss of functionality
17:17.51brlcadobviously not part of a summer's work, but it's the bigger picture
17:18.50brlcadmost of the quick ref sheet commands should migrate as-is just for a starting reference point (unless someone tackles the refactoring sooner)
17:19.11brlcadthat's about 10%
17:22.30brlcadbhinesley: once you get into the swing of things, it'd probably be helpful to set up a spreadsheet of all the commands on the quick ref sheet with columns for the name in mged, status of libged refactoring, archer name, etc
17:22.52brlcadthen just work down the list
17:24.35brlcadthat way we can be more certain of what has been looked at and migrated, what was migrated but renamed, what hasn't been migrated at all yet because it's a script or crap or irrelevant, and what just hasn't even been looked at  yet
17:25.08bhinesleysounds good
17:29.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:07.18CIA-105BRL-CAD: 03starseeker * r44240 10/geomcore/trunk/src/libgvm/ (gvm.h objects.c): This function should be returning the bu_external - let the calling function decide how to package it or use it.
18:13.16CIA-105BRL-CAD: 03erikgreenwald * r44241 10/brlcad/trunk/src/librt/opennurbs_ext.h: remove inline calls that cause gcc3.4.6 to fail (needs review)
18:18.15brlcadthose inline statements were required to keep 4.3 or 4.4 happy, compilation fail with --enable-optimized iirc
18:18.36brlcadmaybe a pragma similar to what's in bu.h
18:21.07``Erikhm, an emergency install this morning on the darkside went all wonky for indianlarry (rhel4), we can't give up gcc3 support just yet... which in bu.h? not seeing anything in there about gcc versions or anything related about inlines
18:36.25*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
18:39.03*** join/#brlcad Stattrav (~Stattrav@117.192.134.162)
18:39.03*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:43.23*** join/#brlcad Ralith (~ralith@d142-058-174-190.wireless.sfu.ca)
19:05.05brlcad``Erik: __BU_ATTR_*
19:05.21brlcadthey're not (yet) protected because we haven't had one that was version-dependent
19:06.38brlcadas for the dark side, that's a configuration snafu -- gcc4 is installed, it's just not default ... ./configure CC=gcc4
19:07.59brlcadaha, common.h -- that's where the version-specific logic is at, so bu.h could stay simple
19:59.03CIA-105BRL-CAD: 03starseeker * r44242 10/geomcore/trunk/src/libgvm/ (gvm.h objects.c): (untested) check to see if an object is present in the repository
20:59.25*** join/#brlcad adityag (~ADITYA@182.237.144.88)
21:34.29CIA-105BRL-CAD: 03starseeker * r44243 10/geomcore/trunk/src/libgvm/ (gvm.h objects.c): Completely untested (the add and delete logic is untested even in svntest) but start working on the commit logic)
21:49.14CIA-105BRL-CAD: 03starseeker * r44244 10/brlcad/branches/STABLE/src/librt/primitives/bot/g_bot_include.c: sync STABLE to trunk r44240
21:53.48starseekerhttp://arstechnica.com/tech-policy/news/2011/04/the-next-napster-copyright-questions-as-3d-printing-comes-of-age.ars
22:04.29*** part/#brlcad adityag (~ADITYA@182.237.144.88)
22:51.03*** join/#brlcad Ralith (~ralith@d142-058-174-190.wireless.sfu.ca)
IRC log for #brlcad on 20110407

IRC log for #brlcad on 20110407

00:04.10*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
00:09.05kunigami_hi, I've updated my proposal on "shaders enhancements". commentaries are most welcome!
00:19.00brlcadkunigami_: hehe
00:19.02brlcad"write a small tutorial on how to write a tutorial on how to implement shaders"
00:20.08brlcadbut ... I what if I need a tutorial on writing small tutorial on how to write a tutorial on how shaders are implemented?
00:25.44kunigami_brlcad: oops let me correct that :P
00:26.23*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601295.dsl.bell.ca)
00:33.31brlcadkunigami_: so a few other comments and clarifications
00:34.37brlcadit doesn't necessarily have to go into your proposal now (though it will be useful pre-coding work), but you'll have to tell me more about their concept of closures
00:35.27brlcadas well as whether OSL actually evaluates / calculates the optical properties of a shader or whether it just describes a shader
00:36.27kunigami_brlad: hmm, ok! I think I'll spend some more time playing with OSL tomorrow!
00:37.30brlcada shader can be a completely abstract concept, so it's hard for me to imagine they actually implemented a system that takes a C-style text description and turns it into an actual working implementation .. but maybe, imageworks has a lot of resources
00:38.20brlcadreturning a parametric representation sounds more plausible, but then how that interacts with a raytrace sounds very interesting
00:39.15brlcadkunigami_: one thing you can look at, on the wiki is a tutorial on shooting a ray with brl-cad -- that has no shader/optics, just returns a hit point
00:39.26brlcadyou could use that with OSL as a proof-of-concept
00:39.33brlcadthat might be something work milestoning
00:39.38brlcads/might/would/
00:39.45brlcadsince it would show how the two interact
00:41.00kunigami_hmm good idea!
01:01.58brlcadstarseeker: I hope you meant sync TRUNK to stable and not stable to trunk... ;)
01:08.43*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
01:11.53*** join/#brlcad crazy_imp (~mj@a89-182-6-68.net-htp.de)
01:17.13CIA-105BRL-CAD: 03brlcad * r44245 10/brlcad/trunk/include/ (bu.h common.h): add __BU_ATTR_ALWAYS_INLINE with a protection for gcc 3.4 and earlier where the always_inline attribute wasn't yet fully implemented (reportedly still works for some optimization options)
01:19.27CIA-105BRL-CAD: 03brlcad * r44246 10/brlcad/trunk/src/librt/opennurbs_ext.h:
01:19.27CIA-105BRL-CAD: use the new __BU_ATTR_ALWAYS_INLINE define so that we get forced inline behavior
01:19.27CIA-105BRL-CAD: for newer gcc or forced off if older. the 'inline' keyword may be superfluous
01:24.04brlcadtick tock gsoc applicants!
01:24.11brlcadtwo days remaining
02:00.52*** join/#brlcad PrezWhiteCalf (MK@whitecalf.net)
02:03.48*** join/#brlcad WhiteCalf (MK@whitecalf.net)
02:16.53starseekerer, yeah
03:11.57*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
03:16.17bhinesleybrlcad: Part of my new plan is to migrate oed (modified for stateless use), which then opens the door for ill, sill, and consolidation of all the rot commands. I wanted to try and get your opinion before updating the proposal.
03:25.17bhinesleyAlso, I was hoping to include the consolidation of the rcc-* commands, which you mentioned was desirable. Can a naming convention be hashed out during the coding phase, or is that something that the proposal should address?
03:53.25brlcadbhinesley: the proposal doesn't have to have everything addressed, just a clear plan (even if the plan includes numerous research, design, and coding work)
03:54.54*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
04:05.45bhinesleyokay; I'm submitting again.
04:05.48brlcadbhinesley: the plan to migrate oed sounds great but that will be a somewhat tricky on -- give yourself a good bit of time (a week or two) for just that one command
04:06.23bhinesleythat should be just fine, I rear-loaded the milestones to give me a chance to tackle the tougher issues
04:07.00brlcadsetting up some means to track your progress can be a milestone in itself
04:07.30brlcad(e.g., the spreadsheet idea)
06:13.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:57.56*** join/#brlcad merzo (~merzo@193.254.217.44)
07:00.54*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
09:43.50*** join/#brlcad sachinjain (~sachin@117.211.88.150)
11:19.57CIA-105BRL-CAD: 03davidloman * r44247 10/geomcore/trunk/tests/ (20 files in 19 dirs): Split out tests into Functional and Unit dirs in prep for some unit test addition.
11:37.36*** join/#brlcad Stattrav (~Stattrav@122.172.43.72)
11:37.36*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:03.09*** join/#brlcad adityag (~ADITYA@182.237.144.88)
13:33.12*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:42.34sachinjainbrlcad : can you tell me what are the two approaches that you told me earlier for the project "vector output from raytracing"
13:43.25sachinjainand I have also uploaded a patch on sourceforge as you told to do so
13:43.41sachinjaintold me*
13:48.01CIA-105BRL-CAD: 03starseeker * r44248 10/geomcore/trunk/tests/func/svntest/main.c: Work from respository root for commit, rather than assuming a particular model
13:51.31CIA-105BRL-CAD: 03starseeker * r44249 10/geomcore/trunk/tests/func/CMakeLists.txt: tweak build to get it working...
13:53.43sachinjainisn't there any developer online?
13:53.57CIA-105BRL-CAD: 03starseeker * r44250 10/geomcore/trunk/src/libgvm/objects.c: Will need to specify 'root' here as well
13:59.30CIA-105BRL-CAD: 03starseeker * r44251 10/geomcore/trunk/src/libgvm/objects.c: Memory is in pool, but go ahead and dequeue list...
14:16.26d_rossbergsachinjain: now, yes
14:17.41d_rossbergups, he quit
14:18.24starseekerhe doesn't really seem to grasp the nature of IRC
14:27.59``Erikor mebbe he pays by time or data xfer
14:28.32``Erik(or has to use a cybercafe or school lab for internet access)
14:47.19starseekerscreen + remote server
15:04.26``Erikgotta have shell access on a remote server to do that :D
15:05.22brlcadthey're at a uni .. chances are super-high that they have or could get access
15:07.22``ErikI d'no, where I went, they started killing screens at night and then removed unix servers for NT ones (12 rs6k aix boxes took over 300 nt4 machines to meet needs), and he may've moved back home for the summer *shrug* not everyone has our level of access, 'sall I'm sayin'
15:08.05CIA-105BRL-CAD: 03starseeker * r44252 10/geomcore/trunk/src/libgvm/ (CMakeLists.txt models.c): Add logic for adding a new model
15:08.21``Erikmight be worth asking his connection details before stating that he doesn't "get it"
15:08.47brlcadgiven the previous discussions, I'd still bet on him just not getting it or not being patient
15:09.21starseekerwhatever his connection details, IRC is what it is - if he can't communicate on those terms that's OK, but then he should be using email
15:09.33brlcadeverything you describe happened where I was at, but there was still a dozen ways I could have run a screen session
15:09.51brlcadyou only have to find ONE .. which really isn't that hard
15:10.35brlcadstarseeker: great point, IRC isn't an excuse given we have a mailing list
15:16.21*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
15:32.19*** join/#brlcad PrezKennedy (MK@whitecalf.net)
15:43.19*** join/#brlcad Stattrav (~Stattrav@117.192.145.3)
15:43.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:47.11CIA-105BRL-CAD: 03starseeker * r44253 10/geomcore/trunk/src/libgvm/models.c: add gvm_get_model implementation
15:50.54*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
16:06.20*** join/#brlcad Stattrav_ (~Stattrav@117.192.135.83)
16:22.38CIA-105BRL-CAD: 03brlcad * r44254 10/brlcad/trunk/src/libbu/: timetester binary
16:23.25CIA-105BRL-CAD: 03brlcad * r44255 10/brlcad/trunk/src/libpc/: ignore pc_test binary
16:24.15CIA-105BRL-CAD: 03brlcad * r44256 10/brlcad/trunk/src/libbn/: ignore bntester binary
16:26.56CIA-105BRL-CAD: 03r_weiss * r44257 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed)
16:26.56CIA-105BRL-CAD: Added preprocessor commands to optionally disable nmg triangulation functions
16:26.56CIA-105BRL-CAD: within nmg_tri.c that are not needed when new 'prototype' nmg triangulation code
16:47.39CIA-105BRL-CAD: 03starseeker * r44258 10/geomcore/trunk/src/libgvm/models.c: restructure gvm_get_model to be simpler - don't really need callback. Start working on gvm_get_objs - this will be tricky since it's essentially a keep without the full database
16:54.54CIA-105BRL-CAD: 03brlcad * r44259 10/brlcad/trunk/src/other/incrTcl/itcl/generic/itclInt.h: is the common.h header necessary here? builds clean without
16:59.38*** join/#brlcad Stattrav (~Stattrav@117.192.154.206)
16:59.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:04.16brlcad``Erik: this is the one: http://www.tirerack.com/tires/tires.jsp?tireMake=Continental&tireModel=ExtremeContact+DWS
17:05.57brlcadhttp://www.e90post.com/forums/showthread.php?t=302424
17:10.03*** join/#brlcad Stattrav (~Stattrav@117.192.139.40)
17:10.03*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:13.11*** join/#brlcad Elrohir (~kvirc@p5B14AD98.dip.t-dialin.net)
17:17.23*** join/#brlcad Stattrav (~Stattrav@117.192.135.92)
17:17.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:18.00``Erikbrlcad: these were the kind I had http://www.sears.com/shc/s/p_10153_12605_09543528000P?sid=IDx20070921x00003a&ci_src=14110944&ci_sku=09543528000P
17:20.33``Erikthen I went to http://www.tirerack.com/tires/tires.jsp?tireMake=Michelin&tireModel=Pilot+Sport&partnum=54YR8SPORTG1&vehicleSearch=false&fromCompare1=yes which were awesome
17:20.57``Eriklast rears I got, they ordered the wrong ones and I got http://www.tirerack.com/tires/tires.jsp?tireMake=Michelin&tireModel=Pilot+Sport+A%2FS+Plus&partnum=54YR8PSAS&vehicleSearch=false&fromCompare1=yes
17:22.52brlcadyeah, this is the review I was mentioning: http://www.consumersearch.com/tires/continental-extremecontact-dws
17:23.00brlcaddefinitely not the same tire :)
17:24.45``Erikyeh, all season instead of summer... won't stick as well, but will last longer and do better in rain
17:25.26brlcadyeah, the michelin was what I was going to go with, though one step up, the pilot super sport
17:26.08brlcadhttp://www.michelinman.com/tire-selector/category/ultra-high-performance-sport/pilot-super-sport/tire-details
17:26.18brlcadbut too long a wait, it's a new tire
17:26.35brlcadwasn't going to be available until next week, wanted something now
17:27.14``Erikhm, longer treadlife than the ones I used to have, interesting
17:27.17brlcadwe'll see how it goes, so far I'm loving them .. super comfortable and quiet ride, and holding grip well enough to still make me smile
17:28.08``Erikponders the pilot sport cup
17:33.37CIA-105BRL-CAD: 03r_weiss * r44260 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
17:33.37CIA-105BRL-CAD: Added a prototype version of the function 'nmg_triangulate_fu' (nmg triangulate
17:33.37CIA-105BRL-CAD: faceuse) to the file 'nmg_tri.c'. Added preprocessor commands to, by default,
18:14.36CIA-105BRL-CAD: 03r_weiss * r44261 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed)
18:14.36CIA-105BRL-CAD: Added the functions 'nmg_plot_fu', 'nmg_triangulate_rm_holes',
18:14.36CIA-105BRL-CAD: 'nmg_triangulate_rm_degen_loopuse', and 'nmg_dump_model' to the file
18:42.17CIA-105BRL-CAD: 03r_weiss * r44262 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed)
18:42.17CIA-105BRL-CAD: Added a new prototype version of the function 'cut_unimonotone' to the file
18:42.17CIA-105BRL-CAD: 'nmg_tri.c'. This function supports the new prototype function
18:42.25*** join/#brlcad adityag (~ADITYA@182.237.144.88)
18:46.58CIA-105BRL-CAD: 03Markhobley 07http://brlcad.org * r2819 10/wiki/MGED_Commands: /* E */
19:05.53*** join/#brlcad Stattrav (~Stattrav@117.192.128.64)
19:05.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:13.11CIA-105BRL-CAD: 03r_weiss * r44263 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed)
19:13.11CIA-105BRL-CAD: Updated function 'pick_pt2d_for_cutjoin' within file 'nmg_tri.c'. This update
19:13.11CIA-105BRL-CAD: supports the new prototype function 'nmg_triangulate_fu' (nmg triangulate
19:39.19CIA-105BRL-CAD: 03r_weiss * r44264 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed)
19:39.19CIA-105BRL-CAD: Updated function 'is_convex' within file 'nmg_tri.c'. This update supports the
19:39.19CIA-105BRL-CAD: new prototype function 'nmg_triangulate_fu' (nmg triangulate faceuse) and is
19:41.22*** part/#brlcad adityag (~ADITYA@182.237.144.88)
19:51.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:04.29``Erikneat. incr fails now :D
20:05.19starseekeroh, now that I think about it I recall something similar when I tried a vanilla build of incr
20:13.54CIA-105BRL-CAD: 03r_weiss * r44265 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: (log message trimmed)
20:13.54CIA-105BRL-CAD: Updated function 'nmg_cut_loop' within file 'nmg_mod.c'. This update supports
20:13.54CIA-105BRL-CAD: the new prototype function 'nmg_triangulate_fu' (nmg triangulate faceuse) and is
20:39.04CIA-105BRL-CAD: 03r_weiss * r44266 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c:
20:39.04CIA-105BRL-CAD: Updated function 'nmg_classify_lu_lu' within file 'nmg_class.c'. This update
20:39.04CIA-105BRL-CAD: supports the new prototype function 'nmg_triangulate_fu' (nmg triangulate
21:05.49CIA-105BRL-CAD: 03r_weiss * r44267 10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c:
21:05.49CIA-105BRL-CAD: Updated function 'nmg_2edgeuse_g_coincident' within file 'nmg_info.c'. This
21:05.49CIA-105BRL-CAD: update supports the new prototype function 'nmg_triangulate_fu' (nmg triangulate
21:15.03``Eriksrc/brlcad/src/other/tcl/generic/tclInt.h:56: error: conflicting types for 'ptrdiff_t'
21:15.07``Erik<PROTECTED>
21:17.16``Erikhttp://paste.lisp.org/display/121260 is the full one, I imagine that common.h was important
21:23.44CIA-105BRL-CAD: 03r_weiss * r44268 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c:
21:23.44CIA-105BRL-CAD: Updated function 'nmg_lu_reorient' within file 'nmg_mod.c'. This update supports
21:23.44CIA-105BRL-CAD: the new prototype function 'nmg_triangulate_fu' (nmg triangulate faceuse) and is
21:34.40CIA-105BRL-CAD: 03r_weiss * r44269 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c:
21:34.40CIA-105BRL-CAD: Updated function 'nmg_isect_eu_fu' within file 'nmg_inter.c'. This update
21:34.40CIA-105BRL-CAD: supports the new prototype function 'nmg_triangulate_fu' (nmg triangulate
21:37.19*** join/#brlcad dli (~dli@132.205.216.21)
21:51.16CIA-105BRL-CAD: 03starseeker * r44270 10/geomcore/trunk/src/libgvm/models.c: Untested, but add some logic to pull the comb's tree and add its members (if they're something not already seen) to the hash
22:04.42starseekerwell, good news and bad news about kermit
22:04.59starseekerbad news is the project is shutting down, good news is they're planning to BSD license it
22:07.12*** join/#brlcad Elrohir (~kvirc@p5B14AD98.dip.t-dialin.net)
22:33.42starseekerwonders if their terminal emulation code could do what we need on Windows...
22:45.17starseekerprods himself again to give this a try... http://www.projectpluto.com/win32a.htm
22:54.06CIA-105BRL-CAD: 03starseeker * r44271 10/geomcore/trunk/src/libgvm/models.c: Once we have the objects in question, stick 'em on the list.
22:56.04CIA-105BRL-CAD: 03starseeker * r44272 10/geomcore/trunk/src/libgvm/models.c: Oh, right - we had to get the bu_external already earlier, so no need to get it again.
23:51.39CIA-105BRL-CAD: 03starseeker * r44273 10/geomcore/trunk/src/libgvm/ (gvm.h models.c): Clear out comment, add gvm_export_list to header.
23:53.27CIA-105BRL-CAD: 03starseeker * r44274 10/geomcore/trunk/src/libgvm/models.c: Go with NULL to avoid confusion here, assuming that's viable
IRC log for #brlcad on 20110408

IRC log for #brlcad on 20110408

00:22.52CIA-105BRL-CAD: 03starseeker * r44275 10/geomcore/trunk/src/libgvm/ (CMakeLists.txt files.c): Start working on .g file handling routines
00:37.05*** join/#brlcad PrezKennedy (MK@whitecalf.net)
00:51.48CIA-105BRL-CAD: 03starseeker * r44276 10/geomcore/trunk/src/libgvm/ (files.c models.c): Make a stab at file export
01:11.28*** join/#brlcad crazy_imp (~mj@a89-182-212-231.net-htp.de)
01:15.04*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
03:16.24starseekerhmm - X11 license:  http://www.mozart-oz.org/
03:26.57brlcad``Erik: hm, k -- that'd be the common.h then
03:27.17brlcadwill revert
03:38.03CIA-105BRL-CAD: 03brlcad * r44277 10/brlcad/trunk/src/other/incrTcl/itcl/generic/itclInt.h: revert r44259
04:08.05*** join/#brlcad siddharth (~siddharth@117.211.88.150)
04:08.12siddharthanyone here?
04:54.44*** join/#brlcad adityag (~ADITYA@182.237.144.88)
06:09.28*** part/#brlcad adityag (~ADITYA@182.237.144.88)
06:43.47*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:53.12*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:02.50*** join/#brlcad Stattrav (~Stattrav@122.167.168.206)
07:02.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:47.16*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:26.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:16.15*** join/#brlcad Elrohir (~kvirc@p5B14BE4A.dip.t-dialin.net)
12:59.18*** join/#brlcad adityag (~ADITYA@182.237.144.88)
14:14.31*** part/#brlcad adityag (~ADITYA@182.237.144.88)
14:55.58*** join/#brlcad adityag (~ADITYA@182.237.144.88)
15:00.59CIA-105BRL-CAD: 03r_weiss * r44278 10/brlcad/trunk/src/libbn/plane.c: (log message trimmed)
15:00.59CIA-105BRL-CAD: Added new prototype versions of the functions 'bn_isect_lseg3_lseg3' and
15:00.59CIA-105BRL-CAD: 'bn_isect_line3_line3' to the file 'plane.c'. The names of these new function
15:07.05CIA-105BRL-CAD: 03r_weiss * r44279 10/brlcad/trunk/include/bn.h: (log message trimmed)
15:07.05CIA-105BRL-CAD: Updated the header file for libbn (i.e. bn.h) to include the definition of new
15:07.05CIA-105BRL-CAD: prototype versions of the functions 'bn_isect_lseg3_lseg3' and
15:15.23CIA-105BRL-CAD: 03r_weiss * r44280 10/brlcad/trunk/include/raytrace.h:
15:15.24CIA-105BRL-CAD: Updated the header file 'raytrace.h' to include the definition of a new
15:15.24CIA-105BRL-CAD: prototype function 'nmg_dump_model'. This new function is located in file
16:08.50*** join/#brlcad adityag (~ADITYA@182.237.144.88)
16:37.48CIA-105BRL-CAD: 03starseeker * r44281 10/brlcad/branches/cmake/ (CMakeLists.txt src/vfont/CMakeLists.txt): If we have rpmbuild around, add the RPM generator to the package build
17:01.30CIA-105BRL-CAD: 03starseeker * r44282 10/brlcad/branches/cmake/CMakeLists.txt: Minimize hard-coding - use CMAKE_INSTALL_PREFIX for this, if we can get away with it
18:30.56*** join/#brlcad Stattrav (~Stattrav@117.192.131.161)
18:30.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:41.44*** part/#brlcad adityag (~ADITYA@182.237.144.88)
19:09.40CIA-105BRL-CAD: 03erikgreenwald * r44283 10/brlcad/trunk/sh/conversion.sh: If no OBJECTS are set, pass an explicit "-print" to search. This may be a bug in the ged_search implementation ("search ." is no longer legitimate).
19:23.09brlcadit is a bug
19:31.41CIA-105BRL-CAD: 03erikgreenwald * r44284 10/brlcad/trunk/sh/conversion.sh: force posix output from time(1)
19:32.09``Erikyup, talked to starseeker about it. *shrug* when it's fixed, we can remove the workaround
19:34.39CIA-105BRL-CAD: 03starseeker * r44285 10/geomcore/trunk/src/libgvm/files.c: rough out logic to use a .g file as the basis for a commit update set.
19:35.20CIA-105BRL-CAD: 03erikgreenwald * r44286 10/brlcad/trunk/src/libged/search.c: some notes on the workaround for the "search ." bug
19:35.49``Erikman, if I get a two week surprise vacation, I'm going to have trouble remembering C :D I'm already doing bu_log("~d"
19:45.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:53.42brlcadis running a coverity scan on brl-cad right now
19:54.18starseekersweet!
19:59.35CIA-105BRL-CAD: 03starseeker * r44287 10/geomcore/trunk/src/libgvm/mem.c: Oh yeah, don't forget svn_cmdline_init
20:00.23*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
20:03.59CIA-105BRL-CAD: 03erikgreenwald * r44288 10/brlcad/trunk/db/bldg391.asc: remove references to nonexistent regions (midwall.r equip)
20:33.41CIA-105BRL-CAD: 03starseeker * r44289 10/geomcore/trunk/ (6 files in 3 dirs): Add a basic gvmtest program - not much working yet, but get it in there to make shakedown possible.
20:56.17brlcadaaaand, the first pass through the system seems to have gotten stuck in libfft, restarting build
21:00.11CIA-105BRL-CAD: 03starseeker * r44290 10/geomcore/trunk/src/libgvm/files.c: If 0, use latest revision (will need to do this in other functions too)
21:12.03CIA-105BRL-CAD: 0399.183.222.230 07http://brlcad.org * r2820 10/wiki/Talk:MGED_to_Archer_Command_Migration: Project Proposal for G-coding extension
21:13.02*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
21:51.20CIA-105BRL-CAD: 03starseeker * r44291 10/geomcore/trunk/src/libgvm/files.c: For reasons that are not immediately clear, the wdb_close (or db_close) bomb out when trying to export the .g file. It's reporting bad magic, but not clear how that bad magic is coming about.
21:53.10CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Talk:MGED to Archer Command Migration]]": inappropriate place to ask questions about gcode, linking to and external website is not cool
22:06.09brlcad2139 compilation units (100%) are ready for analysis
22:06.09brlcadThe cov-build utility completed successfully.
22:06.14brlcadwoot!
22:09.13bhinesleyThat's pretty interesting, I hadn't heard of coverity.
22:15.24*** part/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net)
22:15.31*** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net)
22:16.33starseekerOK, it's not the way the repository is being build, because svntest can reassemble that repository
22:25.19CIA-105BRL-CAD: 03starseeker * r44292 10/geomcore/trunk/src/libgvm/objects.c: Hmm - interesting. Looks like the database needs externs even in cases where the lookup isn't finding anything - this resolves the crash
IRC log for #brlcad on 20110409

IRC log for #brlcad on 20110409

01:12.14*** join/#brlcad crazy_imp (~mj@a89-182-23-46.net-htp.de)
02:35.00brlcadoutstanding .. coverity report took 2.5 hours to process, found a little under 2k issues
02:35.27brlcadspot-checking just a couple and they're valid (and outstandingly descriptive!)
02:35.48brlcadso this should be some pretty awesome homework
02:42.19brlcadI'll check next week into getting other accounts created so multiple people can work on fixing the defects
04:27.47bhinesleythat's amazing
04:28.03bhinesleyI'd love to see what that output looks like
07:22.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:50.13*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
09:05.12*** join/#brlcad Stattrav (~Stattrav@117.192.133.79)
09:05.12*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:21.17*** join/#brlcad Stattrav_ (~Stattrav@117.192.139.114)
10:26.26*** join/#brlcad mafm (~mafm@236.Red-83-55-205.dynamicIP.rima-tde.net)
12:53.46*** join/#brlcad adityag (~ADITYA@182.237.144.88)
14:07.47*** join/#brlcad adityag (~ADITYA@182.237.144.88)
14:20.16*** join/#brlcad adityag (~ADITYA@182.237.144.88)
14:25.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:39.36*** join/#brlcad adityag (~ADITYA@182.237.144.88)
14:58.34*** join/#brlcad Stattrav (~Stattrav@117.192.136.165)
14:58.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:06.52*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
15:16.15*** join/#brlcad adityag (~ADITYA@182.237.144.88)
16:38.27*** join/#brlcad adityag (~ADITYA@182.237.144.88)
17:47.00*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
18:39.08*** join/#brlcad Stattrav (~Stattrav@117.192.136.165)
18:39.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:52.05*** part/#brlcad adityag (~ADITYA@182.237.144.88)
19:52.51*** join/#brlcad kunigami (~kunigami@187.21.173.136)
20:23.12*** join/#brlcad kunigami_ (~kunigami@187.21.173.136)
21:38.25*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
22:04.01*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
22:10.09*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
22:11.43*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
22:49.21*** join/#brlcad kunigami (~kunigami@187.21.173.136)
22:51.11*** join/#brlcad kunigami_ (~kunigami@187.21.173.136)
23:13.00*** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net)
23:49.45*** join/#brlcad kunigami (~kunigami@187.21.173.136)
IRC log for #brlcad on 20110410

IRC log for #brlcad on 20110410

01:08.25*** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net)
01:11.55*** join/#brlcad crazy_imp (~mj@a89-182-14-73.net-htp.de)
01:44.59*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
03:10.14*** join/#brlcad kunigami_ (~kunigami@187.21.173.136)
05:31.40*** join/#brlcad Stattrav (~Stattrav@117.192.144.40)
05:31.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:38.06*** join/#brlcad adityag (~ADITYA@182.237.144.88)
07:57.45*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
08:06.12*** part/#brlcad adityag1 (~ADITYA@182.237.144.88)
08:51.19*** join/#brlcad ibot (~ibot@rikers.org)
08:51.19*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 ETA 20110401 || Welcome GSoC 2011 Students! Speak up, ask questions, start here: http://brlcad.org/wiki/Google_Summer_of_Code/2011
09:35.31*** join/#brlcad adityag (~ADITYA@182.237.144.88)
09:40.20*** join/#brlcad adityag1 (~ADITYA@182.237.144.88)
10:08.34*** join/#brlcad mafm (~mafm@49.Red-83-38-34.dynamicIP.rima-tde.net)
10:14.21*** join/#brlcad kunigami (~kunigami@187.21.173.136)
10:15.57*** join/#brlcad kunigami (~kunigami@187.21.173.136)
10:46.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:04.39*** join/#brlcad kunigami (~kunigami@187.21.173.136)
11:18.18*** join/#brlcad adityag (~ADITYA@182.237.144.88)
11:18.37*** part/#brlcad adityag (~ADITYA@182.237.144.88)
11:31.06*** join/#brlcad kunigami_ (~kunigami@187.21.173.136)
11:40.31*** join/#brlcad mafm (~mafm@49.Red-83-38-34.dynamicIP.rima-tde.net)
11:47.11*** join/#brlcad kunigami_ (~kunigami@187.21.173.136)
11:53.17*** join/#brlcad kunigami_ (~kunigami@187.21.173.136)
11:57.48*** join/#brlcad kunigami (~kunigami@187.21.173.136)
11:59.18*** join/#brlcad kunigami__ (~kunigami@187.21.173.136)
12:19.50*** join/#brlcad kunigami (~kunigami@187.21.173.136)
13:18.31*** join/#brlcad merzo (~merzo@13-137-133-95.pool.ukrtel.net)
13:30.56*** join/#brlcad merzo (~merzo@13-137-133-95.pool.ukrtel.net)
14:05.49*** join/#brlcad adityag (~ADITYA@182.237.144.88)
14:10.32*** part/#brlcad adityag (~ADITYA@182.237.144.88)
14:36.37*** join/#brlcad Stattrav (~Stattrav@117.192.129.27)
14:36.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:53.00*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
16:01.33*** join/#brlcad mafm (~mafm@49.Red-83-38-34.dynamicIP.rima-tde.net)
16:10.54*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
16:10.54*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
16:10.54*** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
16:27.05*** join/#brlcad mafm (~mafm@49.Red-83-38-34.dynamicIP.rima-tde.net)
16:27.11*** join/#brlcad dtidrow (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
16:48.33*** join/#brlcad adityag (~ADITYA@182.237.144.88)
16:48.38*** part/#brlcad adityag (~ADITYA@182.237.144.88)
18:22.33*** join/#brlcad mafm (~mafm@83.38.34.49)
IRC log for #brlcad on 20110411

IRC log for #brlcad on 20110411

00:29.23*** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net)
01:11.40*** join/#brlcad crazy_imp (~mj@a89-182-208-255.net-htp.de)
03:26.39*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
03:33.43*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680483.dsl.bell.ca)
04:36.10*** join/#brlcad stevegt` (~stevegt@cislunar.TerraLuna.Org)
07:31.23*** join/#brlcad Stattrav (~Stattrav@122.172.5.31)
07:31.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:49.21*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
09:09.48*** join/#brlcad mafm (~mafm@132.Red-81-35-69.dynamicIP.rima-tde.net)
09:25.05CIA-105BRL-CAD: 03jordisayol * r44293 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): Properly handle errors during GNU/Linux packages building.
13:09.49dlomanyawns
13:10.03*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
13:22.32brlcadresists the yawn
13:23.00brlcadtotally bummed though
13:23.03brlcadno furlough
13:23.33dlomanhad two big brown eyes staring at me starting at 0100. Youngest wouldn't sleep!
13:23.59dlomanheh, speak for your self.  I still have a paying job because of 'no furlough' ;)
13:37.38``Erikvacation woulda been nice O.o
13:37.57dlomanstill a chance for it :)
13:37.59``Erikbrlcad: migration? accounts?
13:54.32dlomanbrlcad: was looking at VLB over the weekend and saw that a bu_vlb_write() call could potentially trigger a bu_realloc().  In order to know this ahead of time, the caller would need to know both the vlb's 'nextByte' and 'capacity'.  bu_vlb_buflen serves to get the 'nextByte' but there's nothing for capacity.  I was thinking about adding a bu_vlb_capacity() and/or bu_vlb_remaining() functions.  Comments/concerns/tips ?
13:58.40``Erikthe struct is public and the math is trivial O.o
14:00.00``Erikiirc, vlb's default to 4k 'chunks', so that's a straight up page mapping, quick and cheap on linux (not on fbsd/mac)
14:01.20brlcaddloman: sounds good to me
14:01.36brlcadshould make the function name mirror the vls api, though
14:01.46dlomannods
14:04.51brlcadvery curious that you'd need to know the size, though -- the mechanism by which the bytes are stored is supposed t be a black box
14:05.14brlcadcould be a bu_list of individual bytes, for example, or some c++ construct or a static buffer
14:05.33dlomanwas looking at vlb_write and saw that there is a possiblity of a realloc
14:05.55dlomanand without knowing capacity a head of time, you'll never know if that realloc will happen or not.
14:06.01brlcadso?
14:06.07brlcadanything that adds bytes is going to be a potential realloc
14:06.18brlcadpart of the black box
14:06.36dlomanwould exposing the capacity break the black box mindset?
14:06.54brlcadpretty much
14:07.04dlomanokie
14:07.15brlcadstill, what does the realloc matter?
14:07.17``ErikI think it's more "why do you care?" O.o reallocs aren't terribly slow on occasion
14:07.27``Erikpremature optimization? O.o
14:08.14dlomanjust trying to think ahead ;)
14:08.37brlcador "a little knowledge is dangerous"
14:09.05brlcadstd::string foo = "hello"; foo += "world"; may or may not cause a realloc too
14:09.16brlcadyou don't know, shouldn't care -- vlb is the same
14:09.23dlomanokie
14:10.28``Erik(no forward motion on the server? I'm out today, thought maybe I could start a system update and get some stuff installed)
14:10.59dlomanis bug fixing and generally de-stupifying things.
14:12.44brlcad``Erik: noted, i'll create your account
14:13.01brlcadcontext switch thrashing a bit at the moment
14:19.49brlcad``Erik: gmail
14:20.45brlcadwas leaving those default passwords until accounts got migrated
14:22.27brlcadso the coverity scan is really frelling awesome
14:33.41CIA-105BRL-CAD: 03starseeker * r44294 10/geomcore/trunk/src/libgvm/ (files.c objects.c): Hrm. Something strange - simply calling gvm_obj_in_model was enough to cause a crash - reorganizing the initializations in gvm_object_in_model was enough to make things work.
15:03.58brlcadif anyone is interested in actually working on fixing coverity bugs, let me know with an e-mail address to provide so I can get an account created (let me know via e-mail or PM)
15:05.00brlcadplease don't bother if you're just interested or want to peek at results, rather not waste david's time
15:05.09brlcador mine for that matter
15:05.33brlcadhere's what some of the results look like, though:
15:06.17brlcadhttp://brlcad.org/tmp/cov1.png   <-- detected potential null dereference
15:06.31brlcadhttp://brlcad.org/tmp/cov2.png  <-- security issues
15:07.20brlcadhttp://brlcad.org/tmp/cov3.png  <-- more elaborate (and awesome) detection of potentially uninitialized data being used
15:07.44dlomanneato.
15:07.47dlomanthat a pay service?
15:07.54brlcadjust a sample of the 2k or so issues reported
15:08.12brlcadit's paid for, but not something we're paying for
15:08.52brlcadDHS funded an initiative a few years ago to evaluate (and improve) security of open source software
15:09.03dloman=D
15:09.04dlomannice
15:09.40dlomanso its "free"  =D
15:10.47brlcadI applied and we were one of the first to get added to the scan ladder (when there were only a couple dozen being scanned), but our scan (of an old version) got stuck on a build failure in src/other
15:11.05brlcadwasn't fully resolved until the past friday
15:11.55dlibrlcad, I can have a look on the coverity bugs, not sure how hard it is to fix them, without collateral damage at least
15:12.28dlibrlcad, do you have some examples for me to digest
15:12.39brlcaddli:  just screenshotted three :)
15:13.36dlibrlcad, too bad. :( no text report?
15:14.04brlcaddli: what do you mean?
15:14.41brlcadthere's a full-blown website around the report generated, pretty sure there are export options too -- but the website lets you manage the issues so you know which ones are fixed and which are not
15:15.10brlcaddli: can you not view images at the moment or something?
15:15.39dlibrlcad, of course, I can view images
15:16.26brlcadthen what's the "too bad"?
15:17.34dlibrlcad, I expected a list with file locations, line numbers, and explanation of findings, etc.
15:20.17dlihttp://scan.coverity.com/all-projects.html
15:20.26dlinot found
15:21.28brlcaddli: it has that list of files, explanations and a lot more
15:21.36brlcadthe screenshots show three specific bugs
15:22.37brlcadI can dump out the various reports (there are many, all configurable) as csv, but that's not really effective for fixing them collaboratively
15:22.49dlibrlcad, found, 178,135 lines, that will take ages to fix :(
15:23.10brlcaddli: that's the stalled scan
15:23.18brlcadthat webpage hasn't been updated in years
15:23.39brlcadit found 690,667 lines
15:23.41dlibrlcad, so, I have to sign in to get updated
15:24.00brlcadthat's lines of code analyzed, not # issues
15:24.15brlcadit found 1892 issues, 700 of which are like cov2.png
15:24.24CIA-105BRL-CAD: 03starseeker * r44295 10/geomcore/trunk/ (4 files in 2 dirs): Ah, there we go - got changes committed to the repository. Approaching full parity with the old svnTest example.
15:25.05dlibrlcad, a link for cov2.png?
15:25.26brlcadpoints up
15:26.45brlcadthose where the screenshots I mentioned
15:27.50dlibrlcad, to fix like sscanf(), we use atof(), etc., right?
15:33.13brlcaddli: it depends, strtol/strtod with manual string parsing or regexp parsing are generally more robust to sanitizing input
15:33.55starseekerbrlcad: in that case, should we pre-package some regex logic for the common parsing cases?
15:33.56brlcadpreferred over the ato*() family of functions because they don't report error
15:35.41dlibrlcad, but the idea is to replace all sscanf(), rather than trying to keep sscanf() safe by limiting buffer size, etc
15:35.44brlcadstarseeker: bu routines that get values from strings would be useful (however the underlying mechanism does it)
15:36.41brlcaddli: to best solve the problem, yes
15:36.56brlcadthe quickest solution is to just add precision specifiers like the comment states
15:37.33brlcaddepending on how many there are, that could be a first step or could be skipped in leu of an API solution
15:39.47dlibrlcad, I think I can help fixing the issues here
15:40.12brlcade-mail me a username and an e-mail to give the coverity guys
15:41.18dlibrlcad, using the sean address in topic?
15:43.15dlibrlcad, sent
15:45.37brlcadthx
15:47.50dlibrlcad, I will ask about ideas before actually fixing anything, my biggest fear is still the collateral damages :)
15:48.19brlcadokay, no worries
15:49.25brlcadi'll mostly be concerned with people actually using the coverity website when bugs are fixed so we don't get people wasting time looking into issues that have already been solved
15:49.35brlcadso using the various status markers they provide
15:49.41brlcadinspected, uninspected, fixed, etc
15:51.31dlibrlcad, right, with so many lines to check, need an way to assign/partition
15:54.07CIA-105BRL-CAD: 03starseeker * r44296 10/geomcore/trunk/src/libgvm/gvm.h: Nevermind these functions - handled in a couple for loops. Add them later if needed.
15:54.07brlcadnods
15:54.41brlcadsome are downright trivial to fix, some are downright tricky logic
16:09.00*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
16:26.24CIA-105BRL-CAD: 03starseeker * r44297 10/geomcore/trunk/src/libgvm/ (files.c gvm.h objects.c): Clear out a few more functions of dubious utility, assing some names to the commit actions.
16:37.35CIA-105BRL-CAD: 03starseeker * r44298 10/geomcore/trunk/tests/func/gvmtest/main.c:
16:37.35CIA-105BRL-CAD: Add a test to create an empty repo. May need to add one additional parameter to
16:37.35CIA-105BRL-CAD: all these functions - the ability to pass a local subpool (presumably as a void
16:47.56CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2821 10/wiki/Main_Page: add a section on code cleanup
16:55.19CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2822 10/wiki/Code_Cleanup: stub in initial page, link to HACKING
17:01.01CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2823 10/wiki/Code_Cleanup: coverity section
17:05.19CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:CoverityExample1.png]]": Example Coverity scan issue showing a potential (albeit unlikely) NULL dereference
17:25.24CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:CoverityExample2.png]]": Coverity analysis showing secure coding practice suggestions
17:27.48CIA-105BRL-CAD: 03starseeker * r44299 10/geomcore/trunk/src/libgvm/objects.c: Er, oops - need a textdelta if we're going to add content...
17:27.49CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:CoverityExample3.png]]": Coverity analysis showing an elaborate detection of a variable being used that was potentially uninitialized
17:28.47CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2827 10/wiki/Code_Cleanup: link in the images and site
17:29.55CIA-105BRL-CAD: 03starseeker * r44300 10/geomcore/trunk/src/libgvm/objects.c: Use the gvm_info_clear_objects function
17:31.18CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2828 10/wiki/Code_Cleanup: add a section on code reduction and using simian
17:31.19CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2829 10/wiki/Code_Cleanup: swap the order so lays out better
17:33.14CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2830 10/wiki/Code_Cleanup: add an example of the output
17:35.46CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2831 10/wiki/Code_Cleanup: break the long line
17:46.46CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2832 10/wiki/Code_Cleanup: add one more section on strict compilation, yay TOC
17:50.47CIA-105BRL-CAD: 03davidloman * r44301 10/geomcore/trunk/CMake/FindCppUnit.cmake: Check in a quick n dirty cmake find module for finding CppUnit
17:53.48CIA-105BRL-CAD: 03davidloman * r44302 10/geomcore/trunk/ (4 files in 4 dirs): Setup cmake to find CppUnit if the UnitTests are enabled. Split out subdirectory addition for Functional and Unit test dirs. Stub in unit test dir CMakeList.txt
18:06.05*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680483.dsl.bell.ca)
18:10.32*** join/#brlcad Stattrav (~Stattrav@117.192.144.22)
18:10.32*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:04.39*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680483.dsl.bell.ca)
19:14.17*** join/#brlcad mafm (~mafm@132.Red-81-35-69.dynamicIP.rima-tde.net)
19:27.46starseekerhah - Manassas, Virginia
19:43.47CIA-105BRL-CAD: 03davidloman * r44303 10/geomcore/trunk/tests/unit/ (4 files in 2 dirs): Wire in CppUnit to cmake build. Added a sample cmake unit test that will eventually be ByteBuffer's Unit Test.
19:47.33CIA-105BRL-CAD: 03davidloman * r44304 10/geomcore/trunk/ (3 files in 2 dirs): Implement ByteBuffer. Combines the functionality of ByteArray and DataStream, since those were mostly redundant. ByteBuffer is backed by a bu_vlb and, at this point, is completely untested.
19:57.19CIA-105BRL-CAD: 03starseeker * r44305 10/geomcore/trunk/src/libgvm/TODO: Add a TODO for libgvm
20:16.54``Erikhrm?
20:26.21starseeker``Erik: Tcl/Tk conference this year is in Virginia
20:30.30``Erikah, roger
20:40.14*** join/#brlcad Stattrav (~Stattrav@117.192.144.22)
20:40.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:41.17brlcadperfect nearby location for a presentation or three
20:44.34brlcad``Erik: login worked?
21:03.31*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:05.53brlcadstarseeker: did you make red delete or keep the original if the user edits the object name?
21:06.28starseekeruh... I thoght I made it delete the original, but not sure
21:06.48brlcadokay
21:07.18brlcadi was thinking about the usability implications of both and intent
21:09.01brlcadgiven cases where both might be expected, I'm thinking it'll be safer to err on keeping the original
21:09.32starseekermake it a cp, instead of a mv?
21:09.43brlcadbasically
21:09.50starseekerthat kind of violates the paradigm of "changing this object" we're using with red
21:10.03starseekerthe fact we use a temp copy is an implementation detail, after all
21:11.00brlcadthe tradeoff is make those expecting copies having to cp first vs. those expecting rename having to rm after
21:12.19brlcadthat's only if you expect red to "change this object" ... I can just as easily see someone pulling up the text editor, and expecting the name change to mean "give me a copy using that object's values"
21:12.55brlcadmore than likely with some value(s) changed
21:13.12starseekeras opposed to every other parameter in the text editor changing the original object?  dunno, seems a bit inconsistent (not to say someone wouldn't expect it...)
21:13.16brlcadbasically boils down to cp+ed vs ed+rm
21:14.05brlcadi'm not sure someone wouldn't expect it frankly
21:14.10brlcadthere are good use cases for both
21:14.41brlcadand every other param wouldn't change the original, it applies to that copy
21:15.18brlcadyou wouldn't edit the original AND make a copy .. that'd just be wrong
21:15.39CIA-105BRL-CAD: 03starseeker * r44306 10/geomcore/trunk/ (3 files in 2 dirs): Grrrrr. Can't get recursive assembly to function. Am I hitting some issue with pool memory size or something?
21:15.55starseekeroh, I agree - I just was thinking in the paradigm of "if you red an object, you're working on that one object. Period"
21:16.06brlcadit's the intent of changing the object name, did they mean rename or did they mean make me a new one based on the original
21:17.22brlcadthe other consideration is that even if they are thinking that way, that it should rename the original .. the only surprise is that the original object is still there and they have to manually delete it
21:18.13brlcadif they're thinking the other way, that it should make a copy .. then much to their surprise, the original is deleted (along with the destruction of any original values they maybe still wanted)
21:19.26starseekercould make two commands - red and rcp
21:19.27brlcadthat alone is pretty strong case for not deleting, maybe adding a flag to red to force one behavior
21:20.09starseekeryeah,  I suppose until we have undo support not deleting is safer
21:23.15brlcadof course, copy or move behavior will have to check if that object name already exists, and similarly abort (unless there's a force flag)
21:24.21brlcadah, and I see you already have code for that, excellent
21:27.05brlcadhm, what's a similar command that has cp/mv options
21:36.25*** join/#brlcad yiyus (1242712427@je.je.je)
21:42.42CIA-105BRL-CAD: 03starseeker * r44307 10/geomcore/trunk/src/libgvm/ (files.c models.c): OK, that worked. Wasn't cleaning up after myself. See if I can put the content assignment back.
21:45.18CIA-105BRL-CAD: 03starseeker * r44308 10/geomcore/trunk/src/libgvm/ (files.c models.c): Yep, that was it - just needed to clear the list.
22:24.29*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
22:40.06brlcadhello KimK
22:40.39KimKHi brlcad, how's it going?
22:40.47brlcadpretty great!
22:41.00KimKHa, excellent
22:44.21KimKYou might be interested to know that I have now managed to install BRL-CAD on several machines, one defeated me, I'll look into that one again on a return visit there. Unfortunately, I'm no smarter on operating BRL-CAD yet, but I have stumbled across some tutorials, I hope to have time to work on those.
22:48.16brlcadKimK: outstanding
22:48.30brlcadyeah, the tutorials on the main website (under Documentation) is really the place to begin
22:48.49brlcadseveral of the documents listed there are very helpful for learning the basics
22:55.40KimKI have been trying to get the Ubuntu menu to start BRL-CAD. The LibreOffice-dev group has a similar problem, they start scripts to start the locally-built development versions. A developer friend gave me a little bash trick to put in the Ubuntu menu command to start them, example:  bash -c 'cd /home/username/libo/install/program; ./swriter'  But I haven't been able to apply it in the expected ways to start mged, I don't know what's up with that
22:55.40KimK.
22:56.00KimKBah, flooded by one, need a character counter, lol!
22:57.56brlcadKimK: hm.. in more recent versions jordi sayol has menu and icons working for fedora and debian
22:58.23brlcadmight check out the .deb to see how he did it
22:58.41brlcad(it's not in apt, it's up on the website)
23:00.15KimKMore recent as in your development version? OK, no problem, I only installed from the 7.18 tarball. Do you guys have a git repo yet?
23:00.32brlcad7.18.2
23:00.43KimKOK, 7.18.2
23:00.51brlcadno plans to move from svn to git any time soon
23:01.46KimKOh, you're on svn? Maybe I can use "git svn". (Git is really nice.)
23:01.58brlcadquite familiar with git
23:03.01KimKExcellent, maybe git will be an option someday and you can advocate for it?
23:04.57brlcadif a revision control system needs advocating, then it's not mature enough yet for our use
23:06.01brlcaddidn't advocate for cvs when switched from rcs, didn't advocate for svn when switched from svn ... the benefits were clear and downsides non-existent
23:06.22brlcadgit doesn't have that case yet, several downsides
23:06.44brlcadmaybe someday, but then maybe svn will have those features by then too or maybe some other system will have stepped up
23:08.00KimKWhat do you see as the downsides of git? Is svn in the group of one-repo cvs's, is that the issue?
23:08.31brlcaddon't understand the second question
23:09.29KimKwell, some are bothered by the idea that there's no "official central repo" in git (except by agreement or convention).
23:09.53KimKAny repo is equal to any other repo.
23:09.58brlcadthat could be seen as a downside (or a benefit), depending on the community
23:11.57brlcadthere are social impacts that are pretty extensively discussed, potential for community fragmentation, potentially increase in antisocial behavior (comparitively, since collaboration isn't forced)
23:12.14brlcadpractical downside is the windows support, but that's improving
23:13.12brlcadthe fact that it's a relatively new version control system, not nearly as extensively tested due to age alone
23:14.21KimKThe EMC2 group hasn't had fragmentation problems that I have observed. They do have an agreed central repo. I would put decentralization in the benefit category, especially when there are internet connectivity issues, as might be expected more frequently now. (Earthquakes, tsunamis, sunspots, disasters, emp, what-have-you.)
23:14.40brlcadsize of repo clone compared to checkout requires increased disk (particularly for large histories)
23:15.09brlcadthat's a bit ridiculous imho :)
23:15.21KimKEase of anyone browsing full history might be helpful?
23:15.24brlcad"might be expected more frequently now" .. no more or less than before unless people are just ignorant of the planet :)
23:16.16brlcadI think I can count on one hand how many times I've been offline and needing to commit over the past five years
23:16.40brlcadthat would be a benefit, but it's minor (and it's also something that svn is working to implement too)
23:16.52brlcadin the end, I think the systems will become so hybridized that it just won't matter
23:17.47brlcadin which case, a central repo that can be distributed would win over a distributed repo pretending to be central
23:18.01brlcadbut that's many many years out, of course
23:18.52KimKWell, git does have an impressive array of projects, even if you discount the Linux kernel one. (Admittedly some bias there, lol.)
23:19.05brlcadthe point about switching, though, was that up until now, it's been very clear and strong benefits with NO downsides ... that's simply not the case quite yet
23:19.12brlcadpopularity means nothing
23:19.56brlcadgit tends to be the most vocal but by far not the most popular yet, last estimate I saw had it at maybe 20% (across industry)
23:20.16brlcadcourse stats can be fudged to show just about anything :)
23:20.49KimKWell, not completely nothing, it means that some groups saw an advantage to switching (to whatever).
23:21.12brlcadthe fact that the benefits and downsides have to be weighed means it's closer to a wash .. which would simply be busy work right now
23:21.19brlcadnot solving any specific problem we're having
23:21.36KimKYes, well, you guys do have your hands full.
23:21.54KimKHope it's going well, generally?
23:22.01brlcadit solves a big problem when the dev team scales beyond a communication point
23:22.05brlcadgit, that is
23:22.40brlcadthat point is around 50-100 active developers, if I recall correctly
23:23.41KimKDue to its history, are most brlcad developers in the US? I think that makes a difference too.
23:23.42brlcadI did the math a couple years ago, but it's basically the point at which NxM communication points slow down development where having a distributed infrastructure lets you have islands of communication
23:24.33KimKNot in the US, but in the same time zone, makes chatting difficult, or at least delays email.
23:24.34brlcadi don't think that makes any difference -- same issue with other communities I work with that are predominantly non-US
23:25.24brlcadif you have active devs, then the method and time of communication plays only a minor part .. they're reading logs, mailing lists, whatever
23:25.28brlcadimpact is minimal
23:25.53brlcadit's the point at which there is too much activity, too many devs to have centralized communication
23:26.08brlcadthat's the 50-100 dev metric
23:26.19brlcadthat's why it was dead-obvious for linux
23:26.27brlcadhundreds of active devs
23:27.40KimKOK. Well, hopefully brlcad will continue to grow and you'll have more developers too.
23:27.55brlcadyeah, that's a problem I'd LIKE to have ;)
23:28.42KimKHaha, you'll get there.
23:37.55brlcadstarseeker: on further inspection, red will also *create* a new combination (from nothing) .. so that seems even more pertinent that the editing intent is "write an object I've named with these values" and the in-editor object name might simply be them changing their mind on that name
IRC log for #brlcad on 20110412

IRC log for #brlcad on 20110412

00:28.21starseekerbrlcad: sounds good
01:09.49brlcadwoo hoo, got a full-blown red regression test working
01:12.22*** join/#brlcad crazy_imp (~mj@a89-182-220-92.net-htp.de)
02:04.40brlcadthe bad news is that it's failing the regression test pretty hard
02:58.02*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
03:55.13*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
04:18.30*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
04:43.40``Erik*readreadread* git? bah, darcs ftw
05:51.25CIA-105BRL-CAD: 03brlcad * r44309 10/brlcad/trunk/regress/red.sh: add an extensive test of the mged 'red' command due to repeat failures. regression unveils at least 11 other bugs, quality, and robustness issues still remaining.
05:52.10CIA-105BRL-CAD: 03brlcad * r44310 10/brlcad/trunk/regress/Makefile.am: add a 'red' rule to run the new red regression test, but don't add it to the release regression due to all of the bugs
05:57.47CIA-105BRL-CAD: 03brlcad * r44311 10/brlcad/trunk/src/libged/red.c: add a -f force flag to forcibly overwrite a pre-existing comb if the new name would result in an existing object getting overwritten. also fixed a memory free crash bug if final_name is NULL.
06:09.46CIA-105BRL-CAD: 03brlcad * r44312 10/brlcad/trunk/src/libged/red.c: blather a strong warning since several data-destructive bugs are now confirmed, but not enough time to fix before release. hopefully better to warn than disable since some use cases are fine.
06:10.54CIA-105BRL-CAD: 03brlcad * r44313 10/brlcad/trunk/TODO: red no longer show-stopper, but still needs to be fixed.
06:11.51*** join/#brlcad Stattrav (~Stattrav@122.172.5.31)
06:11.52*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:14.11*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
06:17.45CIA-105BRL-CAD: 03brlcad * r44314 10/brlcad/trunk/src/libged/red.c: one sec is probably plenty
07:20.34*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:31.32*** join/#brlcad mafm (~mafm@85.Red-83-50-132.dynamicIP.rima-tde.net)
09:36.07starseekerbrlcad: nice work on the red regression
09:36.22starseekersigh - at this rate, I should get to NURBS around August
10:54.47*** join/#brlcad mafm_ (~mafm@85.Red-83-50-132.dynamicIP.rima-tde.net)
13:51.51CIA-105BRL-CAD: 03starseeker * r44315 10/geomcore/trunk/src/libgvm/files.c: Yes. Handle the global attribute values.
14:24.35*** join/#brlcad crazy_imp (~mj@a89-182-220-92.net-htp.de)
14:30.13CIA-105BRL-CAD: 03starseeker * r44316 10/geomcore/trunk/src/libgvm/TODO:
14:30.13CIA-105BRL-CAD: Undoubtedly there's a lot of polishing, API refactoring, and error checking to
14:30.13CIA-105BRL-CAD: do still - however, the core features of .g file breakup, committing,
14:56.28starseekerdloman: if you're around, could you take a look at the current state of libgvm?
14:57.40starseekerIt needs robustness testing (with near-certain bug repairs), error handling, etc. but the key abilities are there now, so if it doesn't look too daunting I'd like to toss it over to you and tackle some helpdesk stuff (search, etc...)
15:16.44CIA-105BRL-CAD: 03erikgreenwald * r44317 10/geomcore/trunk/src/interfaces/cl/ (gvm.asd gvm.lisp): libgvm cffi
15:32.38brlcadstarseeker: did you run it?
15:33.24brlcadstarseeker: as long as you get to (and finish) nurbs before october, we're good ;)
15:40.46dlomanstarseeker: Im kinda around today.  I'll take it from here if you need/want to get moving back to NURBs.
16:27.00CIA-105BRL-CAD: 03brlcad * r44318 10/brlcad/trunk/ (NEWS include/conf/PATCH): beginning final release steps for 7.18.4, bump patch
16:31.22CIA-105BRL-CAD: 03brlcad * r44319 10/brlcad/trunk/ChangeLog: update changelog for 7.18.4
16:51.13starseekerbrlcad: run the regression?  not yet
16:51.41brlcadok, just wondering
16:56.05starseekerdloman: cool, thanks - let me know if you have any questions
16:56.32starseekerbrlcad: I'll take a poke at it today - wanted to get those last two things working for dloman
17:01.47starseekerbrlcad: did you want to revert the search changes for the release?  I'm not using them in the gvm code anymore so we could probably get away with that
17:05.38CIA-105BRL-CAD: 03brlcad * r44320 10/brlcad/trunk/NEWS: typo
17:19.45CIA-105BRL-CAD: 03starseeker * r44321 10/brlcad/branches/cmake/ (31 files in 15 dirs): MFC r44320
17:28.12CIA-105BRL-CAD: 03Kunigami 07http://brlcad.org * r2833 10/wiki/User:Kunigami: Initial load
17:30.05CIA-105BRL-CAD: 03Kunigami 07http://brlcad.org * r2834 10/wiki/User:Kunigami:
17:30.55CIA-105BRL-CAD: 03Kunigami 07http://brlcad.org * r2835 10/wiki/User:Kunigami:
17:38.44*** join/#brlcad PrezKennedy (MK@whitecalf.net)
17:45.53brlcadstarseeker: I'm about to tag, so probably not :P
17:46.10starseekerah, k :-)
17:55.12brlcadhttp://www.siam.org/meetings/gdspm11/
17:55.18brlcaddeadlines approaching for submission
17:55.27CIA-105BRL-CAD: 03erikgreenwald * r44322 10/brlcad/trunk/src/other/libpng/Makefile.am: add an empty depends rule
17:57.55CIA-105BRL-CAD: 03brlcad * r44323 10/brlcad/branches/STABLE/ (30 files in 15 dirs): merge trunk to STABLE from r to HEAD r
17:59.26brlcadthat wasn't very informative
18:00.15starseekerhas flashbacks
18:04.58CIA-105BRL-CAD: 03brlcad * r44324 10/brlcad/trunk/HACKING: requesting a specific log revision, -rHEAD, results in empty output so don't use it
18:15.30CIA-105BRL-CAD: 03brlcad * r44325 10/brlcad/branches/STABLE/ (7 files in 5 dirs): merge trunk to STABLE from r44240 to HEAD r44324 ... not really, but previous branch commit had bad log message. should be up-to-date wrt r44324
18:23.27CIA-105BRL-CAD: 03brlcad * r44326 10/brlcad/tags/rel-7-18-4/: tag release 7.18.4
18:26.28CIA-105BRL-CAD: 03brlcad * r44327 10/brlcad/trunk/HACKING: add diagnostic lines to echo the PREV and CURR values so we know if anything changes
18:36.49CIA-105BRL-CAD: 03starseeker * r44328 10/brlcad/branches/cmake/ (HACKING src/CMakeLists.txt src/other/libpng/Makefile.am): MFC r44327
18:41.00CIA-105BRL-CAD: 03brlcad * r44329 10/brlcad/trunk/ (NEWS README include/conf/PATCH): final testing of source tarball under way, bump to 7.18.5 in anticipation of 7.18.6 next month.
18:55.20starseekerblinks... can it be that simple??
18:56.23*** join/#brlcad PrezKennedy (MK@whitecalf.net)
18:58.31CIA-105BRL-CAD: 03starseeker * r44330 10/brlcad/trunk/src/libged/search.c: This needs more testing, but search . and the conversion.sh script seem to run with this change...
19:02.59starseekerbrlcad: looks like search . and search / are back
19:04.40starseekerwhen you say "relative searching" in the search TODO item, how is search ./havoc -type r different from search . havoc -type r ?
19:08.29brlcadwell the latter is invalid syntax, for one ;)
19:11.02brlcad"search ./havoc -type r" is the same as "search havoc -type r" as they are both relative paths, but different from "search /havoc -type r"
19:13.38brlcadfortuantely, any string of ./ and ../ prefixes can probably be ignored since the top-level namespace scope has no parent
19:14.35brlcadthe more imporant feature is being able to specify relative subpaths at all, "search havoc/weapons -type r" to get a list of regions under weapons
19:15.05brlcadoperationally equivalent to "search weapons -type r" unless/until operators are added that are matrix-sensitives
19:16.24brlcadso it should be possible to just determine if it's absolute (starts with /) or not, if it's not, then walk the basename object
19:19.47*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
19:19.56brlcadthat was a painful release
19:22.33starseekerhow is it invalid syntax?  search uses . and / to select whether to report a list of objects or full paths
19:22.41``Erikhm, should "search . havoc -blah" invalid? if we model on find, it'd be silly but valid... I could see wanting to specify several trees in one line.. "search leftwing rightwing -name *fuel*'
19:23.00starseekerthe latter will work now
19:23.04starseekerbut will return full paths
19:24.08starseekeroh, conceptual mismatch.  The way I have it implemented now, the leading . and / have nothing to do with the paths
19:24.32starseekerthey might as well be -l and -f (list and fullpath)
19:26.11starseekerum.  I'm not sure how matrix sensitive operations would work with the current find logic
19:27.29starseekerbrlcad: if I understand you, you're expecting search havoc -type r to return a list, not full paths?
19:39.01brlcadoh, my bad -- I actually didn't know/remember that search/find supported multiple paths .. nifty!
19:40.08brlcadand yes, I'd expect a relative path (including plain object names) to return a list, not paths .. prefix it with a / and you get paths
19:40.12brlcadconsistent, simple
19:40.16brlcadno new options
19:41.18starseekererm
19:42.03starseekerthat introduces a new problem - if I mix them, e.g. seach /obj1 obj2 do I then get back a mixed full path/list result?
19:42.38starseekerthe . and / have the merit of being unambiguous in that respect
19:42.39brlcadthat'd be the impliciation -- if technically infeasible, could just detect and abort
19:44.39brlcadwith 'find', having '.' and '/' return paths (relative and absolute respectively), everything works out fine because we're working with a hierarchy and paths are paths
19:45.39brlcadfor search, it's a bit more complicated since we're searching over a graph -- there would be no useful difference between '.' and '/' like there is with find since a "relative" geometry path means nothing useful
19:46.21brlcadthat's the motivation for "make it useful" since the most common operation is "i'm looking for a list of objects matching my criteria"
19:46.38brlcadnot paths, lists -- so hijack the otherwise useless relative option on search
19:48.15starseekerponders...
19:48.17brlcadI mean, you could make them both work identically, but post-process each path set afterwards (basename+uniq for relative path sets)
19:48.43starseekerthe simplest way to mix results would be to run one search per path and accumulate the results, but that means n searchs for n arguments
19:49.04brlcadsounds reasonable
19:49.26brlcadlets you sort/filter each path set independently so you can return paths and non-pathed lists as one set
19:49.59brlcadif they ran "search . /" you'd basically get a list of all objects followed by a list of all paths
19:52.36starseekerdo we have any kind of "canonicalization" routine for db paths?
19:53.12starseekere.g. /havoc/. -> /havoc?
20:08.19*** join/#brlcad crazy_imp (~mj@a89-182-220-92.net-htp.de)
20:10.13brlcadthe default posix / bsd one should work
20:10.27brlcadit just looks at the string, not the filesystem
20:10.40brlcadwe call it in a couple places to reduce paths
20:11.44brlcadsupports harder cases like /havoc/weapons/../fuel_system/lt_fuel/../../fuel_system/. -> /havoc/fuel_system
20:12.11brlcadrelease is now posted and notified
21:17.50starseekerexcellent!
21:18.15starseekerpwd
21:18.17starseekerwhoops
21:20.53CIA-105BRL-CAD: 03starseeker * r44331 10/brlcad/trunk/src/libged/search.c: Take a stab at using . and / prefixes to denote lists or full paths. This is a significant change to the search syntax and functionality, needs testing. Doesn't yet use the canonical logic to simplify paths.
21:27.28CIA-105BRL-CAD: 03erikgreenwald * r44332 10/geomcore/trunk/src/interfaces/cl/gvm.lisp: add test function
21:28.08starseekerbrlcad: let me know if that does what you want
21:29.49CIA-105BRL-CAD: 03erikgreenwald * r44333 10/geomcore/trunk/src/interfaces/cl/brlcad.lisp: add some callback stuff. Start a facetize function.
21:33.00CIA-105BRL-CAD: 03starseeker * r44334 10/brlcad/trunk/src/libged/search.c: While I'm at it, fix the print order of the results - toplevel first, then children.
21:43.20*** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net)
22:39.17CIA-105BRL-CAD: 03starseeker * r44335 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r44334
23:44.51CIA-105BRL-CAD: 03starseeker * r44336 10/brlcad/trunk/ (include/bu.h src/libbu/vls.c src/libged/search.c): Try some scrubbing on user supplied paths. Not sure this is correct yet, but it does handle some cases.
23:48.29starseekerbrlcad: ok, I think the search command is ready for you to see what's still broken :-P
IRC log for #brlcad on 20110413

IRC log for #brlcad on 20110413

00:47.47*** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
01:12.23*** join/#brlcad crazy_imp (~mj@a89-183-84-47.net-htp.de)
03:08.37*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca)
03:32.26*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca)
03:33.21*** join/#brlcad Stattrav (~Stattrav@117.192.154.227)
03:33.21*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
04:14.05*** join/#brlcad Stattrav (~Stattrav@117.192.154.227)
04:14.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
04:44.42*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
05:14.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:26.36brlcadoutstanding, already an rtwizard failure reported
07:10.21*** join/#brlcad merzo (~merzo@193.254.217.44)
07:21.29*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
07:57.58*** part/#brlcad epileg (~epileg@unaffiliated/epileg)
08:09.33*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:18.57*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
10:04.11dlomanMernin
10:11.32*** join/#brlcad mafm_ (~mafm@233.Red-83-54-181.dynamicIP.rima-tde.net)
12:01.12d_rossberger, src/libged/search.c tries to access a non-existent "local" member of struct db_full_path_list
12:33.14CIA-105BRL-CAD: 03davidloman * r44337 10/geomcore/trunk/tests/unit/test_runner.cxx: Update test_runner.cxx with header and footer. Make console printing a tad prettier.
12:37.26CIA-105BRL-CAD: 03davidloman * r44338 10/geomcore/trunk/CMakeLists.txt: Add in check to root CMakeLists.txt that tests if CppUnit has been found or not. If not, configuration of the unit tests will not occur and a message will be printed to the console instead of a cmake failure.
12:38.07starseekerd_rossberg: whoops - maybe I didn't check in the header change
12:38.09starseekerlet me check
12:40.02CIA-105BRL-CAD: 03starseeker * r44339 10/brlcad/trunk/include/raytrace.h: whoops - helps to check in the headers too
12:42.47CIA-105BRL-CAD: 03starseeker * r44340 10/brlcad/branches/cmake/ (. include/bu.h src/libbu/vls.c src/libged/search.c): MFC r44339
12:43.12CIA-105BRL-CAD: 03davidloman * r44341 10/geomcore/trunk/include/ByteBuffer.h: getMark() should be public, not protected.
13:08.53CIA-105BRL-CAD: 03starseeker * r44342 10/brlcad/trunk/src/libged/search.c: Hmm - that only worked on the Mac. Go the safe route and put basename into a tmp string.
13:09.54CIA-105BRL-CAD: 03starseeker * r44343 10/brlcad/branches/cmake/src/libged/search.c: MFC r44342
13:25.41``Erikiirc, basename fills a chunk of static memory and is not necessarily thread safe
13:27.15``Erikwait, no, it returns a pointer into the memory passed to it, n/m
13:33.46dlomanfwiw it looks like gcj hasn't been touched in about 2 years :/
13:35.41``Erikhuh, yeh, sept 22, 2009
13:36.12``Eriklast commit was 113 minutes ago
13:36.28``Erikhttp://gcc.gnu.org/viewcvs/trunk/
13:36.36dlomanto the gcc trunk yeah
13:36.41dlomanbut gcj is a subset
13:36.52``Eriklibjava is 28 hours
13:37.03dlomanyeah, but someone touched the makefile junk
13:37.06dlomanthats it.
13:38.33``Erikhm, poking around, it looks like it's maintenance mode
13:38.55``Erikhandful of commits in the last year, some new test stuff, but otherwise "done"
13:39.05dlomanyeah, i looked also.  according th the 'status page' there are some big holes in functionality
13:39.13dlomanlike NIO isn't implemented :/
13:39.29``Eriknio, even? hm, last I looked, the gui stuff was the gaping hole :/
13:39.57dlomanfor the most part, it is the gui
13:39.58CIA-105BRL-CAD: 03brlcad * r44344 10/brlcad/trunk/TODO: already a request from a user to test out the BoT TIE integration, via rtg3 or covart, so add a LIBRT_BOT_MINTIE environment variable as a means to enable it pervasively.
13:40.12dlomanbut i saw that .nio.* was also just an interface, no implementation.
13:40.14dlomanso that sucks.
13:40.32``Erikbrlcad: as a getenv(), not just the -c cmd?
13:42.10brlcadyeah
13:42.48``Erikwhere did the request come from? I don't see it in email or trackers
13:42.58brlcadlike LIBRT_V4FLIP, src/librt/librt.3
13:43.30brlcadit was a direct e-mail
13:44.46CIA-105BRL-CAD: 03davidloman * r44345 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): Convert some size_t's to int32_t since size_t does not necessarily mean unsigned int.
13:45.06brlcadbu_basename() has a patch pending that will require the caller to bu_free()
13:45.18brlcadto match behavior with bu_dirname()
13:45.38brlcad(they don't match dirname()/basename() but it let them be thread-safe)
13:45.48brlcadat least re-entrant
13:47.20CIA-105BRL-CAD: 03davidloman * r44346 10/geomcore/trunk/tests/unit/ (3 files in 2 dirs): Implement a few unit tests to get the feel for CPPUnit.
13:47.50brlcaddloman: heh, int32_t definitely doesn't mean unsigned int either :)
13:47.58brlcaduint32_t would though
13:47.58dlomanrighto
13:48.21dlomanthat's what i mean :)  commit entry was poorly worded.
13:49.32brlcadsize_t should be used when the value is meant to represent a "size" (i.e. unsigned 0->whatever)
13:50.44CIA-105BRL-CAD: 03erikgreenwald * r44347 10/brlcad/trunk/src/librt/dir.c: if the LIBRT_BOT_MINTIE environment variable is set, try to update the corrosponding global (direct email request to brlcad@
13:50.46brlcadwhy would a bytebuffer be specific about using 32-bit return values?  smells wrong
13:51.23dlomanneed something that can return a -1
13:51.26brlcadat a glance, getMark() sounds more like an off_t
13:51.53brlcadif it's still a size, ssize_t
13:52.07brlcadif it's a range offset, off_t
13:52.21dlomanssize_t == signed size_t ?
13:52.28brlcadyep
13:52.40CIA-105BRL-CAD: 03erikgreenwald * r44348 10/brlcad/trunk/src/libged/search.c: hoise declarations before body, C90 does not allow mixing.
13:52.54dlomanits a position.... so does that make it an range offset?
13:53.48``Erikbrlcad: in rt_dirbuild(), I'm assuming that is adequate for <third party>'s needs?
13:54.08brlcadhaving functions return values do double-duty with error values and values mixed fell out of stylistic favor a while ago, but is still fairly common -- ssize_t was added for that purpose to describe some of the legacy I/O calls (e.g., man 2 write)
13:54.55brlcad``Erik: could just pull the getenv() during prep, avoid setting the global altogether
13:55.42dlomangetMark() simply returns the 'marker' that the user set in the ByteBuffer.  if its not set, getMark() returns -1
13:55.45brlcadif (rt_bot_mintie > val || LIBRT_BOT_MINTIE > val || ...) tie prep
13:56.17brlcaddloman: would a marker of -32 work?
13:56.54dlomanwork as in 'is a marker of -32 valid' ?  in that case, no
13:57.29brlcadthen probably not an off_t
13:57.39dlomankk
13:57.40brlcadssize_t
13:57.49dlomangets it now. duh, lol
13:58.13``Erikwanted to avoid a slew of getenv() calls
13:58.44brlcadaren't they basically free?
13:59.09``Erikum, any sane shell would save them in a trie, but it'll be a few syscalls
13:59.15brlcadalready loaded into mem, just scans the array with string compares
14:01.06brlcadyeah, there's an environ[] global that is set up during binary init
14:01.16brlcadshouldnt' be syscalls
14:01.54brlcadhttp://pubs.opengroup.org/onlinepubs/009695399/functions/getenv.html says a few things about performance, nothing too insightful other than it "should" be fast
14:03.12``Erikother than cognitive locality, is there any benefit to placing it in the primitive prep?
14:03.37brlcadalso have the downside for long-running apps that might run some traces, stay running with the db still open, set the var, then run some more
14:03.45``Erikit's already a global due to how rt -c works
14:04.29brlcaddb_open() isn't a bad choice, it can probably work
14:05.04brlcadI'd just think you'd want it closer to the actual decision point (until it's observed / measured that performance is a problem)
14:05.08brlcadpremature and all that :)
14:05.42``Erikhm, I went with rt_dirbuild() because it seemed like the closest decision point... a converter will call db_open() without needing to prep *shrug*
14:06.01brlcadoop, I meant dirbuild
14:07.34``Erik*shrug* if you want to make a todo to discuss it, that's cool. if we move it and it impacts my isst stuff, I'll bitch/moan/complain/etc :D
14:08.37``ErikI'm not above saying "if you want it, change your rtg3/covart stuff" (this is the ohio office?)
14:09.55``Erikif they test it, it'll break and I'll have to fix it :/ I'm running into cmake issues with gtk+2, so I can't give it the testing I'd like to just yet
14:11.03brlcadif it moved and impacted, it'd get moved back right away .. that'd be the "observed" problem :)
14:11.42dlomanokay, most systems have htons and htonl, but is there any 'standard' support for 64 bit ints?
14:11.46brlcadthe user's desire to test it isn't our concern until you give it the "thumbs up, seems to be working fine for me, I'm done" stamp of approval
14:11.57brlcadthat's why the release notes said it was preliminary
14:12.24brlcadthe flag is more "oh yeah, that'd be a great way to toggle it on/off for everyone, even after it's all done and working"
14:12.56brlcaddloman: in libbu there is
14:13.07brlcadotherwise no
14:13.07dlomankk, am checking there atm, thanks.
14:13.49brlcaddloman: nothing so fancy, #include "bu.h" and just call ntohll() or htonll()
14:15.03dlomanbrlcad: would you recommend using the fns for floats and doubles as well?
14:15.29brlcadwhat are you doing?
14:15.44dlomancleaning up the network serializer stuff
14:15.53brlcadlibbu implements htonf() htond() ntohf() ntohd()
14:19.06CIA-105BRL-CAD: 03starseeker * r44349 10/brlcad/branches/cmake/ (TODO src/libged/search.c src/librt/dir.c): MFC r44348
14:27.18*** join/#brlcad PrezKennedy (MK@whitecalf.net)
14:35.43*** join/#brlcad willdye (~willdye@198.183.6.23)
14:39.31CIA-105BRL-CAD: 03davidloman * r44350 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): use of int32_t for ByteBuffer::mar was wrong. use ssize_t instead. Also, implemented put16Bit() and get16Bit()
14:41.17CIA-105BRL-CAD: 03davidloman * r44351 10/geomcore/trunk/src/utility/ByteBuffer.cxx: No need to increment 'position' since bu_vlb_write already does this.
14:44.30``Erikhm, 'ceylon' O.o
14:46.58dloman?
14:49.56``Erikhttp://blog.talawah.net/2011/04/gavin-king-unviels-red-hats-top-secret.html
14:51.00dlomanthat a play on Cylon?
14:51.24CIA-105BRL-CAD: 03d_rossberg * r44352 10/rt^3/trunk/include/ (MinimalDatabase.h brlcad/ConstDatabase.h brlcad/Object.h):
14:51.25CIA-105BRL-CAD: cleaned up to revision 44007
14:51.25CIA-105BRL-CAD: - removed unused includes from ConstDatabase.h (moved them to MinimalDatabase.h, maybe they are important there)
14:51.56``Erikredhat has a plan.
14:53.03starseekerhow do they plan to get all the existing java code over to Ceylon though?
14:53.39starseekerwe can't even get IE6 to die - I doubt anything will prompt businesses to rewrite key Java code
14:54.36``Erikit's "enterprisy" and on the jvm, groovy was too 'hippy' *shrug*
14:54.57starseekeris the jvm fully open source?
14:55.23``Eriklast I heard, the only turd left was in the sound code?
14:55.34starseekerhmm'
14:56.19``Erikwell, the only technical turd... the new ownership is a big steaming pile... O:-)
14:57.03starseekerinteresting:  http://vmkit.llvm.org/
14:57.37``Erikyou saw that apple has thrown in with the llvm crowd after gcc went gplv3?
14:57.56starseekeryep
14:58.38starseekercould be a very good thing
14:59.31starseekeronly problem I know of at the momemt is that clang isn't quite there performance wise compared to gcc
14:59.42``Erikmebbe, hopefully apple still has some top tier talent, even though they just had another 'great exodus'
14:59.51starseekerdid they?
15:00.02starseekerhadn't heard
15:00.03``Erikwell, mebbe 5ish years ago
15:00.10starseekeroh, the BSD guys?
15:00.15``Erikhubbard, perlstein, etc
15:00.16``Erikyeah
15:01.19starseekerwell, so far it looks like they're doing a decent job
15:01.52starseekera robust compiler toolkit with most of industry behind it and a BSD license strikes me as a Good Thing - everybody benefits
15:02.42starseekerseeing as there's not much of a commerical compiler market outside of specialized applications, it's in the interests of most companies to make a common substrate as good as possible
15:03.14``Erikicc is proprietary, right?
15:03.27starseekerand Apple's gcc fork is going to stray further and further from gcc proper, so it'll just get more and more annoying
15:03.30starseekerI believe so
15:04.02``Erikof anyone who would benefit, intel would be the obvious choice... they're starting to smell like 80's ibm :/
15:05.26starseekerthey must get enough licenses to make it worthwhile
15:05.52starseekerI suppose for companies shipping binaries, the cost is no big deal and they want the speedup
15:06.52starseekerdunno though - modern PCs seem fast enough that the difference would only be user visible in select cases
15:33.46CIA-105BRL-CAD: 03starseeker * r44353 10/brlcad/trunk/src/libged/search.c: Unlike find, we won't insist on a path if we're given options - if we have options but no path, assume '.'
15:34.48CIA-105BRL-CAD: 03starseeker * r44354 10/brlcad/branches/cmake/src/libged/search.c: MFC r44353
16:13.19CIA-105BRL-CAD: 03starseeker * r44355 10/brlcad/trunk/doc/docbook/system/mann/en/search.xml: Update search documentation
16:13.58CIA-105BRL-CAD: 03starseeker * r44356 10/brlcad/branches/cmake/doc/docbook/system/mann/en/search.xml: MFC r44355
16:26.05starseekerbrlcad: hrm.  I can't get the red tests to work - they're trying to fire off emacs for some reason
16:33.38starseekeroh, I have to set EDITOR to cat
16:48.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:13.39``Erikhm, I saw that on fbsd, but mac worked ok
17:14.38``Erikwonders if anything is still going on with googles 'go' O.o
17:32.33dlomanhttp://i.imgur.com/y7Hm9.jpg
17:55.37*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
18:07.10CIA-105BRL-CAD: 03r_weiss * r44357 10/brlcad/trunk/src/libbn/plane.c: (log message trimmed)
18:07.11CIA-105BRL-CAD: Corrected a bug in function 'bn_isect_lseg3_lseg3_new' in file 'plane.c' within
18:07.11CIA-105BRL-CAD: the libbn library. This is a prototype version of the function
19:06.09starseekerbrlcad: aha - ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/bmake/files/realpath.c
19:08.48CIA-105BRL-CAD: 03starseeker * r44358 10/brlcad/branches/cmake/regress/CMakeLists.txt: Add CMake code to run the red regression, but don't add it to the general regress target for now since a) red doesn't pass and b) something funny is happening with the EDITOR being called
19:13.09CIA-105BRL-CAD: 03starseeker * r44359 10/brlcad/trunk/ (include/bu.h src/libbu/vls.c src/libged/search.c): OK, no halfway measures. Going to need a full-on path resolution function.
19:21.43CIA-105BRL-CAD: 03davidloman * r44360 10/geomcore/trunk/tests/unit/utility/ (ByteBufferUTest.cxx ByteBufferUTest.h): Complete implementation of the ByteBufferUTest class.
19:23.23CIA-105BRL-CAD: 03davidloman * r44361 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): Unit test immediately reveled some bugs with ByteBuffer's behavior. Fixt.
19:33.45*** join/#brlcad Raz_Lobo (~razer@178.139.103.130)
19:38.35Raz_Lobohi all, I have a problem during deb package built of Brlcad-7.18.4 on PowerPC architecture.
19:38.41Raz_LoboCopy from console:
19:38.59Raz_Lobogcc -DHAVE_CONFIG_H -I. -I. -I../../include  -I../../src/other/tcl/generic -I../../src/oBS -I../../src/other/libz -pedantic -W -Wall -Wundef -Wfloat-equal -Wshadow -Winline -Wnc -W -Wall -Wundef -Wfloat-equal -Wshadow -Winline -Wno-long-long -c bntester.c
19:38.59Raz_Lobocc1: warnings being treated as errors
19:38.59Raz_Lobobntester.c: In function ‘main’:
19:38.59Raz_Lobobntester.c:190:5: error: comparison is always true due to limited range of data type
19:38.59Raz_Lobomake[3]: *** [bntester.o] Error 1
19:39.06Raz_LoboSomeone can help me?
19:39.38starseekerRaz_Lobo: Try adding --disable-strict to the configure flags
19:40.27Raz_Lobook, thanks so much, so fast. ^_^
19:40.28Raz_LoboI try.
20:21.16brlcadstarseeker: hmm.. you shouldn't have needed to set editor to cat
20:23.52starseeker``Erik was seeing issues with that too
20:25.34brlcadalso, ftp://ftp.irisa.fr/pub/OpenBSD/src/lib/libc/stdlib/realpath.c
20:26.01*** join/#brlcad dli (~dli@dsl-173-248-203-45.acanac.net)
20:26.20brlcadthe more I think about it, the more I lean towards that deserving to be a librt function, not libbu
20:27.07brlcadsince the minimal case right now isn't arbitrary path reduction, it's geometry path reduction
20:27.29brlcadalso sets the stage for later if "symbolic link" objects get added
20:27.52starseekerarrgh :-P
20:28.02starseekeris 4/5 of the way to a bu_normalize
20:28.14brlcadhehe, you still need every bit of that for the rt func
20:28.55starseekerlet me get this going first, then we can move it
20:29.01brlcadyeah keep on then, not a big deal
20:31.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:39.25CIA-105BRL-CAD: 03starseeker * r44362 10/brlcad/trunk/ (include/bu.h src/libbu/brlcad_path.c src/libged/search.c): Try again, this time with a realpath based path normalization
20:44.48CIA-105BRL-CAD: 03starseeker * r44363 10/brlcad/branches/cmake/ (5 files in 4 dirs): MFC r44362
20:56.57CIA-105BRL-CAD: 03starseeker * r44364 10/brlcad/trunk/ (4 files in 2 dirs): Move db_path.c to db_fullpath.c
21:06.00CIA-105BRL-CAD: 03starseeker * r44365 10/brlcad/trunk/ (7 files in 4 dirs): Take a stab at making bu_normalize into db_normalize
21:15.51CIA-105BRL-CAD: 03starseeker * r44366 10/brlcad/trunk/src/librt/db_path.c: Opps, headers are a good thing.
21:18.19CIA-105BRL-CAD: 03starseeker * r44367 10/brlcad/branches/cmake/ (9 files in 4 dirs): MFC r44366
21:27.20CIA-105BRL-CAD: 03starseeker * r44368 10/brlcad/trunk/src/libged/search.c: remove debug line
21:58.39*** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
22:45.31*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
IRC log for #brlcad on 20110414

IRC log for #brlcad on 20110414

01:12.10*** join/#brlcad crazy_imp (~mj@a89-182-198-172.net-htp.de)
01:19.31*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
04:02.12CIA-105BRL-CAD: 03brlcad * r44369 10/brlcad/trunk/src/libbn/bntester.c: bu_getopt() returns an int, not a char -- should resolve 'comparison is always true' failure (strict catches another bug).
04:04.36CIA-105BRL-CAD: 03brlcad * r44370 10/brlcad/trunk/src/libbn/bntester.c: there is no reason for these variables to be declared static. main() is not reentrant or used recursively.
04:05.59CIA-105BRL-CAD: 03brlcad * r44371 10/brlcad/trunk/src/libbn/bntester.c: ws indent consistency cleanup
04:06.52CIA-105BRL-CAD: 03brlcad * r44372 10/brlcad/trunk/src/libbu/getopt.c:
04:06.52CIA-105BRL-CAD: The getopt() function was once specified to return EOF instead of -1. This was
04:06.52CIA-105BRL-CAD: changed by IEEE Std 1003.2-1992 (POSIX.2'') to decouple getopt() from <stdio.h>.
04:13.01CIA-105BRL-CAD: 03brlcad * r44373 10/brlcad/trunk/include/bu.h: document the complex return values that may result from bu_getopt() (borrowed and adapted from the getopt() manual)
04:36.29CIA-105BRL-CAD: 03brlcad * r44374 10/brlcad/trunk/ (249 files in 41 dirs):
04:36.29CIA-105BRL-CAD: bu_getopt() function used to return EOF instead of -1. For getopt(), this was
04:36.29CIA-105BRL-CAD: changed by IEEE Std 1003.2-1992 (POSIX.2'') to decouple getopt() from <stdio.h>.
06:40.17*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca)
06:42.10CIA-105BRL-CAD: 03d_rossberg * r44375 10/rt^3/tags/rel-7-18-4/:
08:40.13*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
09:15.28*** join/#brlcad Stattrav (~Stattrav@117.192.140.159)
09:15.28*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:27.16*** join/#brlcad mafm_ (~mafm@193.153.199.229)
09:36.06*** join/#brlcad merzo (~merzo@193.254.217.44)
11:21.58CIA-105BRL-CAD: 03davidloman * r44376 10/geomcore/trunk/ (4 files in 3 dirs): Add getString and putString to ByteBuffer class. ByteBuffer class should now be a complete replacement for DataStream and ByteArray classes. Replacements to follow.
11:36.13dlomananyone: Are there help functions anywhere in the BRLCAD libs for getting/setting individual bits ?
11:38.50dloman(or do i need to roll my own)
11:48.44*** join/#brlcad crazy_imp (~mj@a89-182-198-172.net-htp.de)
12:10.57CIA-105BRL-CAD: 03davidloman * r44377 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): Add toHexString() to ByteBuffer. Aids in troubleshooting.
12:23.04CIA-105BRL-CAD: 03davidloman * r44378 10/geomcore/trunk/ (include/ByteBuffer.h src/utility/ByteBuffer.cxx): Add ByteBuffer::defaultBufferSize and set it to 4k
12:31.15brlcaddloman: search include/bu.h for 'bit' :)
12:31.32dlomanright on :)  found it already, but thanks :)
12:32.05dlomanis actually learning to look in bu first.... promise!
12:32.27brlcadwill believe it when he sees it :)
12:32.34dlomanpouts
12:33.02brlcadof course, the next time you'll look in libbu, and it'll be a math routine in libbn
12:33.14dlomanwait... how can you see it if i never ask?  ......SCAM!
12:50.22brlcadsees the commits
12:50.33brlcadcommit with some libbu api that you never asked about :P
13:04.36*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:20.10*** join/#brlcad mafm_ (~mafm@193.153.199.229)
13:20.32CIA-105BRL-CAD: 03davidloman * r44379 10/geomcore/trunk/ (55 files in 6 dirs): Removed DataStream and ByteArray classes. Replaced them with ByteBuffer.
13:26.20*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
13:34.35CIA-105BRL-CAD: 03starseeker * r44380 10/brlcad/branches/cmake/ (252 files in 43 dirs): MFC r44378
13:35.53CIA-105BRL-CAD: 03davidloman * r44381 10/geomcore/trunk/tests/unit/ (5 files in 3 dirs): Stub in unit test class for NetMsgs
13:36.12CIA-105BRL-CAD: 03davidloman * r44382 10/geomcore/trunk/tests/func/libNet/CMakeLists.txt: remove cmake entry for func test of netmsgs
13:48.01starseekercrap
13:48.34starseekerwe have a confirmed raytrace output change (overlap reporting with air volumes) between 7.16.8 and 7.18.3
13:52.37*** join/#brlcad Stattrav (~Stattrav@117.192.157.100)
13:52.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:58.54CIA-105BRL-CAD: 03bob1961 * r44383 10/brlcad/trunk/src/libdm/dm-wgl.c: RECT has no width/height members.
15:38.47*** join/#brlcad Stattrav (~Stattrav@117.192.158.156)
15:38.47*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:47.07CIA-105BRL-CAD: 03davidloman * r44384 10/geomcore/trunk/src/libNet/netMsg/ (19 files): Formatting, ws.
18:04.34CIA-105BRL-CAD: 03brlcad * r44385 10/brlcad/trunk/src/librt/cut.c:
18:04.34CIA-105BRL-CAD: increment axis AFTER the end of the loop, not as the first statement, so that
18:04.34CIA-105BRL-CAD: the iteration is XYZXYZXYZ instead of YZXYZXYZX. this unfortunately may impact
18:17.28*** join/#brlcad Stattrav (~Stattrav@117.192.158.156)
18:17.28*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:19.27*** join/#brlcad jay_ (~jay@212.96.10.253)
18:19.59jay_hi
18:20.15jay_anyone here using autocad 2010?
18:20.33dlomannot I!
18:21.46brlcadjay_: we don't provide autocad support
18:22.33jay_i know. i was just asking if someone here uses autocad
18:22.54brlcadso you can ask them your support questions in private?
18:23.33brlcadi've used autocad before
18:23.34jay_brlcad, you really want me to ask each person here the same question in private?
18:24.08brlcadasking support for a commercial product from an open source community is generally a really shitty thing to do
18:25.07brlcadif you're willing to donate 10% of their license fee, I might consider your question(s); but I'd rather answer any and all open source related questions for free
18:25.25jay_brlcad, are you serious?
18:25.39brlcadare you?
18:25.50brlcadyou pay them for a reason, they have support channels
18:26.08jay_brlcad, you just wasting my time. thanks for nothing
18:26.12brlcadlikewise
18:27.20*** mode/#brlcad [+o brlcad] by ChanServ
18:28.23*** part/#brlcad jay_ (~jay@212.96.10.253)
18:29.32starseekerhah - blender finally released a stable version of 2.5
18:29.46starseekermy, what an... odd versioning scheme
18:30.03dlibrlcad, how is the coverity thing going?
18:31.21brlcaddli: waiting a couple days to see if there is other interest
18:31.33brlcaddidn't want to send in account requests one at a time, just makes for more work on their end
18:31.47brlcadi'll send a batch request in on Monday
18:32.02dlibrlcad, sure, just make sure I didn't miss something
18:32.15brlcadanyone who has expressed interest in working on the issues, I'll include them in that request
18:32.51brlcadI think it's up to just four accounts so far
18:33.26dlimanpower not enough to fix 680 thousand lines :(
18:33.47dlior we develop some tool to auto fix findings
18:33.49brlcaddli: there's not 680k lines to fix :)
18:33.56brlcadthere were 680k analyzed
18:34.01brlcad< 2k to fix
18:34.18dlibrlcad, then, just doing it manually is fine
18:34.41brlcadif it was automatable, I would be writing scripts
18:34.49brlcadeach issue has to be investigated for the proper fix
18:35.03dlibrlcad, okay
18:35.45brlcadI bet more than 1800 will be very very easy, but then there will be 100 that will really take lots of time and effort to investigate and fix
18:37.05brlcadlike the three I posted, two of them are trivial to "fix" .. one really begs for a function to be implemented (a week of work) and another (the long one) warrants a logic review to see how it got that far in the first place with uninit data
18:52.55*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
18:55.51brlcad../../src/libged/.libs/libged.so: undefined reference to `db_normalize'
18:55.59brlcadstarseeker: forget a file?
18:56.16brlcador my sync might not be up to date .. checking now
19:22.22*** join/#brlcad ibot (~ibot@rikers.org)
19:22.22*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
19:22.47starseekerbrlcad: hehe, no problem - lord knows I've done that enough...
19:23.00starseekerw
19:23.05starseekerbah
20:11.04CIA-105BRL-CAD: 03brlcad * r44386 10/brlcad/branches/STABLE/ (272 files in 50 dirs): merge trunk to STABLE from r44325 to HEAD r44385 -- pulls in the spatial partitioning change to cut.c for XYZXYZXYZ split planes
20:15.40CIA-105BRL-CAD: 03starseeker * r44387 10/brlcad/trunk/src/librt/db5_types.c: Make a stab at a more general solution to handling boolean strings for regions that expect them.
20:30.59CIA-105BRL-CAD: 03starseeker * r44388 10/brlcad/trunk/src/librt/db5_types.c: Air isn't boolean, it's just a number
20:46.09CIA-105BRL-CAD: 03starseeker * r44389 10/brlcad/branches/cmake/src/ (libdm/dm-wgl.c librt/cut.c librt/db5_types.c): MFC r44388
21:11.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:28.26CIA-105BRL-CAD: 03starseeker * r44390 10/brlcad/trunk/src/librt/db5_types.c: Might as well be general here - do what we did in color.c in libged
21:47.44starseekeryeah, red's shader stuff is totally busted
21:58.19CIA-105BRL-CAD: 03r_weiss * r44391 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c:
21:58.39CIA-105BRL-CAD: Updated function 'nmg_bool' in file 'nmg_bool.c'. This update supports the new
21:58.39CIA-105BRL-CAD: prototype function 'nmg_triangulate_fu' (nmg triangulate faceuse) and is
21:58.39CIA-105BRL-CAD: disabled by default since it is untested in the production code. This update
23:00.43*** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net)
23:20.44*** join/#brlcad Ralith (~ralith@1555hostw130.starwoodbroadband.com)
IRC log for #brlcad on 20110415

IRC log for #brlcad on 20110415

00:00.18*** join/#brlcad dli_ (~dli@67.55.46.44)
01:12.02*** join/#brlcad crazy_imp (~mj@a89-182-196-151.net-htp.de)
01:15.54*** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net)
01:42.53*** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net)
03:03.16starseekerO.o http://www.amazon.com/Virtual-LM-Pictorial-Engineering-Construction/dp/1894959140/ref=ntt_at_ep_dpt_2
03:14.19*** join/#brlcad bhinesley (~bhinesley@99.104.170.214)
03:35.35brlcadhello bhinesley
03:35.47bhinesleyhi
03:36.36bhinesleyhow's it going?
03:38.24brlcadhad better days
03:38.53brlcadjust got back from coaching novice rowers, it went terrible even though the weather was gorgeous
03:39.04brlcadfrustrating :)
03:39.08brlcadotherwise, going great
03:39.28bhinesleyI'm guessing that it's the "novice" part that was giving you trouble.
03:40.13brlcadnot usually, but several things were off kilter tonight
03:41.23bhinesleybummer
03:47.05bhinesleydo you work for the Army, Sean?
03:47.22bhinesleyI mean, directly.
04:16.40*** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net)
04:16.52bhinesleyhm... mged keeps locking up my X session
06:11.21*** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net)
06:29.49*** join/#brlcad merzo (~merzo@193.254.217.44)
06:58.47*** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net)
07:26.03*** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net)
07:35.04*** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net)
07:44.22*** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net)
07:50.45*** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net)
08:02.03*** join/#brlcad Stattrav (~Stattrav@117.192.149.202)
08:02.03*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:04.30*** join/#brlcad mafm_ (~mafm@42.Red-83-45-72.dynamicIP.rima-tde.net)
09:11.11CIA-105BRL-CAD: 03d_rossberg * r44392 10/brlcad/trunk/src/librt/db_path.c: included raytrace.h because of the function's prototype and MAXPATHLEN via bu.h
09:12.34CIA-105BRL-CAD: 03d_rossberg * r44393 10/brlcad/trunk/src/librt/CMakeLists.txt: synced with Makefile.am (db_fullpath.c)
10:50.02*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:09.36*** join/#brlcad merzo (~merzo@193.254.217.44)
12:25.17*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
12:27.05*** join/#brlcad Stattrav_ (~Stattrav@117.192.137.184)
13:38.45*** join/#brlcad Stattrav (~Stattrav@117.192.138.197)
13:38.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:46.53*** join/#brlcad Stattrav_ (~Stattrav@117.192.139.64)
14:00.28*** join/#brlcad Stattrav (~Stattrav@117.202.16.228)
14:00.28*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:18.43*** join/#brlcad Stattrav (~Stattrav@117.192.134.224)
14:18.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:40.03*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
16:07.54CIA-105BRL-CAD: 03starseeker * r44394 10/brlcad/trunk/src/ (libged/red.c librt/db5_types.c): Ah - rgb, not color. This is a 'quick fix' - need to avoid editing the original data and rework write_comb to have no internal knowledge of the details of standard attributes - use librt functions.
16:09.47CIA-105BRL-CAD: 03starseeker * r44395 10/brlcad/branches/cmake/src/ (3 files in 3 dirs): MFC r44394
16:35.09*** join/#brlcad Stattrav (~Stattrav@117.192.135.83)
16:35.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:44.33*** join/#brlcad Ralith (~ralith@173.10.121.193)
16:49.44CIA-105BRL-CAD: 03starseeker * r44396 10/brlcad/trunk/src/libged/red.c: bye bye standard_attributes array, all hail db5_standard_attribute iteration
16:51.19starseekeryou know, in some ways red should really be called ced - it will edit a combination whether or not the region flag is set
16:53.49starseekereven better, we could just have 'ed' which would call either combination editing or primitive editing with a text editor depending on the argument given
16:56.29brlcadyep
16:56.35brlcadted
16:56.46brlcadmerge it all into ted since it's just text editing an object
16:56.53starseekernods
16:57.16starseekeris there any particular reason ted currently needs a primitive to be in edit state?
16:57.22brlcadnot really
16:57.28starseeker(I mean, aside from the convenience of not typing the name...)
16:57.33brlcadthat's the only reason
16:57.44brlcadold mged statefulness
16:58.37starseekerwill check into it - ideally, mged would feed libged's ted either the active primitive (sed) OR the active comb (oed)
16:59.07starseekerdives deeper down the rabbit hole...
16:59.59starseekerbrlcad: is there a good, easy way to make a local copy of a struct directory ?
17:00.40brlcader
17:00.43starseekerwas thinking bu_malloc and memcpy, but perhaps that has issues...
17:00.45brlcadyou can copy the struck
17:01.18brlcadyou can copy strucks directly -- it just depends on whether the copied pointer values will get edited or not
17:01.26brlcadheh, struct
17:02.01starseekeryou mean struct directory dp_cpy = *dp ?
17:02.12brlcadthat will do it
17:02.16starseekerin this case, editing is quite possible
17:02.39brlcadseems a bit odd that you'd need to mess with a dp
17:02.39starseekerguess I need a deep copy (avs, etc...)
17:03.07starseekerit's because the comb struct still keeps struct level variables for things like region, inherit, etc
17:03.52starseekerI need to 1) update those with any bu_avs values and then 2) update/create bu_avs values not present that ARE present in the struct
17:04.33starseekerif we could just nuke them out of the comb altogether that would be ideal...
17:05.03brlcadbut which routine are you referring to?
17:05.16starseekerthe ones you flagged
17:05.29starseekerdb5_apply_std_attributes and  db5_update_std_attributes
17:06.07starseekerI suppose I could write alternative versions of those that mimicked the internal comb variables
17:06.22starseekermaybe that's what I should do
17:06.31starseekerthen just have a function to sync the attributes to a dp
17:07.17brlcadwhat's the difference between those two functions?
17:07.37starseekera thought - can/should we mark the internal comb variables being replaced with attributes as deprecated, if we haven't already?
17:08.14starseekerdb5_apply_std_attributes reads the bu_avs attributes and looks for av pairs corresponding to variables contained in the comb struct
17:08.25starseekerif it finds any, it applys them to the struct
17:08.31brlcadthey already are marked deprecated in rt_comb_internal
17:08.45starseekerdb5_update_std_attributes goes the other way
17:09.39brlcadso they're really something like: db_sync_attr_to_comb() and db_sync_comb_to_attr()
17:11.07brlcadif that's the case, I wouldn't think you'd need a dp -- you'd need just the comb and a const bu_avs  or  an avs and a const comb
17:13.08brlcadthe caller code can call db5_get_attributes() to pull the avs, but that keeps the api more simple
17:13.23brlcadfewer degrees of freedom
17:18.34starseekerhmm... point
17:21.35CIA-105BRL-CAD: 03erikgreenwald * r44397 10/brlcad/branches/cmake/src/librt/CMakeLists.txt: indentation
17:47.51starseekerbrlcad: OH, that's why I had the dp mixed in - dp->d_flags &= ~RT_DIR_REGION;
17:48.50starseekerwill that get taken care of automatically when the comb is updated?
17:49.09brlcadhmm
18:11.48*** join/#brlcad Stattrav_ (~Stattrav@117.192.135.183)
18:31.41CIA-105BRL-CAD: 03starseeker * r44398 10/brlcad/trunk/ (include/raytrace.h src/libged/red.c src/librt/db5_types.c): Rework the attribute sync logic - more to do for validation. Note that this isn't syncing the dp->d_flags anymore so if that's needed functions will have to do it manually.
18:39.12CIA-105BRL-CAD: 03starseeker * r44399 10/brlcad/trunk/src/libged/red.c: Shouldn't need to call this out anymore
18:44.56CIA-105BRL-CAD: 03starseeker * r44400 10/brlcad/trunk/src/libged/red.c: Not calling db_update_attributes anymore in the sync routines.
18:47.30CIA-105BRL-CAD: 03starseeker * r44401 10/brlcad/branches/cmake/ (include/raytrace.h src/libged/red.c src/librt/db5_types.c): MFC r44400
19:21.20CIA-105BRL-CAD: 03erikgreenwald * r44402 10/brlcad/trunk/misc/win32-msvc8/librender/librender.vcproj: remove libtie, the functions are in librt now.
19:23.48*** join/#brlcad Stattrav (~Stattrav@117.192.129.235)
19:23.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:37.34CIA-105BRL-CAD: 03starseeker * r44403 10/brlcad/trunk/src/ (libged/red.c librt/db5_types.c): reorder/rework the attribute syncing for build comb in light of the current function behavior. Give strtol a try.
20:21.33CIA-105BRL-CAD: 03starseeker * r44404 10/brlcad/trunk/src/librt/db5_types.c: This should improve the robustness of the attr validation, including fixing an outright bug in air code handling.
20:29.48*** join/#brlcad mafm (~mafm@42.Red-83-45-72.dynamicIP.rima-tde.net)
20:35.20CIA-105BRL-CAD: 03starseeker * r44405 10/brlcad/trunk/src/librt/db5_types.c: Remove more hardcoded attribute names.
20:43.55CIA-105BRL-CAD: 03starseeker * r44406 10/brlcad/trunk/src/librt/db5_types.c: Start going with shader instead of oshader. Also, clear out old strings for shaders - clearing a shahder setting is a valid operation for attribute -> comb syncing.
20:47.06*** join/#brlcad Cappie (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca)
20:54.24Cappieftp://files3.cyberlink.net  login anon password anon <------ read Disclaimer.txt first   :)
20:56.39IriX64did redhat truly abandon el6 Workstation?
22:08.17*** join/#brlcad dli (~dli@67.55.46.44)
22:56.56CIA-105BRL-CAD: 03starseeker * r44407 10/brlcad/trunk/src/ (5 files in 5 dirs):
22:56.57CIA-105BRL-CAD: OK, starting to simply down a bit - add 'empty means set to zero' logic to other
22:56.57CIA-105BRL-CAD: cases for attr->comb. only call what syncs are needed. more oshader->shader
22:56.58CIA-105BRL-CAD: changes. Need to go with aircode as std for now, apparently - that one should
22:56.58CIA-105BRL-CAD: be fine, just change standard report.
23:15.09starseekerbrlcad: um.  What behavior are you looking for with the unsafe region_id and material_id?  Should I go ahead and assign the negative values, catch it, ...?
23:17.40*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
23:30.16CIA-105BRL-CAD: 03starseeker * r44408 10/brlcad/branches/cmake/ (7 files in 6 dirs): MFC r44407
IRC log for #brlcad on 20110416

IRC log for #brlcad on 20110416

01:17.46*** join/#brlcad crazy_imp (~mj@a89-182-6-110.net-htp.de)
02:20.13*** join/#brlcad bhinesley (~bhinesley@adsl-99-104-170-214.dsl.bkfd14.sbcglobal.net)
03:53.59*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca)
05:19.16starseekermakes a note of this page: http://www.blender.org/forum/viewtopic.php?t=18026
06:03.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:40.40*** join/#brlcad mafm (~mafm@242.Red-80-39-191.dynamicIP.rima-tde.net)
08:29.52*** join/#brlcad Ralith (~ralith@173-10-121-193-BusName-Washington.hfc.comcastbusiness.net)
10:00.33*** join/#brlcad merzo (~merzo@114-136-133-95.pool.ukrtel.net)
10:41.27*** join/#brlcad merzo (~merzo@40-234-95-178.pool.ukrtel.net)
12:37.37CIA-105BRL-CAD: 03jordisayol * r44409 10/brlcad/trunk/ (misc/debian/rules sh/make_deb.sh):
12:37.38CIA-105BRL-CAD: Properly handle errors during GNU/Linux packages building
12:37.38CIA-105BRL-CAD: Check if "configure" script exist.
12:54.21CIA-105BRL-CAD: 03jordisayol * r44410 10/brlcad/trunk/misc/debian/changelog: Update debian/changelog to the next BRL-CAD release.
13:02.12*** join/#brlcad mafm (~mafm@242.Red-80-39-191.dynamicIP.rima-tde.net)
15:02.57CIA-105BRL-CAD: 03starseeker * r44411 10/brlcad/trunk/src/librt/db5_types.c: Ah, was too aggressive about checking things on import.
16:33.00*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca)
16:38.35*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:41.28*** join/#brlcad cjdevlin1 (~devlin@75.118.176.70)
16:46.59*** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
17:18.13*** join/#brlcad Stattrav (~Stattrav@27.57.45.253)
17:18.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:27.02*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:37.16*** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
18:22.47*** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
18:24.08*** join/#brlcad Stattrav (~Stattrav@117.192.137.219)
18:24.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:50.07*** join/#brlcad Ralith (~ralith@198.134.89.250)
20:38.31bhinesleybrlcad: on sourceforge, it still says Looking for the latest version? Download BRL-CAD_7.14.8.exe...
22:23.51*** join/#brlcad Ralith (~ralith@204.239.250.1)
22:25.57dlibhinesley, https://sourceforge.net/projects/brlcad/files/BRL-CAD%20for%20Windows/ , 7.18.0 is available
22:57.56bhinesleydli: oh, I was just pointing out that the message is outdated
23:05.47CIA-105BRL-CAD: 03starseeker * r44412 10/brlcad/trunk/include/raytrace.h: Looks like we'll probably need this macro.
23:23.29starseekerbrlcad: in your color-unsafe test, you're feeding it -123 and expecting it to change?
23:23.49starseekerthe color input does validation - it should reject that and leave the file the same
23:26.43CIA-105BRL-CAD: 03starseeker * r44413 10/brlcad/trunk/src/librt/db5_types.c: Don't add an attribute if color is 0/0/0.
23:40.32starseekerbrlcad: I'm not sure I understand red.sh:442 - what are you trying to achieve there?
IRC log for #brlcad on 20110417

IRC log for #brlcad on 20110417

00:19.05*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
00:28.15starseekerO.o  http://www.shipmodels.info/mws_forum/viewtopic.php?f=27&t=66949
00:36.25brlcadcolor 0/0/0 is a perfectly valid color
00:36.48brlcad"-1" for color should delete the attribute if we follow previous mater convention
00:37.10brlcad-.*
00:42.10*** join/#brlcad Stattrav (~Stattrav@27.57.189.11)
00:42.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
01:12.40*** join/#brlcad crazy_imp (~mj@a89-182-223-144.net-htp.de)
02:24.09*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601162.dsl.bell.ca)
06:44.58*** join/#brlcad ibot_ (~ibot@198.60.114.207)
06:44.58*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
06:59.08*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
07:43.17*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
IRC log for #brlcad on 20110418

IRC log for #brlcad on 20110418

21:32.07*** join/#brlcad ibot (~ibot@rikers.org)
21:32.07*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
21:58.19CIA-105BRL-CAD: 03starseeker * r44430 10/brlcad/trunk/src/libged/red.c: Fix up the rename behavior for red.
22:00.07CIA-105BRL-CAD: 03starseeker * r44431 10/brlcad/trunk/src/libged/red.c: ws
22:23.50*** join/#brlcad mafm (~mafm@156.Red-88-23-77.staticIP.rima-tde.net)
22:24.40CIA-105BRL-CAD: 03starseeker * r44432 10/brlcad/trunk/src/ (libged/red.c librt/db5_types.c): Try taking the requirement for the space out of the attribute regex, trunk the shader if it's been cleared out
22:37.40CIA-105BRL-CAD: 03starseeker * r44433 10/brlcad/trunk/regress/red.sh: Urm. Shader is empty in test file, so this should be the same...
22:53.41*** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net)
23:08.47CIA-105BRL-CAD: 03starseeker * r44434 10/brlcad/trunk/regress/red.sh: Clear out the bug report messages.
23:13.58brlcadstarseeker: yeah, copy instead of move (or just ignore the original after reading its values)
23:14.02CIA-105BRL-CAD: 03starseeker * r44435 10/brlcad/branches/cmake/ (4 files in 3 dirs): MFC r44434
23:17.54starseekerI think I got all the regression tests dealt with
23:24.42starseekerbrlcad: I'll work on merging red and ted tomorrow
23:24.59starseeker(at least, at the mged level)
23:42.54*** join/#brlcad bhinesley (~bhinesley@adsl-99-104-168-20.dsl.bkfd14.sbcglobal.net)
IRC log for #brlcad on 20110419

IRC log for #brlcad on 20110419

01:12.37*** join/#brlcad crazy_imp (~mj@a89-182-195-68.net-htp.de)
02:03.52*** join/#brlcad dloman_ (~claymore@BZ.BZFLAG.BZ)
02:29.42CIA-105BRL-CAD: 03brlcad * r44436 10/brlcad/trunk/src/libged/annotate.c: position placement, decoration
02:33.36CIA-105BRL-CAD: 03brlcad * r44437 10/brlcad/trunk/src/libged/annotate.c: expand examples, notes on justification, placement, and initial thoughts on required struct members
02:33.56brlcadcool
02:45.06*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177878567.dsl.bell.ca)
04:23.34*** join/#brlcad cjdevlin (~devlin@75.118.176.70)
05:42.32CIA-105BRL-CAD: 03brlcad * r44438 10/brlcad/trunk/src/libged/annotate.c: considerable thought put into formalizing the command design so that it's descriptive yet reads naturally. enough hours thinking and designing for now, time to start coding.
05:48.57brlcadpretty exhausting to design up front, but I think this will be worth it .. should be really easy to use
05:53.35*** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net)
06:03.52CIA-105BRL-CAD: 03brlcad * r44439 10/brlcad/trunk/src/libged/annotate.c: lied, lil more thinking
06:16.26*** join/#brlcad Stattrav (~Stattrav@27.57.101.209)
06:16.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:50.22*** join/#brlcad merzo (~merzo@193.254.217.44)
06:54.48*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177592886.dsl.bell.ca)
08:23.28*** join/#brlcad vtts (~vytautas@diz.ktu.lt)
08:41.48*** join/#brlcad mafm (~mafm@20.Red-81-34-125.dynamicIP.rima-tde.net)
09:11.30*** join/#brlcad merzo (~merzo@193.254.217.44)
09:56.51*** join/#brlcad Stattrav (~Stattrav@27.61.60.144)
09:56.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:12.18*** join/#brlcad Stattrav_ (~Stattrav@27.61.234.254)
11:34.03*** join/#brlcad mafm_ (~mafm@20.Red-81-34-125.dynamicIP.rima-tde.net)
11:50.25CIA-105BRL-CAD: 03erikgreenwald * r44440 10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: add db_fullpath.c
11:55.38CIA-105BRL-CAD: 03erikgreenwald * r44441 10/brlcad/trunk/misc/win32-msvc8/libtclcad/libtclcad.vcproj: ged_obj.c is now tclcad_obj.c
12:00.33*** join/#brlcad bhinesley (~bhinesley@adsl-99-104-168-20.dsl.bkfd14.sbcglobal.net)
12:52.15*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
13:41.32*** part/#brlcad hyarion (c05ben@peppar.cs.umu.se)
13:53.18starseekeris fighting the urge to begin a big reorganization of the primitive editing code...
13:54.36starseekertedit is using globals, calls out a bit list of primitive types, doesn't do things like accept a name and primitive type on the command line to bring up an empty file...
14:02.29brlcadI tried eliminating one of the globals a few months back
14:02.37brlcadgot something wrong, broke, reverted
14:03.13brlcadis prime for rewrite though
14:09.07starseekerI think it belongs in a functab interface
14:10.11starseekerwould REALLY prefer to consolidate the import/export functabs into one, that keys off of an int parameter (1 = v4, 2 = v5, ... 100 = g2asc, 101 = txt edit, ...)
14:10.52starseekerthen we don't have to muck with the functab for a new format
14:11.25starseekerdon't have time for that now though - guess I'd better leave it, got to get on nurbs
14:22.50dloman_haha: http://www.youtube.com/watch?v=ejEkZtgYNpQ&feature=related
14:45.20CIA-105BRL-CAD: 03starseeker * r44442 10/brlcad/branches/cmake/src/librt/uvpoints.cpp: Make the tree depth to uvpoints a variable
14:48.39CIA-105BRL-CAD: 03erikgreenwald * r44443 10/geomcore/trunk/include/NetMsg.h: include NetMsgTypes.h to propogate the defines to the implementation
15:54.04CIA-105BRL-CAD: 03starseeker * r44444 10/brlcad/trunk/src/librt/uvpoints.cpp: Oops, that should have been in trunk.
16:11.35starseeker``Erik: one of the things we need to do for merge is to figure out why package require Itcl/Itk isn't cutting it for some of the mged stuff
16:11.55starseekerIIRC, I'm depending on package require working in the CMake setup
16:13.48starseekerthat'll be one of the main sources of conflict between the two trees - the change was reverted in trunk
16:17.08starseekerah, phooy - 44444 should have been something more significant than a trunk sync
16:18.10brlcadstarseeker: the func tab sort of already has an interface (in fact it has several)
16:18.33CIA-105BRL-CAD: 03starseeker * r44445 10/brlcad/branches/cmake/ (3 files in 3 dirs): MFC r44444
16:19.49brlcadat the functab level, it should be something pretty low level, like filling out a key/value pairing (another case for binary AVS) where each parameter and it's value is written in order
16:20.51brlcadthen similar to nirt output, the values can be formatted accordingly consistently with just one function for all object types (avs to v4, avs to v5, avs to text, etc)
16:21.22brlcadheck, json is a prime candidate since it also includes recursive grouping support
16:21.30brlcad(as an implementation detail)
16:21.39starseekernods
16:21.42brlcadat least, in-memory
16:21.58starseekerI'll have to shelve it for a while though - nurbs/step need attention
16:22.13brlcadnods
16:26.00starseeker``Erik: take a look at bwish/cadAppInit.c for a note on the problem
16:26.28brlcadhe working on merge review?
16:26.43starseekerhe was asking about merging, dunno about review
16:29.45starseekerthis is a handy little trick if you have trunk and cmake branches checkout out, run from within trunk:
16:29.48starseekerfind . -type file ! -regex '.*svn.*' ! -regex '.*\.cmake' ! -name CMakeLists.txt -print -exec diff {} ../cmake/{} \;
16:40.11brlcadnods -- usually do something similar to that when I merge major branches
17:11.32*** join/#brlcad crazy_imp (~mj@a89-182-195-68.net-htp.de)
18:03.41CIA-105BRL-CAD: 03bob1961 * r44446 10/brlcad/trunk/include/ged.h: Added GED_DM_VIEW_NULL.
18:27.53*** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net)
20:20.19*** join/#brlcad merzo (~merzo@197-47-132-95.pool.ukrtel.net)
22:21.38*** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net)
IRC log for #brlcad on 20110420

IRC log for #brlcad on 20110420

00:58.52*** join/#brlcad ibot (~ibot@rikers.org)
00:58.52*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
01:12.37*** join/#brlcad crazy_imp (~mj@a89-182-207-113.net-htp.de)
01:38.54*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:11.15*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
02:56.22*** join/#brlcad Hyper-Core (~lol@71.31.117.174)
03:00.47*** part/#brlcad Hyper-Core (~lol@71.31.117.174)
04:04.27*** join/#brlcad vtts (~vytautas@diz.ktu.lt)
04:16.10*** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net)
04:37.59*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
05:06.31*** join/#brlcad Stattrav (~Stattrav@122.172.5.31)
05:06.31*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:14.39brlcadstarseeker: nice job keeping the branch in sync
05:15.19brlcadcursory review looks great .. just a few issues to resolve
05:16.03brlcadthe known ones that you've already documented with bwish/mged init calls to Tcl_Eval("package require ...") instead of Itcl_Init() and friends
05:16.39brlcadone peculiar change in mged/cmd.c
06:09.18CIA-105BRL-CAD: 03brlcad * r44447 10/brlcad/branches/cmake/include/ged.h: merge r44444:44446 from trunk
06:37.11CIA-105BRL-CAD: 03brlcad * r44448 10/brlcad/trunk/src/other/libz/contrib/dotzlib/ (DotZLib/DotZLib.csproj DotZLib.build): merge from cmake branch to trunk, setting mime-type and eol-style on a few miles
08:24.13*** join/#brlcad ibot (~ibot@rikers.org)
08:24.13*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
08:39.03*** join/#brlcad mafm_ (~mafm@127.Red-81-32-105.dynamicIP.rima-tde.net)
11:07.43*** join/#brlcad merzo (~merzo@193.254.217.44)
11:24.16*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
11:27.18CIA-105BRL-CAD: 03208.110.88.242 07http://brlcad.org * r2855 10/wiki/Main_Page:
13:07.44CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2856 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/208.110.88.242|208.110.88.242]] ([[User talk:208.110.88.242|Talk]]); changed back to last version by [[User:Sean|Sean]]
13:07.54CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:208.110.88.242]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
13:13.22CIA-105BRL-CAD: 03brlcad * r44449 10/brlcad/trunk/src/other/libz/contrib/masmx86/inffas32.asm: set props to match branch
13:16.16CIA-105BRL-CAD: 03brlcad * r44450 10/brlcad/trunk/src/other/libz/contrib/masmx64/ (gvmat64.asm inffasx64.asm): more prop syncing
13:16.41CIA-105BRL-CAD: 03brlcad * r44451 10/brlcad/branches/cmake/src/other/incrTcl/itk/win/rc/itk.rc: not native, windows-style in case it's shoved into a source tarball
13:19.42CIA-105BRL-CAD: 03brlcad * r44452 10/brlcad/branches/cmake/src/other/incrTcl/itcl/win/rc/itcl.rc: sync eol-style to windows-style
13:21.52CIA-105BRL-CAD: 03brlcad * r44453 10/brlcad/branches/cmake/src/librt/primitives/nmg/nmg_misc.c: somehow this change was missed from trunk a few months back. nmg is using a plane, so init properly with HSETALL. this snippet still needed/needs investigating.
13:27.41CIA-105BRL-CAD: 03brlcad * r44454 10/brlcad/branches/cmake/src/ (bwish/cadAppInit.c bwish/main.c mged/setup.c):
13:27.41CIA-105BRL-CAD: sync with trunk just so we have a matching merge at the point of sync. this
13:27.42CIA-105BRL-CAD: restores the itcl/itk initialization to using their *_Init() functions instead
13:36.44CIA-105BRL-CAD: 03brlcad * r44455 10/brlcad/branches/cmake/src/mged/cmd.c: another change that was somehow missed syncing from trunk. maybe off-by-one on the revisions a couple times. this change automatically redraws any objects that are edited.
13:49.03CIA-105BRL-CAD: 03brlcad * r44456 10/brlcad/branches/cmake/include/config_win_cmake.h: another missed, probably due to name. everyone gets hypot and we have tk.
13:54.34CIA-105BRL-CAD: 03brlcad * r44457 10/brlcad/branches/cmake/misc/win32-msvc/ (CMakeLists.txt Dll/CMakeLists.txt): sync with trunk
14:45.16starseekerbrlcad: I'm not sure 44456 is the right way to sync - I have a vague recollection that the cmake branch changes were needed
14:52.16brlcadcmake branch had a compiler-version check -- that's usually not right
14:52.49starseekerI think that was added after some painful testing where we found it did matter for Visual Studio
14:53.48starseekerand the Tk variable(s) ought to be handled elsewhere - no reason for config_win to have that hardcoded
14:55.47starseekerIIRC, building with the HAVE_TK and hypot definion in Visual C++ 2010 won't work
14:56.29starseeker(HAVE_TK will be multiply defined regardless, if the build logic does its job)
15:01.45CIA-105BRL-CAD: 03starseeker * r44458 10/brlcad/trunk/ (doc/docbook/system/mann/en/ls.xml src/libged/ls.c): Add a -q option to ls to do a quiet db_lookup instead of a noisy one (useful for scripting)
15:03.23brlcadit can matter for studio
15:03.28brlcadit just shouldn't be version-exempted
15:03.49brlcadit becomes a feature test if it's feature-variant
15:04.49willdyebrlcad: this is only tangentially related to CAD, but FWIW the models and environments in Portal2 are (IMO) gorgeous.  most of the animated movie's i've seen aren't as visually impressive as what P2 renders in real time.
15:05.09brlcadnoticed HAVE_TK was suspect but had to pick left or right for the merge and trunk should win when there's doubt or suspect lines
15:05.10willdyeif you're not a game player, at least check out some of the videos for the modeling work.
15:05.31brlcadwilldye: okay, thanks
15:05.45brlcadusually a lot of impressive texture and lighting effects work :)
15:06.03willdyeyes, that too.
15:06.09``Erikshaders ftw
15:07.34starseekerbrlcad: if you can figure out how to set up a feature test I'm cool with that - it does need to be handled in some fashion for VS 2010
15:08.15CIA-105BRL-CAD: 03brlcad * r44459 10/brlcad/trunk/ (INSTALL.cmake README.cmake TODO.cmake): sync the cmake top-level docs from the cmake branch
15:08.19starseeker``Erik: do you remember that MSVC version specific thing we had to deal with?  I recall asking  you for help there
15:08.24brlcader, a small snippet that runs hypot() and/or _hypot()
15:09.03``Eriknot especially, I didn't see a commit message on that file that helped, either :/
15:09.36``ErikI do recall looking up the variable on msdn, but not what the core issue was :/
15:10.14brlcad#include <math.h>\nint main(int ac, char*av[]) { double f; f = _hypot(1.0, 1.0); return 0; }
15:10.26brlcadif it succeeds, #define hypot _hypot
15:11.03starseekerbbl, must perform helpdesk function
15:57.41brlcadsyncs all the cmakelist files (with history!)
16:04.36brlcadwoo hoo, no gsoc conflicts!
16:04.51brlcadnot much longer now
16:05.22``Erikheh, I was starting to do a clobber copy last night, decided to finish it today and you'd already started O.o w00t, history preserved
16:06.09brlcadthe cmakelists files are going to take a while to sync with history :)
16:07.14``Erik*nod* hopefully ya don't lose connection when committing :) I had one that wouldn't work in a single thing from the office, ended up using bz to do it
16:07.33brlcadcommit from arlnet, why it's taking so fraking long
16:07.36``Erikbtw, new server has user accounts, a wad of ports, updated system, and /usr/home copied
16:08.12brlcadAWESOME!
16:08.21``Erikthat's a huge disk bump
16:30.12brlcadI bet
16:30.34brlcadheh, syncing the cmake files is going to take another hour .. stupid network
16:36.19``Erikwhile that's chunking, think ya might update the crit cname? :D
16:53.39CIA-105BRL-CAD: 03starseeker * r44460 10/brlcad/trunk/src/libged/ls.c: whoops, update usage too.
18:17.26brlcadwoot, finished copying .. now the commit
18:39.53CIA-105BRL-CAD: 03brlcad * r44461 10/brlcad/trunk/ (130 files in 130 dirs): sync all of the CMakeLists.txt files from the cmake branch to trunk, preserving history via svn cp for the new additions and copying for the rest.
18:48.32brlcadyes, it really took that long
18:48.53*** join/#brlcad mafm_ (~mafm@34.Red-83-58-21.dynamicIP.rima-tde.net)
18:54.45starseekerbrlcad: so that just leaves the .cmake files?
19:27.01starseekerblinks: http://www.steptools.com/products/stepncwrite/
19:44.27CIA-105BRL-CAD: 03erikgreenwald * r44462 10/geomcore/trunk/src/libgvm/ (files.c gvm.h gvm_svn.h mem.c models.c objects.c repo.c): add header/footer, indent, kill trailing whitespace, etc.
19:46.26``Erikstill need merged in misc/CMake
19:46.51``Erikgrammar I master am of
19:47.04starseekerheh
19:47.40``Erik(vim writing/editing style doesn't quite work in irssi)
19:54.06brlcad``Erik: it's going, still merging
19:54.32brlcaddoing the preserved copy apparently initiates a lot of net connections, which sucks
19:54.48brlcadat least on that net
20:01.11CIA-105BRL-CAD: 03brlcad * r44463 10/brlcad/trunk/ (configure.cmake.sh misc/CMake/ misc/Doxyfile.in): add new files coming from the cmake branch: support infrastructure, templatized Doxyfile, and a fake configure wrapper
20:08.46starseeker``Erik: yeah, it's in tests/func/gvmtest
20:13.46``Erik#+darwin(sb-posix:chdir (let ((binname (sb-sys::os-get-runtime-executable-path t))) (subseq binname 0 (- (length binname) (length (concatenate 'string "Contents/MacOS/" +executable-name+))))))
20:14.06starseekerawesome
20:14.13``Erikayup, I thought so
20:14.45``Eriknot awesome enough for 3 months in sbcl's guts, but...
20:15.17CIA-105BRL-CAD: 03brlcad * r44464 10/brlcad/trunk/src/librt/db5_types.c: really 'del' means the same for any of the attributes. it's our old-style convention meant to remove/disable an value or option.
20:20.18brlcadnstill working on src/other
20:26.15CIA-105BRL-CAD: 03brlcad * r44465 10/brlcad/trunk/src/other/ (8 files in 8 dirs): likewise with the src/other CMake dirs
20:28.22brlcadsnack break, will be back to merging in a couple .. not yet complete
20:28.45starseekermmm, snacks
20:48.06*** join/#brlcad crazy_imp (~mj@a89-182-207-113.net-htp.de)
21:28.18*** join/#brlcad mafm (~mafm@34.Red-83-58-21.dynamicIP.rima-tde.net)
23:09.11*** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net)
23:53.30*** join/#brlcad evander (~jack@adsl-76-202-242-120.dsl.emhril.sbcglobal.net)
23:55.40evanderhey
IRC log for #brlcad on 20110421

IRC log for #brlcad on 20110421

02:28.10brlcadhello evander
02:30.43``Erikso the merge is complete?
02:42.01evanderI'm having trouble getting brl-cad to compile, it's just one line causing trouble, anyone willing to help
02:42.05evander?
02:49.42brlcad``Erik: doing a final pass review now
02:50.12brlcadhaven't done a compilation check yet, both old and new builds may be busted but the changes are reviewed and merged
02:50.17brlcadevander: what's the failure?
02:51.39evandermake says that 'abi' and 'aci' 'may be uninitialized in this function'
02:54.42evanderthis is for the proc_box function in src/librt/patch/patch-g.c line 1936: 'vect_t ab, ac, ad, abi, aci, adi'
02:55.37evandersorry, src/conv/patch/patch-g.c
03:10.12``Erikevander: there's a flag to disable strict flags when you run configure, try that?
03:14.10evanderI'll try
03:21.38CIA-105BRL-CAD: 03brlcad * r44466 10/brlcad/trunk/src/conv/patch/patch-g.c: quell strict compilation warning reported by evander via irc. compiler wasn't smart enough to figure out that use prior to init isn't possible (valid is false).
03:33.41CIA-105BRL-CAD: 03brlcad * r44467 10/brlcad/trunk/misc/archlinux/brlcad.install: remove the rcs id var to minimize branch diff. add /bin/sh header for source scanners since it looks like proper syntax.
03:37.54CIA-105BRL-CAD: 03brlcad * r44468 10/brlcad/trunk/src/other/togl/CMake/CheckFunctions.cmake: this just very well may be the last sync needed to merge cmake branch to trunk.
03:40.20brlcadverified, the diff looks clean
03:40.33brlcadnow to check/fix the build :)
03:41.09brlcadfair game for anyone to hack on now
03:51.57``ErikI'll do my usual spread tomorrow and either fix or report all the failures O.o I doubt there'll be many if the merge is solid, been fixing/reporting for the cmake branch for a while :)
04:17.17brlcadshould be possible to have both working without too much effort at least while install testing proceeds -- that was just a pure source merge review so the branch can be closed out
04:19.52CIA-105BRL-CAD: 03brlcad * r44469 10/brlcad/trunk/src/conv/patch/patch-g.c: oops, double semi
04:31.31brlcadhmm.. the lights regression is failing
04:31.46brlcadpretty sure it worked for release, but not 100%
04:34.18CIA-105BRL-CAD: 03brlcad * r44470 10/brlcad/trunk/TODO: light regression is failing, need to investigate and fix. don't know when it broke.
04:39.04CIA-105BRL-CAD: 03brlcad * r44471 10/brlcad/trunk/TODO:
04:39.04CIA-105BRL-CAD: aha, found the cause. the lights test calls 'put' and sets attributes directly
04:39.05CIA-105BRL-CAD: including several old attribute names such as rgb and .. oshader. this makes
04:51.34CIA-105BRL-CAD: 03brlcad * r44472 10/brlcad/trunk/src/librt/CMakeLists.txt: deterministic behavior still applies, ignore individual 'extra_dist' files.
05:55.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:02.29*** join/#brlcad crazy_imp (~mj@a89-182-193-94.net-htp.de)
08:07.31*** join/#brlcad crazy_im1 (~mj@a89-182-199-125.net-htp.de)
08:45.35*** join/#brlcad mafm (~mafm@213.Red-83-40-126.dynamicIP.rima-tde.net)
10:29.08*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:28.43*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
11:39.39*** join/#brlcad merzo (~merzo@193.254.217.44)
13:14.36brlcadinteresting.. old build passed distcheck :)
13:26.00starseekerblinks - but it shouldn't, should it?
13:29.06``Erikshould the old stuff get all the CMakeLists.txt and misc/CMake/ stuff added as EXTRA_DIST ?
13:29.42brlcadthat's why it passing distcheck was interesting :)
13:29.56brlcadbut otherwise, yeah
13:30.18starseekerwinces - that's a lot of work unless we're going to maintain both for a while
13:30.21``Erikdistcheck won't complain if unknown "turds" don't get put in the tarball
13:30.32brlcadonly minimal attention I'd think -- wont' live for long
13:30.55brlcad``Erik: except I have logic in there that checks if anything is missing
13:31.09brlcadit compares the svn list with the dist
13:31.34starseekertook some doing to duplicate that behavior with CMake
13:31.36brlcadstarseeker: o.O not really .. 10 min tops
13:32.10starseekerbrlcad: updating all the Makefile.am extradists for all the directories where something was added?
13:32.11brlcadtedious, sure, but not a lot of actual time
13:32.28starseekerwhat do we gain?
13:32.52brlcadif we have to push a source release with it
13:33.11brlcadit's not your 10min, no worries :)
13:33.18starseekertrue :-)
13:33.41brlcadI didn't plan on adding them unless distcheck failed
13:33.53brlcadand it didn't fail, so .. interesting :)
13:34.03starseekercmake build is currently failing due to the Itcl_Init issue, bty
13:42.49brlcadhm, mine is actually failing in librt here
13:42.55brlcadstrictness fail on bot.c
13:43.02brlcadsignage warnings
13:48.03starseekerer, yeah - itcl is with strict off
13:48.21starseeker(lots of formatting blather too)
13:56.13brlcadso that's going to require a little digging -- Itcl_init definitely shouldn't be failing (nor should package require)
13:56.18brlcadi'll hop of the debugger later today
13:56.23brlcads/of/on/
14:00.10``Erikthe signed issues came from a commit indianlarry did, I'll ask him about it when he gets back in the office
14:01.55brlcadautotools strict is actually off in librt, was turned off during release preparations due to a problem in the nmg export code
14:02.04brlcadso even if bot succeeds, nmg is going to issue a warning
14:02.41brlcadwe need to either exempt librt like autotools does, or fix the warnings (ideal)
14:05.23``Erikyeah, I'd like to ask him sooner than later while it's still semi-fresh, mebbe leave a comment in the src if it bears holding off reverting
14:06.08``Eriklog says something about a bug report, d'no which one, so'z *shrug*
14:36.42starseekerbrlcad: I know why Itcl_init isn't working - it's because I didn't include all the directories needed for the itcl.h/itk.h headers
14:37.29starseekerwas trying to use package require to avoid that whole "using private headers" mess
15:33.31*** join/#brlcad Stattrav (~Stattrav@117.202.20.210)
15:33.31*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:57.14``Erikmmmm, pröst *pats belleh*
16:58.04``Erikbrlcad: those g_bot_include signed issues are direct fallout from size_t, the 'index' and nhits stuff use -1 as a special value in some cases, a mixed of == and <0
16:59.58starseekerbrlcad: there are a couple of cases where I call out whole directories to ignore in the CMakeLists.txt files - in particular, the Tcl/Tk man pages are generated by scripts.  I suppose would could actually list all those out and update that list every time Tcl/Tk changes something, but that's quite a pain as opposed to just snarfing the list of generated files after generating them
17:06.19CIA-105BRL-CAD: 03starseeker * r44473 10/brlcad/trunk/doc/docbook/system/mann/en/CMakeLists.txt: Remove early experiment with file-checking code
17:21.18CIA-105BRL-CAD: 03starseeker * r44474 10/brlcad/trunk/src/ (bwish/CMakeLists.txt mged/CMakeLists.txt): Until we get it sorted out, add in the logic needed for btclsh/bwish and mged to find the itcl.h and itk.h headers.
17:21.46starseekerok, that gets me going with a non-strict build on Mac
17:24.28starseekerreflects that eventually we'll probably want to update the svn ignore properties in trunk
17:24.37CIA-105BRL-CAD: 03erikgreenwald * r44475 10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: use temporary signed variables to quell the signed/unsigned warning. Add a TODO: requesting review down the road.
17:34.00CIA-105BRL-CAD: 03erikgreenwald * r44476 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: bu_glong -> ntohl (only tested on v5)
17:35.35``Eriklibrt should be safe for strict again
17:42.51CIA-105BRL-CAD: 03starseeker * r44477 10/brlcad/trunk/ (misc/CMake/BRLCAD_Util.cmake src/librt/CMakeLists.txt): Add the ability to specify a NOSTRICT compile when adding a library.
18:11.53*** join/#brlcad merzo (~merzo@222-14-94-178.pool.ukrtel.net)
18:14.05brlcad``Erik: yeah, I remember that patch -- most of the -1 should have been properly cast through size_t, so if anything was missed, it might have been a <0 check that needed to be changed to == (size_t)-1
18:14.28brlcadwarrants getting the test case that provoked the bug
18:16.11brlcadstarseeker: that sounds fine for src/other dirs -- I think the issue is more with our own directories
18:16.41starseekerbrlcad: k.  For ours it'll probably be a few cases like the xxx dir
18:17.50brlcada minor referential integrity cost so we can say we're fully managed (with lists of all intentional files, whether source code or not)
18:18.09brlcadnot a major issue in the least, just completeness
18:18.22brlcadreally impressed how cleanly the merge went
18:19.49brlcad``Erik: unless I typo'd .. the "obvious" conversion to ntohl() resulted in a hard crashing raytracing bug
18:20.13starseeker'course, I doubt the windows build works right now
18:20.32starseekerbut it shouldn't be far off
18:20.39brlcadsure, some wrinkles to iron out, but in all .. looking great
18:20.44starseekeris impressed you managed to save all the history
18:20.46brlcadold build works, new build works
18:21.29starseeker(all my early CMake suckage preserved for posterity...)
18:21.30brlcadnow a confirmation that release tarballs produced are identical and same with binary installs, and the old can go bye bye soon
18:21.47starseekernot quite yet - install docs will need more work
18:22.02brlcadminor, that's an afternoon at best
18:22.29starseekerand possibly some expansion of the options in the fake configure script - also not a huge deal, unless we want to automate its generation
18:22.54brlcadit'll take more time to write up an article on the conversion overview and impact
18:23.50starseekerfor the source files, it's make package_source - make package for the binaries, IIRC
18:24.21brlcadno worries, I'll assume it's all documented in INSTALL.cmake
18:24.25brlcadotherwise, I'll chase you down :)
18:24.32starseekerquickly checks...
18:24.34starseekererm...
18:24.53brlcader, perhaps HACKING.cmake
18:25.23starseekerwhich doesn't exist yet
18:25.25starseekergets busy
18:29.39starseekereventually we'll probably want to tie the new deb/rpm settings into the CPack stuff
18:37.41*** join/#brlcad Stattrav (~Stattrav@117.202.20.210)
18:37.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:46.11``Erikbrlcad: I raytraced a big nmg heavy model successfully (took 2 regex passes and hand reviewing the changes to verify, there was a cfl grade difference in some cases)
18:46.38``Erikfor bots, the test case was dark side
18:47.36brlcad``Erik: okay cool
18:47.50brlcadi'm not above having entered a typo or fat-fingered some expression
18:48.14brlcadprobably diff what I did with your patch to see where this lamb went astray
18:59.07CIA-105BRL-CAD: 03starseeker * r44478 10/brlcad/trunk/src/other/CMakeLists.txt: Add a few dirs to the ignore list
19:08.13kanzuredid jdoliner ever finish his implementation of boole? http://brlcad.org/wiki/User:Jdoliner
19:10.27kanzureah.. brlcad/trunk/src/proc-db/surfaceintersect.cpp
19:12.15kanzureyeah i'm not sure if he committed all of his code or not
19:13.07kanzurehmm the latest was 2009-08-13
19:13.14kanzureok. that sounds about right
19:14.25brlcadkanzure: he didn't implement or integrate boole itself, but he was trying to implement what boole does in our system
19:15.18brlcadhe started building up the individual pieces needed to get surface-surface intersection calculations going, and got something going, but it wasn't a complete effort
19:15.48kanzurelooks like he did good work sticking with the opennurbs primitives
19:15.54brlcadsrc/proc-db/surfaceintersect.cpp is the latest state of the code
19:15.58brlcadyeah, pretty good
19:16.46kanzureon the wiki he mentions SurfaceSurfaceIntersect but all i see is BrepBrepIntersect; i figure it's the one?
19:16.59kanzureoh "SurfaceSurfaceIntersect has been renamed to FaceFaceIntersect same" ok
19:17.21brlcada brep is one or more surfaces
19:17.54kanzurei forget how opennurbs handles multiple faces on an object
19:18.13kanzurei know that it's accessed as an array (like my_nurb.m_F[x] for the xth face)
19:18.21kanzurebut usually there's some information about adjacency of faces .. er, somewhere
19:18.42brlcadsee src/proc-db/brep*.cpp
19:18.51kanzuresince you can call myobject.get_edges() where each edge separates two faces, etc.
19:18.54kanzureok
19:18.55brlcadseveral examples
19:19.42kanzureit's the trimming curve that is the edge around a given face right?
19:20.45brlcadyes
19:21.40kanzurewhy do you say it wasn't a complete effort?
19:21.51kanzureoh duh, intersection isn't enough to actually perform the set operators
19:22.14*** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net)
19:22.20brlcadand I don't think his implementation will handle ALL cases of surface surface intersections
19:22.29brlcadlots of edge cases to consider
19:24.00CIA-105BRL-CAD: 03starseeker * r44479 10/brlcad/trunk/doc/README.MacOSX: Document the issue CMake has with parallel builds and OSX open file limits
19:25.00kanzureyeah and then you have to merge the intersection curves
19:25.07CIA-105BRL-CAD: 03starseeker * r44480 10/brlcad/trunk/HACKING.cmake: Add a cmake version of HACKING
19:26.16kanzurethen use the merged brep to partition the original two solids, classify each partitioned component as either inside/outside and based on that classification add it to the object (depending on whether this is a union or difference)
19:28.33brlcadexample, consider two simple triangles.  they can intersect as a point (pt), a line (ln), or a face (fc), so you have pt-pt for two coinciding vertices, pt-ln for a vertex on edge, and pt-fc for a vertex in the face; ln-ln for coinciding edges (with three overlap sub-cases), ln-fa (similarly with three sub-cases), and fa-fa for non-tangential planar intersections (with at least three sub-cases)
19:29.15brlcadthat's twelve cases, and I'd be surprised if he ended up with support for more than a few of them
19:30.16brlcadtwo random intersecting polygons is going to be a fc-fc intersect producing a ln result
19:31.06kanzurei don't know what to do in the case of a vertex on a face- presumably that vertex is infintismal anyway so..
19:31.29brlcadright, so you decide whether to ignore or stitch
19:31.48brlcadone of them will be wrong :)
19:32.03brlcadbut you don't know which
19:33.24brlcadyou could attempt to say "okay, no points on faces" .. but even regular triangle that share an edge have this property (two pairs of coinciding vertices and a coinciding edge)
19:33.59kanzurebtw the guys who wrote BOOLE released their code in the public domain
19:34.36kanzure(in c)
19:34.49brlcadbasically, it's needing to preserve a concept of "inside", "outside", ... and "on"
19:35.15brlcadboole is not PD, unless they changed it recently
19:35.25brlcadit's NC
19:36.04brlcadhttp://gamma.cs.unc.edu/CSG/BOOLE-DOCS/copyright
19:36.32kanzureblah
19:36.55kanzuresorry for the false alarm
19:37.13brlcadI know the guys that worked on boole (and later esolid)
19:37.25brlcadthat was collaborative research back in the day
19:37.29kanzurein one of their papers they claim it is public domain, but i see the license clearly claims differently
19:37.41brlcadthey actually gave us permission to use their code many years ago via e-mail, but no longer have access to that e-mail without serious archive searching
19:37.57kanzureyeah the same paper references muuss which made me wonder if brlcad implemented this (which, the answer is no, but the 2009 gsoc student worked on it, neat)
19:38.32brlcadthey were contracted by BRL to work on the problem back in the mid-90's, but unfortunately there was licensing disputes
19:38.40kanzurelamesauce
19:38.56brlcadmaybe late 80's .. old history now
19:39.27kanzurei trust boole over, say, opencascade, for their intersection algorithm.. since at least this one is documented
19:39.31brlcadthe goal was primarily nurbs raytracing and I think our current implementation easily beats it hands down
19:39.48kanzurei'm honestly surprised how there is no simple, well-written, well-documented, open source brep-brep intersection software
19:40.06kanzurethis isn't *that* hard
19:40.32brlcada lot of the surface surface intersection calculations were needed to get accurate ray-tracing, so you might be able to repurpose some of the ray-tracing code into a more general surface-surface intersection function
19:40.55kanzurei was thinking of implementing boole but i see there's a good start here
19:40.58brlcadit's hard to do robustly :)
19:41.16kanzurei think robustness can be sacrificed at first for a working system, and then robustness can be designed in for a 2.0
19:41.35kanzureonce we have someone, anyone, who is working on open source code that has successfully implemented any of this :)
19:42.00brlcadthat's just it, it's not really working if it's not robust -- the best you can do is limit yourself to robustness across simple geometry
19:42.08brlcadlike two spheres or two boxes
19:42.22kanzuredo you mean practically robust or the academic version of "robust by proof"? ;)
19:42.27kanzureer, robust by theorem
19:42.28brlcadeven robustly answering whether that pairing intersect or not .. tricky
19:42.36brlcadpractically robust
19:42.50brlcadif you want provably, you need different numerics
19:42.57brlcadCGAL-style
19:43.04brlcadslow fixed arithmetic
19:43.57brlcadif you want to pick up the torch working in src/proc-db or elsewhere related to this, lemme know and I'll set you up
19:44.14kanzurewhat do you mean set me up?
19:44.47brlcadwith commit access, so you can work on test code in src/proc-db for example
19:45.51brlcadif you want to do your own thing out of repo, that's cool too, but it is nice to see the commits to see rationale behind development directions
19:45.54kanzurei don't have anything to commit at the moment but i'll ping you
19:46.02kanzurethat's true..
19:46.26brlcadwhatever works
19:46.45kanzureso you're ok with incomplete/dysfunctional code commits?
19:47.00brlcadin src/proc-db yes
19:47.07brlcadin src/lib* no
19:47.20brlcadunless it's #ifdef's out of course
19:47.45brlcadjust shouldn't affect production use until it's reasonably well tested
19:48.05brlcadotherwise, visibility and communication ftw
19:50.35kanzureokay.
19:50.48kanzuresure, i'll take some svn commit access goodness
19:52.05brlcaddone
19:52.07brlcadyou've been around here long enough to know how we operate, not exactly a loose canon
19:52.20brlcadjust don't break stuff :)
19:52.28brlcadread HACKING for the rest
19:52.39brlcadand/or ask
20:03.15kanzureokie dokie
20:05.53*** join/#brlcad mafm (~mafm@48.Red-83-63-197.staticIP.rima-tde.net)
20:14.35kanzurebrlcad: did you add my sourceforge account?
20:22.26brlcadyep
20:22.26CIA-105BRL-CAD: 03erikgreenwald * r44481 10/geomcore/trunk/src/interfaces/cl/gsserver.lisp: use defvar instead of defparameter (to avoid clobbering a live recompile conflict). Use global variable notation instead of constant.
20:22.32brlcadtry a test commit
20:25.06kanzurei'd rather not muddy up commit history
20:26.04brlcadheh
20:26.30brlcadit's a huge history, not really going to be noticed :)
20:26.53CIA-105BRL-CAD: 03erikgreenwald * r44482 10/geomcore/trunk/src/libgvm/repo.c: return 0 on success (instead of stack trash since there was no explicit return on success)
20:27.09brlcadhttps://sourceforge.net/mailarchive/forum.php?forum_name=brlcad-commits  <-- per month commit stats
20:28.21brlcadwow, we hit a new record in january .. 914, nifty!
20:42.02``Erikah, svn_repos_open doesn't open the file, each operation opens and closes the file described by the repo struct... brutal
20:49.05bhinesleywhile (1) {touch . ; svn commit -M "testing"}
20:49.13bhinesleythis month promises to be even better ;)
20:49.43brlcadheh, nice try
20:50.12brlcadthat wouldn't commit a change, and you'll get invalid option on the -M ;)
20:51.22``Erikcan't think of a shell that'd eat that
20:51.53brlcadwhile `true` ; do echo "==$RANDOM==" >> file  ; svn commit -m "+1" file ; cat file | sed 's/==.*==//g' > file ; done
20:52.06*** join/#brlcad merzo (~merzo@7-32-94-178.pool.ukrtel.net)
20:52.17bhinesleyyou guys are too much
20:54.58*** join/#brlcad mafm (~mafm@48.Red-83-63-197.staticIP.rima-tde.net)
20:54.59starseekernever give brlcad a shell script challenge
21:00.36``Erikit's just another language *shrug* a repl based one, even
21:01.30kanzurebrlcad: now that i look at it, BrepBrepIntersect doesn't actually use its (brep) "out" variable
21:02.08kanzureerr, (ON_Brep) type
21:02.55brlcadkanzure: yep, I vaguely recall having to mark that as UNUSED during a strictness pass
21:03.02kanzureah.
21:03.04kanzurefooey
21:03.09brlcadfix it ;)
21:03.15brlcador rewrite
21:03.26kanzureif it wasn't using opennurbs, i'd immediately rewrite it on my own
21:03.43kanzurebut.. since he did at least go to the trouble of making this slightly maintainable..
21:03.55brlcadopennurbs is actually a pretty nice api to work with
21:04.16kanzuresure
21:04.22brlcadmost of the annoying aspects have been things that were intentionally removed
21:04.30kanzureyes
21:04.36kanzureON_GL... grr
21:04.48``Eriknice, the acknowledgements section in the scsh manual... awesome
21:05.19brlcaddo they thank the flying spagetti monster?
21:05.49``Erikhttp://www.scsh.net/docu/html/man.html
21:07.21brlcadhaha
21:18.06brlcadhm, sanity check:  unsigned char cp;   cp + 4 == &cp[4]  ?
21:22.11``Erikyup
21:23.51brlcadthen the only diff between our conversions is you wrapped the cast in parens
21:24.31brlcadI'm thinking the bug was actually an unrelated change made to rt_nmg_reindex() in the same commit
21:24.49brlcadupgraded return type from int to long including two index vars
21:26.40brlcadthe parens shouldn't matter because arrow has higher precedence than the cast, so it's already grouped
21:27.01brlcadotherwise we match line for line
21:27.08brlcadgotta be rt_nmg_reindex() .. hrm
21:29.29brlcadeither way, nice fix ``Erik .. librt can be restrictified
21:34.45*** join/#brlcad bhinesley (~bhinesley@99.104.168.20)
21:42.23CIA-105BRL-CAD: 03starseeker * r44483 10/brlcad/trunk/src/librt/CMakeLists.txt: Erik restored the strict building.
22:05.34starseekerah, that's why - the default implementation of opennurbs_memory.c is a straight-up malloc/calloc/etc. wrapper
22:11.49brlcadstarseeker: another approach for the itcl/package problem -- take it to the natural limit, shouldn't be calling either from C-land
22:11.51CIA-105BRL-CAD: 03brlcad * r44484 10/brlcad/trunk/src/librt/Makefile.am: ditto for now
22:12.08brlcadmake the scripts package require what they need
22:12.15starseekertrue...
22:25.19starseekerer... this is not good.  Probably the best way to set this up would be to use the apr memory pools, since we need variable sizes
22:25.23starseekerick
22:25.54starseekeror custom roll our own
22:32.38``Erikvariable sizes? that doesn't tend to work well with pools, that's a full allocator
22:34.22``Erikyeah, I've gotten in the habit of using parens whenever casting a referenced pieces just to verify it's all correct and obvious
22:34.36``Erikpiece
22:34.54starseeker``Erik: it seems the technical term is "region based memory management"
22:36.23starseekerthat's what the Apache Portable Runtime pools really are
22:36.26``Erikif you have a finite set of sizes, you can do sets of pools... a 'buddy' allocator is pretty easy and quick, used to be the norm... system alloc usually uses slabs these days
22:37.04``Erik'region based' might mean slabs, just implemented outside of the kernel to avoid syscalls, maybe? *shrug*
22:37.04starseekerunfortunately, if we're going to put something behind the opennurbs on* functions (which we want to for improved performance) their API accepts arbitrary sizes
22:37.48starseekerthe only thing that comes readily to mind is a hash table of pointers to pools, hashed by data type size
22:39.09starseekerbasically, assume finite sizes in practice (if not in theory) and create whatever pools are needed - one per requested size
22:39.12``Erikthat'd be one wasteful way to do it... buddy system slicer on subpage chunks, mebbe with an occasional gc/compactor might be another
22:39.36starseekerlooks up buddy allocator
22:39.47``Erik(buddy system basically means a binary tree of memory, pick the best fit, dividing if needed)
22:40.10``Erikand here we go, screaming to greenspuns tenth :D
22:40.47starseekerthe quickest and most practical thing to do  would be to stick APR behind opennurbs and see what kind of performance we get
22:41.05starseekerbut that would tie our raytracing directly to the APR libraries as a dependency
22:41.54``Erikisn't keen on that
22:42.05starseekerisn't either
22:42.50``Erikdo we know the typical size range that opennurbs wants?
22:44.02starseekernot really
22:44.20``Erikas an experiment, we (and I mean you) could write a trivial allocator that does a big block alloc, sets a 'usual max' size and subdivides the memory into those sizes, so if it's 256 bytes, just return a 256 byte zone when 40 bytes is requested
22:44.24``Erikwasteful, but easy
22:44.28starseekermy concern is if it's using onmalloc and friends to allocate storage for NURBS, the size range is going to be all over the map
22:46.45``Erikcould do a 'pass-through' allocator to instrument and record a history of allocs (or see if valgrind, efence, etc can be tortured into doing that) and compare with and without that for a test model?
22:47.27starseekernods - or we might just do a data collection experiment - record all sizes requested and see how big the distribution really is
22:47.38starseekerI might be over-estimating the problem
22:48.00*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177871947.dsl.bell.ca)
22:48.06``Erikyeh, I'd imagine you are :) profile before optimizing, right?
22:49.54``Erikit'd be convenient if an automated tool could do that for you, instead of hand instrumenting the code
22:50.41bhinesleymake well1.s rcc
22:50.45bhinesleyoops sorry
22:51.23brlcadif you're messing with anything more complex than a simple bundling allocation pool (if even that), then you're probably doing something wrong
22:51.59brlcadwho is doing the allocate? when?
22:52.13starseekeropennurbs - anytime onmalloc and friends are called
22:52.19brlcadwhich is when?
22:52.30``ErikI think part of the evaluator for a shot hits one
22:52.46starseekerdepends on whether you're overriding the C++ new or not - if you are, everytime anything is allocated in opennurbs
22:52.52brlcadevaluator that's called during prep, yes?
22:53.35brlcadfind it hard to believe that malloc is being called during the trace .. performance would be very bad
22:53.39starseekerI believe so - I'd have to check if it's being called during the raytrace
22:53.57brlcadnot just a little bad .. super bad, like almost nmg bad
22:54.15brlcadfrom I've seen interactive, that's just not possible
22:54.17starseekerbrlcad: there is a new being called, I remember that from the Shark profiles, but it hit some geometries worse than others
22:54.26brlcadso if it's all prep, then you can pretty much control when you allocate
22:54.33``ErikI was under the impression that shoot had one... and prep definitely needs sped up
22:55.00brlcadmm.. I'd focus on eliminating that single one during shot before even thinking about prep
22:55.27``Erikif you're not freeing until the end, you can alloc a bit chunk and walk it linearly, if you request more than what's left, make a new one, ad the old one to a crap list and move on
22:55.42``Erikbig chunk
22:55.47brlcadnods
22:56.19brlcadthat can even be done during prep
22:56.29brlcadat least for the initial chunk
23:00.12*** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177871947.dsl.bell.ca)
23:00.48CIA-105BRL-CAD: 03starseeker * r44485 10/brlcad/trunk/src/librt/uvpoints.cpp: Add some timing and defaults.
23:10.18starseekerah, looks like apr is using a more straightforward approach than I thought
23:10.44starseekeror wait...
23:11.18starseekerOK, well, either way something custom is needed - time to figure out how to set that up
23:13.11``Erikthe key is to limit the problem domain, if you try to be as generic as the libc stuff, you're trying to outsmart some incredibly smart guys O.o
23:13.35starseekernods - I know, special allocation for special purposes
23:17.53starseekerhuh, nifty:  http://books.google.com/books?id=ukXrNh2g6fQC&pg=PA128&lpg=PA128&dq=APR+memory+pool+Boost&source=bl&ots=CF5TfwORRZ&sig=a6lt3dYZoPXYEaGRYIAb6mS3asU&hl=en&ei=J6uwTYvuBIeUtweqotDzCw&sa=X&oi=book_result&ct=result&resnum=3&ved=0CCYQ6AEwAg#v=onepage&q=APR%20memory%20pool%20Boost&f=false
23:48.45brlcadstarseeker: do you have a profile?
23:49.20starseekerno, Shark is busted on my machine at the moment :-(
23:49.21brlcadI know we constantly say "allocations are bad" .. but they are totally trumped by algorithmic complexity analysis
23:49.28starseekerworking off of memory from last year
23:49.53starseekerI suppose it's time to upgrade and get everything fixed
23:50.34brlcade.g., it may be spending most of it's time calling malloc, but if it's because of some O(N^3) algorithm then it may be calling malloc 10-1000 times more than it actually needs to
23:51.32starseekernods
23:52.30brlcadcase in point was my nmg fix a few months bad .. nmg is relatively slow due to allocations, but was being really stupid reallocating over and over unnecessarily (by two orders of magnitude) .. cut a 5-day run down to half hour, all without changing the way allocations occur even though that's where most of the time was spent
23:52.46brlcadchanged why it was allocating in the first place
23:53.28brlcadshark is awesome, but gprof can give insight too
23:53.42brlcadif you copied configure, it's the -pg profile option
23:55.02starseekerin cmake it's BRLCAD-ENABLE_PROFILING
23:55.07starseekertests...
23:58.58starseekerI'm not actually messing with BRL-CAD's raytracing yet - I'm trying to get a feel for how my test uvpoints.cpp file is behaving
IRC log for #brlcad on 20110422

IRC log for #brlcad on 20110422

00:01.27brlcadgprof excels at function-level analysis
00:01.42starseekergrowl... for whatever reason, that's not working on the mac either
00:01.50starseekereither in isolation or as part of the build
00:01.58starseekerto linux...
00:02.35brlcadTODO: fix profiling option :)
00:03.05brlcad(presuming you're using gprof right)
00:03.28starseekeryep, but I'm assuming it's my mac's fault until proven otherwise
00:04.26brlcadunlikely, it's not like shark
00:04.55brlcadit's not cpu metrics, it injects code around all your functions
00:05.14brlcadso if gcc works, it should work
00:05.26starseekergprof works on inux
00:05.29starseekerlinux even
00:07.03brlcadok, whatever works
00:09.25starseekermust... fix... mac...
00:10.47starseekeryeah, ok - my uvpoints.cpp file is wasting most of its time with strings
00:10.53starseekerno wonder
00:19.57brlcad(fwiw, "using std namespace" is evil)
00:20.10brlcader, using namespace std;
00:20.22starseekerI know -  it's just a test program, not intended for production in its current form
00:20.31brlcadah, interesting
00:20.52starseekerscratchpad for experimenting with uv coordinates, memory pools, etc. without the complexity of the SurfaceTree
00:20.55brlcadperhaps a less on references, pointers, and std:: data types :)
00:21.06brlcaddamn, can't type tonight
00:21.15brlcadlesson
00:21.18starseekerwinces - yeah, I'm quite sure I'm using it all wrong
00:21.29brlcadyou're passing std::string in and out of functions
00:21.41brlcadthat makes a copy of the string every function call
00:21.47brlcadand every return
00:22.00brlcadmalloc-style
00:22.29brlcadyou want to either pass around std::string*'s or std::string&'s depending on the use
00:22.53brlcaddepends who creates the string and how it's used
00:23.37brlcadsafest is to pass a pointer, but best is usually a ref .. but then you have to be more careful on how it's accessed and stored
00:24.57starseekernods - any good tutorials?
00:25.08brlcade.g. UVKey::UVKey() is fine taking a std::string newkey (so it'll make a copy on construction), but UVKey::getKey() should return a std::string&
00:31.52CIA-105BRL-CAD: 03starseeker * r44486 10/brlcad/trunk/src/librt/uvpoints.cpp: Try returning a reference
00:31.55starseekerbrlcad: like that?
00:32.34brlcadyeah, that's better
00:33.17brlcadone thing to remember, that change now changes the contract for UVKey -- it's no longer just a string, it's UVKey's string
00:33.37starseekernods - that was the idea originally, actually
00:33.43brlcadso if you delete UVKey, any references to a std::string from getKey() would be dangling references (invalid)
00:33.47starseekeryow, string comparison is brutal
00:35.26brlcadyeah, that was my next question .. what's up with string keys??
00:35.33brlcadnumeric ftw
00:35.41starseekerthey're UV coordinates
00:36.40brlcadso?
00:36.50starseekerI don't recall the original motivator - I think it was to make it easier to mash together two pairs into one unique descriptive string
00:36.52brlcadyeah, AppendKeys() .. nfg
00:37.25brlcadints_to_key looks like some sort of string-based hash
00:37.51brlcadjust store them into a u,v array, O(1) lookups
00:38.01starseekerah, right - 0100 and 0001 don't convert to different integers
00:38.34starseekerand those strings are the keys for a minimal perfect hash
00:39.01brlcadperfectly inefficient maybe :)
00:39.07starseekerprobably I should stash them as numbers and only build the strings when I need to
00:39.57starseekerthe original effort there was to find unique identifiers for all the UV points that might get evaluated into 3-space during a subdivision of depth N
00:40.15brlcadeither way, even as a perfect hash, shouldn't have a sprintf() call in there for generating a hash (heck, shouldn't need to manually hash yourself anyways)
00:40.17starseekerbecause there are a lot of shared points, I wanted a good way to avoid duplicate evaluations
00:41.13brlcadthe std:: container hashing is pretty frickin good
00:41.40starseekerthe simplest way to avoid duplicates was to have a way for any subdivision, at any depth up until the maximum depth, be able to look up a given UV coordinate to see if it had been evaluated
00:42.32brlcadyou probably want a std::map
00:43.09brlcadheck, maybe even a simple std::map<u, std::map<v, value> >
00:43.23starseekerhow fast are those lookups?
00:43.33brlcadguaranteed to be at least logN iirc
00:43.57starseekerin theory, if I understand correctly, a minimal perfect hash is O(1)
00:44.50starseekerand as a tree deepens, we can build up a LOT of points and do a LOT of lookups
00:46.06starseekerso a minimal perfect hash of a unique string descriptor of the UV coordinates, which is possible because we know the candidate sites that might be evaluated in advance, allows us to generate such a hash up front
00:46.38brlcadif it's O(1) lookup and O(insane) to generate the hash, you've kinda missed the boat
00:46.56brlcadthat's still just the minimum guarantee
00:47.02starseekerexcept the hash only has to be generated at compile time
00:47.13brlcadyou mean prep?
00:47.18starseekerno, compile
00:47.22starseekersource code compile
00:47.38brlcader, there's no such thing going on in your code there now
00:47.43starseekerright
00:47.56starseekerbecause it was early days when I had to shift to other stuff
00:48.14starseekerbut it DOES generate the keys.txt file, which contains the full list of unique keys
00:48.31brlcadif there is a limited set of hash sites, why not just direct index into a set then?
00:49.25starseekerall I know when I'm subdividing is the UV coordinates of the point I'm at - I have to map that to some index value
00:49.37brlcadi'd still try the std::map first -- dead simple implementation, easy to maintain, and really good performance behavior guarantees
00:50.42brlcadso the idea sounds fine, but it shouldn't be based on or involve strings
00:51.47starseekeruh... the string is key for hashing - apparently hashing numbers usually doesn't work out well
00:52.11starseekermy problem is I'm storing the info as a string, which is wrong
00:52.12brlcadhttp://www.sgi.com/tech/stl/hash_set.html
00:52.42brlcadagain, configurable key type, even configurable hash function
00:53.26brlcada hash set of hash maps perhaps for u,v to value mapping
00:53.29brlcadhttp://www.sgi.com/tech/stl/hash_map.html
00:53.43brlcador hash_map of hash_maps
00:59.07brlcadthe tradeoff with a std::map<> is that std::hash_map<> will be faster (O(1) on average O(N) worst case even with perfect hashing, have to account for collisions) but it's not in any particular order if you need to iterate or search
00:59.48brlcadso find *this* UV is fast.. finding your closest neighbor will be relatively expensive
01:00.25starseekernods - so far there hasn't been a need for nearest UV neighbor (famous last words...)
01:00.56starseekerbrlcad: let me see if I can take strings out of what I'm doing now, at least up until keys.txt is generated
01:01.04starseekerthat works in the right direction regardless
01:01.52starseekeronce I'm doing that right, we can tangle with the various hashing/mapping options
01:08.04starseekerthe minimal perfect hash appeals to me because with this situation we don't NEED to have any collisions, but I suppose I could be full of... err... converted dog food too
01:14.28*** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net)
02:31.04*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565712.dsl.bell.ca)
03:22.05*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
04:29.39starseekerbrlcad wins - will investigate stl map tomorrow, then look into hash_map if that's not enough
04:29.55starseekerbraces for another C++ learning curve
05:06.15brlcadit's important enough to warrant a simple performance comparison
06:14.42brlcadstarseeker: here's a code snippet I just whipped up for you to play with
06:15.35brlcadshows how to use map, hash map, and shows the comparative performance of each
06:41.24brlcadhttp://brlcad.org/tmp/hasher.cxx
06:42.42brlcadjust for kicks, I stubbed in some code sort of showing worst case and best case perfect hashing .. though the devil is truly in the details for all of them since a simple datatype change or iteration change can completely skew the comparison
06:44.12brlcadonly played two use-case scenarios, setting and reading .. not iterating over all, nearest neighbor, deletions, etc
06:45.30brlcadalso using the non-bounds-checked [] operator instead of insert(), find(), and other functions
06:46.55brlcadI'd suggest looking at a real worst case trace, see how many insertions/lookups/deletions and what the tree looks like -- shallowest, average, deepest
06:47.10brlcadthen mapping that into a test program simulating the same behavior
06:50.51brlcadshould hopefully be a little more clear how/why I think map or unordered_map will probably be more than "good enough" given how much simpler they are to run with .. and if not, looking into exactly why
07:33.21*** join/#brlcad Stattrav (~Stattrav@117.202.22.183)
07:33.21*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:10.31*** join/#brlcad crazy_imp (~mj@a89-182-215-216.net-htp.de)
08:28.56*** join/#brlcad merzo (~merzo@193.254.217.44)
08:30.38*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
09:38.38*** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net)
11:35.09``Erik*readreadread* obsessing over a perfect hash may be self defeating... also; O() is just one of the bits to consider, there are 5 categories of asymptotic notation. qsort is a poor performer on O(), but awesome in real life (omega is tight, k is low, etc)
11:40.48``Erikhm, no system hash funcs in your demo, brlcad? md5? sha1? :)
12:45.34starseekerbrlcad: thanks for the demo - that will be a big help
12:48.28starseekerhmm... u+v won't work, isn't unique 0 + 1 = 1 + 0... probably need something like u * (some power of 10) + v
12:48.52starseekerthat's a detail though
12:49.20starseekerrummages around for some energy and gets moving
13:13.00``Erikcollisions may be acceptable... ergo; quadratic (http://en.wikipedia.org/wiki/Quadratic_probing) or chained (each hash bin is a linked list)
13:17.15*** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net)
13:33.11brlcadstarseeker: it'll "work" .. it's just a really really bad hash :)
13:33.15brlcadlots of collisions
13:33.31brlcadmore showing the full range of impact it can have
13:34.06brlcadwith the right hash, you approach the best case instant update time of an array but worst case can be an order worse than a simple map
13:34.54brlcadall the more motivation to just stick with the algo that makes most sense
13:36.35brlcadthe data is a simple mapping of uv keys to a 3dpoint, so the immediate thought that comes to mind is std::map<std::pair<int, int>, vect_t>
13:37.56brlcad(do not use ON_3dpoint .. it's got lots of junk, you can set the vect_t direct on read:  vect_t v = VINIT_ZERO; ON_3dpoint p = v; ON_3dpoint *pp = new ON_3dpoint(v);
13:38.25brlcadthey added operator support for getting the value from a double*
13:46.10brlcadgood exercise for the reader to attempt adding std::map<std::pair<int, int>, vect_t> and using proper std::map::iterator instead of using the [] operator .. you'll get a lot of insight
13:57.11brlcadthen switch it to [] and compare :)
14:31.14*** join/#brlcad dli (~dli@67.55.46.44)
14:46.25starseekerbrlcad: the map is good if we need things like nearest-neighbor?
14:48.17starseekerwonders if triangulation might just want that information, even if we don't need it for raytracing
15:25.06``Erikr-tree is the shizzle for nearest neighbor
15:25.12*** join/#brlcad Stattrav (~Stattrav@117.202.18.42)
15:25.12*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:25.41``Erikbut data repacking should never take more than nlgn
15:25.59``Erikpoor cats, still reeling from the bathing this morning
15:43.01starseeker``Erik: this should appeal to your bit-level side - can I take a floating point value and map it to an int simply?
15:43.38starseekerstd::map is slow with floats, but for storage the important thing is to have an easy, unique identifer
15:44.15starseekerif the UV floating point coordinates can be mapped to integers...
15:45.30starseekerI hadn't properly considered what wanting to split first on the knot points implies - it pretty much trashes my subdivision gridding coordinate scheme
15:46.34starseekermight be able to get away with just being aware of which leaves contain knots, but more general solution of being able to pick any given UV point, subdivide using it, and using the std::map or something like it all the while sounds nice
15:53.03*** part/#brlcad willdye (~willdye@198.183.6.23)
16:27.29*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
17:35.13*** join/#brlcad Stattrav (~Stattrav@117.202.18.42)
17:35.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:47.37starseekerhmm... http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
18:45.43kanzuredid commercial CAD packages ever take more than a few seconds to do a boolean operation on two solids?
19:08.49starseekerkanzure: I doubt it...
19:12.44kanzurehrm. weird. i'm reading some papers from the 90s where these programmers are cheering because they can merge a few meshes "IN ALMOST EIGHT SECONDS!!"
19:13.03kanzureon some sort of sgi onyx machine (200 mhz.. etc.)
19:17.49bhinesleyI'm off to the beach for the weekend. Have a good weekend, everyone.
19:25.24*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
19:36.48kanzurewow "CATIA uses polyhedral approximations for intersection and boundary computations"
19:38.36*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
19:44.36kanzure"We then use the trapezoidation of the trimming polygon (using Seidel's algorithm) to perform logarithmic time point location queries.
19:44.39kanzure"However, the accuracy of this result depends on the magnitude of errors introduced by approximating the high degree trimming curve through the boundary of the Gaudl invariants."
19:44.43kanzureok i give up on this paper
19:45.42starseekerkanzure: which paper?
19:45.53kanzureone of krishnan's
19:46.14kanzurei'll use his other one where he uses matrix math for constructing the intersection curve
20:39.27starseekerbrlcad: looks like the pair iteration is slightly slower, I'm assuming due to the make_pair overhead:  http://brlcad.org/~starseeker/map_test.cxx
20:43.37starseekerI can't get the iterator to work thus far
20:56.05starseekerah, there we go - I THINK that works... anyway, if I do full assignment instead of using drand48 the count returned seems to match up
21:00.53starseekerhmm, interesting - iterator is faster if I replace drand48 with i in the insertion loops
21:01.03*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
22:26.36``Erikhm, you could always do floor() or ceiling()... could also grab a bit mask ( ((uint320t)f) >> 16) )
22:26.52``Eriks/0/_/
22:27.51starseeker``Erik: actually, even the worst case floating point performance may not be a showstopper - plus, it looks like to get performance benefit the data type in question needs to be small anyway
22:29.22starseekersuspects, based on conversations concerning STL libraries, that they probably are doing whatever the sanest thing is for floats under the hood
22:30.25``Erikthe guys who did stl are pretty good... don't try to outsmart them, the key is to not use their stuff wrong...
22:31.06starseekernods
22:31.24``Erikat the moment, we assume a full fpu... I'm sure BRL-CAD on my arm7 would suck arse
22:31.40starseekerheh
22:32.02``Erikhttp://brlcad.org/~erik/20110422/  they are not happy :)
22:32.31starseekerhehe
23:04.18brlcadstarseeker: excellent that you got the pair working along with iterators
23:04.28brlcadthat was more the point than actual performance
23:05.07brlcadmake_pair() is probably injecting a tiny overhead, you'd probably just call the pair<> constructor directly where you can set values by const reference instead of by value
23:06.18brlcadthe other thing you should try is printing the pair values through the iterator
23:06.43brlcadinstead of just incrementing counter, try to use the iterator
23:22.45``Erikif I groked correctly, iterator classes are insanely efficient once invoked... a machine optimizable deref, iirc
23:23.31``Eriksame level of machine nerdiness as a ^= b ^= a ^= b
IRC log for #brlcad on 20110423

IRC log for #brlcad on 20110423

00:55.10*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
02:24.03*** join/#brlcad crazy_im1 (~mj@a89-182-219-8.net-htp.de)
04:48.49*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
05:41.01*** join/#brlcad Stattrav (~Stattrav@117.192.140.160)
05:41.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:28.01*** join/#brlcad Stattrav (~Stattrav@117.192.141.32)
06:28.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:16.57*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:13.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:50.21*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
17:54.51*** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net)
IRC log for #brlcad on 20110424

IRC log for #brlcad on 20110424

00:52.43*** join/#brlcad Josko (~Josko@JSO5040.rhbd.psu.edu)
00:57.07JoskoHow can I go about participating in the code cleanup effort following the FULL valid Coverity scan?
01:28.46*** join/#brlcad Josko (~Josko@JSO5040.rhbd.psu.edu)
01:34.37*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
01:51.20*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
02:29.04*** join/#brlcad crazy_imp (~mj@a89-182-28-75.net-htp.de)
04:39.28*** join/#brlcad nat_ (~nat@77.209.179.132)
04:58.03*** join/#brlcad KimK (~Kim__@wlnt-02-246.dsl.netins.net)
05:01.30*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
07:26.18*** join/#brlcad dli (~dli@67.55.46.44)
IRC log for #brlcad on 20110425

IRC log for #brlcad on 20110425

19:19.56*** join/#brlcad ibot (~ibot@rikers.org)
19:19.56*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
19:21.27CIA-105BRL-CAD: 03starseeker * r44490 10/brlcad/trunk/CMakeLists.txt: Ignore new hacking file
20:02.29*** join/#brlcad PrezKennedy (MK@whitecalf.net)
20:34.53CIA-105BRL-CAD: 03erikgreenwald * r44491 10/geomcore/trunk/src/interfaces/cl/gvm.lisp: fix export names. Add a gvm-open convenience function.
20:36.02CIA-105BRL-CAD: 03erikgreenwald * r44492 10/geomcore/trunk/src/interfaces/cl/ (gsserver.asd gsserver.lisp): use gvm to move files over (still entire .g file at a whack)
21:02.56CIA-105BRL-CAD: 03starseeker * r44493 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_CPackOptions.cmake.in): Take a stab at using CPack options to get the directory structure we want.
22:48.26kanzurebrlcad: after playing with BOOLE-1.1 a bit, i've found that their code fails on very simple tests
22:48.41kanzurefor instance, taking the union of two cones works for the initial values that they provide in the example file,
22:49.01kanzurebut if you move the center of the first cone by 0.1 in z, it claims the intersection curve isn't closed
22:50.04kanzurei'm hoping this is just a floating point arithmetic precision issue.. but so far i haven't been able to track this down
22:50.16kanzureif the algorithm fails for such basic operations then i don't see a point in using it
IRC log for #brlcad on 20110426

IRC log for #brlcad on 20110426

00:16.01starseekerkanzure: yeah, boole isn't the way for us to go these days
00:31.15kanzureesolid compiles and the visualizer works. yikes
00:31.33kanzuredoes anyone know about esolid's licensing? i can't find a license or copyright file anywhere
01:04.26*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177871751.dsl.bell.ca)
02:29.50*** join/#brlcad crazy_imp (~mj@a89-182-207-95.net-htp.de)
03:21.24*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
06:41.04*** join/#brlcad merzo (~merzo@193.254.217.44)
06:46.22*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
07:35.56*** join/#brlcad merzo (~merzo@193.254.217.44)
08:17.25*** join/#brlcad mafm (~mafm@36.Red-81-35-69.dynamicIP.rima-tde.net)
10:00.13CIA-105BRL-CAD: 03davidloman * r44494 10/geomcore/trunk/include/ (GeometryManifestMsg.h NetMsg.h PingMsg.h PongMsg.h): Clean up some unused includes.
10:02.02CIA-105BRL-CAD: 03davidloman * r44495 10/geomcore/trunk/src/libNet/netMsg/ (PingMsg.cxx RemoteNodenameSetMsg.cxx): Clean up a few more unused includes.
10:29.29*** join/#brlcad csanyipal (~csanyipal@226-170-85-95.dynamic.stcable.net)
10:29.37csanyipalHi,
10:32.44csanyipalI'm reading SVN/brlcad/doc/legal/bdl.txt, bsd.txt, lgpl.txt and want to know, whether can I use the html documents in a Moodle course of BRL-CAD?
11:07.19CIA-105BRL-CAD: 03davidloman * r44496 10/geomcore/trunk/tests/unit/utility/ (ByteBufferUTest.cxx ByteBufferUTest.h): Clean up extra newlines
11:18.51*** join/#brlcad mafm_ (~mafm@36.Red-81-35-69.dynamicIP.rima-tde.net)
11:20.13CIA-105BRL-CAD: 03davidloman * r44497 10/geomcore/trunk/tests/unit/libnet/ (4 files): Drop the 's' from Msgs
11:22.29*** join/#brlcad merzo (~merzo@193.254.217.44)
11:57.16brlcadcsanyipal: you sure can -- most of the docs are either bsd-licensed or public domain
11:57.37csanyipalbrlcad: thanks! :)
12:08.58brlcadkunigami, bhinesley congratulations and thanks :)
12:09.26brlcadyou guys were the clear choices
12:10.24brlcadas for mentors, keep in mind that you can and SHOULD utilize the mentoring resources of any brl-cad developer
12:11.00brlcadthe one assigned is merely the one that will likely be tracking your progress and filling out your evals, but technical assistance is from all
12:30.42starseekerkanzure: I'd try the contact emails: http://research.cs.tamu.edu/keyser/geom/esolid/releases/version_0.3/README.htm  see if they'd be OK with LGPL or BSD license
12:31.43starseekerkanzure: bear in mind esolid is sssslllooowww, if what I remember about it is accurate.  It's not a method we'd want to rely on except perhaps as a last-ditch fallback
13:09.46CIA-105BRL-CAD: 03davidloman * r44498 10/geomcore/trunk/ (4 files in 3 dirs): No reason for GSUUID to take a pointer to a string.
13:14.49starseekerasc2g isn't processing the attr command using ged_attr
13:37.46CIA-105BRL-CAD: 03davidloman * r44499 10/geomcore/trunk/src/utility/ByteBuffer.cxx: Make ByteBuffer::toHexString() format the hex string properly.
13:51.33CIA-105BRL-CAD: 03davidloman * r44500 10/geomcore/trunk/ (6 files in 5 dirs): Make GSUUID::toString return a string, not a pointer. All uses of this call were simply dereferencing the pointer anyway, and most weren't releasing the memory. Keeping it simpler this way.
13:54.17CIA-105BRL-CAD: 03davidloman * r44501 10/geomcore/trunk/tests/func/ (3 files in 3 dirs): More GSUUID::toString() pointer dereferencing.
13:56.52CIA-105BRL-CAD: 03starseeker * r44502 10/brlcad/trunk/src/libged/attr.c: Standardize the avs used by attr set - this still isn't fixing asc2g, which uses an older style API of some sort.
14:05.18CIA-105BRL-CAD: 03davidloman * r44503 10/geomcore/trunk/tests/unit/ (5 files in 2 dirs): Rename NetMsgUTest to TypeOnlyMsgUTest for clarity. Finished implementing TypeOnlyMsgUTest. Will serve as the baseline test for all netmsg subclasses.
14:05.35``Erikhm, if I understand correctly, passing a class by value creates a copy on the stack (with a constructor call) and destructor on return, that's why I was going pointer happy (defining pass by reference is a different way to invoke pointer shtuff, iirc... been a long time)
14:07.20dloman_understood, however the more pointers there are, the much higher chance there is of a leak.  So i simplified a bit.  If its a perf hit, then someone can optimize later :)
14:10.19``Erik*shrug* *pats the lithp version, with generational compacting garbage collection*
14:10.53dloman_oh how i wish i could have used a language with memory management :)
14:11.03``Erikjava's gc is pretty good if you remember to set the turds to null when you're done with them... d'no about recently, but it USED to get confused and leave them
14:11.49dloman_ya.  it will still gs them, but it takes a significant amount of additional checks to figger out if the pointer isn't being used anymore
14:11.50``Erikcyclic references with no top level heap walk, etc
14:12.29``Erikhm, probably using ref counting for the first few generations, then a heap walker of some kind in the older generations, or 'on occasion'
14:12.38dloman_exactly
14:12.54dloman_which is why the young gneneration gc is wicked fast.
14:13.51dloman_been looking at C# a lot recently.  rather interesting langauge
14:13.54CIA-105BRL-CAD: 03davidloman * r44504 10/geomcore/trunk/tests/unit/libnet/TypeOnlyMsgUTest.cxx: Ooops. Forgot to update the header include!
14:14.01``Erikbtw, why are ya shuffling a 128 bit number around as a hex string? (uuids)
14:14.38dloman_cause i haven't gotten around to just writing the bytes to the ByteBuffer yet.  keeps the debugging of the proto easier too.
14:15.28``Erikkinda likes the notion fo starting out as a pure ascii format, then having a command to switch to a tight binary
14:15.41``Erikso you can get the protocol sorted using telnet :)
14:15.45CIA-105BRL-CAD: 03davidloman * r44505 10/geomcore/trunk/tests/unit/libnet/TypeOnlyMsgUTest.cxx: Again... wrong header.
14:16.17dloman_well, i have a severe lack of experience with this, hence the severe lateness. :/
14:26.22*** join/#brlcad WhiteCalf (MK@whitecalf.net)
14:27.40CIA-105BRL-CAD: 03davidloman * r44506 10/geomcore/trunk/tests/unit/ (4 files in 2 dirs): Compact test classes down to single files instead of class impl and header pairs.
14:30.51CIA-105BRL-CAD: 03davidloman * r44507 10/geomcore/trunk/tests/unit/ (libnet/TypeOnlyMsgUTest.cxx utility/ByteBufferUTest.cxx): CPPUNIT_TEST_CUITE_REGISTRATION() calls are supposed to be *after* class declaration.
14:42.38CIA-105BRL-CAD: 03davidloman * r44508 10/geomcore/trunk/ (3 files in 3 dirs): Pull two unused methods out.
15:10.12*** join/#brlcad merzo (~merzo@193.254.217.44)
15:42.46CIA-105BRL-CAD: 03Erik 07http://brlcad.org * r2857 10/wiki/NetMsgTypes: Add ls message req/res. Add multistring msg.
15:44.47CIA-105BRL-CAD: 03erikgreenwald * r44509 10/geomcore/trunk/include/NetMsgTypes.h: add bot request and list request/result.
15:47.37dloman_``Erik: whats the difference between GeometryBotReq and GeometryReq?
15:48.22CIA-105BRL-CAD: 03Erik 07http://brlcad.org * r2858 10/wiki/GenericMultiStringMsg: multistring message
15:48.42``ErikGeometryBoTReq returns BoT's, one per region (no CSG) for use in OGL, vsl, isst, etc
15:49.15dloman_so its a request for geometry + request for conversion to bot ?
15:49.46``Erikyeh, sorta... hopefully we can cache the BoT variants of the regions, and will have fast robust tesselation soon
15:51.11dloman_ideally, a 'convert to BoT' would be a bit set on a normal geometry request msg.  we can do that, now, if it would be easier for you?  (it'd be better in the long run too)
15:52.03``Erikit already is a bit :D GEOMETRYREQ | 0x1
15:52.53``Erikif you want to shuffle the interface a bit, doesn't bother me... it's just one of the things that'll be needed, "gimme something I can trivially shove in opengl"
15:53.47dloman_no worries, just looking to keep things from getting jumbled up.
15:53.59dloman_whats the ListReq and ListRes for?
15:54.28``Eriklooking around the server side geometry from a client, to find what you want to request
15:54.56dloman_as in 'directory listing' type stuff?
15:55.03``Erikyeah
15:55.06dloman_kewl
15:55.19``Erik"ls /" -> "havoc.g" "ktank.g" "m35.g"
15:55.36``Erik"ls /havok/all.g/" -> "light" "component" "plane"
15:55.59dloman_gotcha
15:56.14``Eriker, well, you get what I mean... to make like a geometry viewer type thing work over the protocol
15:57.16``Erikthe 'list request' may eventually turn into some kind of query language, ah surpose
16:00.06dloman_EQL
16:08.16bhinesleybrlcad: 10-4, thank you
16:08.57CIA-105BRL-CAD: 03Erik 07http://brlcad.org * r2859 10/wiki/NetMsgTypes: call the manifest a genericmultistring instead of a 'special'
16:10.03CIA-105BRL-CAD: 03Erik 07http://brlcad.org * r2860 10/wiki/GenericMultiStringMsg: Update to mirror the manifest format
16:12.05dloman_hey, i like things being special :P
16:17.56CIA-105BRL-CAD: 03erikgreenwald * r44510 10/geomcore/trunk/src/interfaces/cl/ (gsclient.lisp gsnet.lisp gsserver.lisp): implement ls/lsr
16:17.58``Erikthe pattern repeated, that's when ya abstract it :)
16:23.47*** join/#brlcad ibot (~ibot@rikers.org)
16:23.47*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
17:18.08CIA-105BRL-CAD: 03erikgreenwald * r44511 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: fix message types
17:18.18CIA-105BRL-CAD: 03erikgreenwald * r44512 10/geomcore/trunk/src/interfaces/cl/ (gsserver.lisp gvm.lisp): throw an exception when gvm-open doesn't work
17:19.08CIA-105BRL-CAD: 03erikgreenwald * r44513 10/geomcore/trunk/src/interfaces/cl/gsclient.lisp: handle a failmsg in response to a geometry request
17:26.04CIA-105BRL-CAD: 03davidloman * r44514 10/geomcore/trunk/tests/unit/libnet/TypeOnlyMsgUTest.cxx: Formatting
17:27.10CIA-105BRL-CAD: 03davidloman * r44515 10/geomcore/trunk/tests/unit/libnet/GeometryReqMsgUTest.cxx: Implement the GeometryReqMsg unit test
18:04.42*** join/#brlcad crazy_im1 (~mj@a89-182-207-95.net-htp.de)
18:48.49kanzurestarseeker: how slow is too slow?
18:49.05kanzurei've been testing out esolid and the entire program itself runs in 700msec, but i don't think that's the algorithm's time itself
18:49.10kanzurethat's also file reading/loading, allocation, etc.
18:49.24kanzure(700msec for various union/difference/intersection tests i've tried)
18:50.24kanzurei might just drive over to college station and show up at keyser's office and ask him about esolid.. he's relatively local to me (2h drive)
18:54.24kanzurethere's some brlcad constants defined in esolid in a few places
18:56.40*** part/#brlcad csanyipal (~csanyipal@226-170-85-95.dynamic.stcable.net)
19:27.45``Erikwhat kind of complexity is the 700ms case? (and yeah, that's probably mostly file i/o, parsing, etc)
19:28.29CIA-105BRL-CAD: 03bob1961 * r44516 10/brlcad/trunk/ (5 files in 4 dirs): Modify asc2g to use libtclcad.
19:33.07``Erik"esolid assumes that all solids are in general position" <-- could that be the 0.1 +z issue?
22:17.16CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:212.92.142.160]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
23:58.19*** join/#brlcad bhinesley (~bhinesley@adsl-99-104-168-20.dsl.bkfd14.sbcglobal.net)
IRC log for #brlcad on 20110427

IRC log for #brlcad on 20110427

01:33.45*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
02:21.20starseekerhah, cool:  http://ascendwiki.cheme.cmu.edu/ASCEND_overview
02:24.29*** join/#brlcad PrezKennedy (MK@whitecalf.net)
02:28.20starseekerhuh:  http://www.google-melange.com/gsoc/org/google/gsoc2011/cse_tuwien
02:29.18*** join/#brlcad crazy_imp (~mj@a89-182-53-208.net-htp.de)
03:03.08starseekerooo - http://www.google-melange.com/gsoc/project/google/gsoc2011/carlosmn/13001
05:53.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:09.57*** join/#brlcad primary (debian-tor@gateway/tor-sasl/primary)
07:10.05primaryHot damn.
07:24.54*** join/#brlcad kanzure_ (~goonie@neuroblastoma.cs.pdx.edu)
07:25.31primaryCan anyone here recommend a high resolution TEMPEST resistant display monitor for use with BRL-CAD?
07:37.18primarywhat is he planning on doing
08:19.11*** join/#brlcad mafm_ (~mafm@18.Red-88-23-77.staticIP.rima-tde.net)
10:40.27*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
10:40.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:08.08*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
11:25.47CIA-105BRL-CAD: 03davidloman * r44517 10/geomcore/trunk/tests/unit/utility/ByteBufferUTest.cxx: Make ByteBuffer unit test check for proper Limit settings.
11:27.29CIA-105BRL-CAD: 03davidloman * r44518 10/geomcore/trunk/src/utility/ByteBuffer.cxx: Fix limit setting bugs
12:00.14*** join/#brlcad Stattrav (~Stattrav@122.172.42.236)
12:00.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:57.44CIA-105BRL-CAD: 03davidloman * r44519 10/geomcore/trunk/tests/unit/libnet/ (GeometryReqMsgUTest.cxx TypeOnlyMsgUTest.cxx): Collect common header tests into common function, only on a per class basis.
13:29.45dloman_``Erik: you around today?
13:36.06``Erikayup
13:39.28CIA-105BRL-CAD: 03davidloman * r44520 10/geomcore/trunk/ (2 files in 2 dirs): Implement Unit test for GeometryManifestMsg. Fixed some bugs, should be working much smoother now.
13:39.39*** join/#brlcad kanzure (~kanzure@131.252.130.248)
13:56.08CIA-105BRL-CAD: 03davidloman * r44521 10/geomcore/trunk/tests/unit/libnet/GeometryManifestMsgUTest.cxx: Remove some accidental copy/paste vomit.
14:51.27CIA-105BRL-CAD: 03r_weiss * r44522 10/brlcad/trunk/src/librt/primitives/nmg/nmg_manif.c:
14:51.27CIA-105BRL-CAD: Updated functions 'paint_face' and 'nmg_shell_manifolds' within file
14:51.28CIA-105BRL-CAD: 'nmg_manif.c'. There was a datatype mismatch in the function parameters and some
14:52.18CIA-105BRL-CAD: 03davidloman * r44523 10/geomcore/trunk/ (2 files in 2 dirs): Fix up some inheritance problems by making GeometryChunk a direct subclass of NetMsg rather than GenericMultiByteMsg.
14:55.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:01.41``Eriknice http://gaming.operationreality.org/2011/04/26/crytek-for-free-cryengine-3-sdk-and-editor/
15:03.03dloman_wow, complete code access.... that's unusual!  They're lawyers must be on standby :)
15:03.42CIA-105BRL-CAD: 03r_weiss * r44524 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c:
15:03.43CIA-105BRL-CAD: Updated function 'nmg_bool' within file 'nmg_bool.c'. Moved this change from the
15:03.43CIA-105BRL-CAD: triangulation prototype code to the main code. This change corrects a corruption
15:03.44CIA-105BRL-CAD: problem with the class list array. This will improve the sucess of boolean
15:03.44CIA-105BRL-CAD: operations on facetized cgs geometry.
15:07.21*** join/#brlcad Stattrav (~Stattrav@117.192.157.232)
15:07.21*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:12.52*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:19.33dloman_Just when I thought patriotism was dead: http://www.ihatethemedia.com/a-simple-way-to-stop-westboro-baptist-church-funeral-protesters
15:19.38dloman_love it.
16:24.57*** join/#brlcad mafm (~mafm@18.Red-88-23-77.staticIP.rima-tde.net)
16:33.14*** join/#brlcad dli (~dli@67.55.46.44)
16:46.20CIA-105BRL-CAD: 03r_weiss * r44525 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: Updated functions 'nmg_class_pt_e', 'nmg_2lu_identical', 'class_shared_lu' and 'nmg_classify_lu_lu' within file 'nmg_class.c'. Changes were made to compare against SMALL_FASTF instead of '0.0'.
16:46.37dloman_woooo, go Rich go!
16:48.41*** join/#brlcad Stattrav (~Stattrav@117.192.131.229)
16:48.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:57.33dloman_kicks sf.net
16:57.39dloman_come on... FASTER!
17:00.13CIA-105BRL-CAD: 03davidloman * r44526 10/geomcore/trunk/src/libNet/NetMsgFactory.cxx: Two bug fixes. NetMsg parse was failing due to a >= being used instead of a <. Also make peeking at the MsgType remember start position instead of assuming a rewind to position:0
17:06.52*** join/#brlcad Stattrav (~Stattrav@117.192.131.229)
17:06.52*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:08.05*** join/#brlcad Stattrav (~Stattrav@117.192.131.229)
17:08.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:09.16*** join/#brlcad Stattrav (~Stattrav@117.192.131.229)
17:09.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:38.47CIA-105BRL-CAD: 03r_weiss * r44527 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed)
17:38.47CIA-105BRL-CAD: Updated the prototype version of function 'nmg_triangulate_fu' doing some
17:39.12CIA-105BRL-CAD: cleanup and re-factoring. The re-factoring created function 'nmg_isect_lseg3_eu'
17:39.12CIA-105BRL-CAD: to test if a line segment intersects with any edgeuse within a faceuse. Updated
17:39.12CIA-105BRL-CAD: the function 'nmg_triangulate_rm_degen_loopuse' adding code to verify each
18:12.14*** join/#brlcad Stattrav (~Stattrav@117.192.131.229)
18:12.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:28.23dloman_okay, this is wierd.
18:29.11dloman_using pkg, i have confirmed sending 350k on one end, but pkg is reporting recv-ing 25k on the other end.
18:29.32dloman_digs into pkg.
18:45.01*** join/#brlcad Stattrav (~Stattrav@117.192.131.229)
18:45.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:52.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:26.41kanzure<PROTECTED>
19:27.01kanzurehttp://heybryan.org/shots/2011-04-27-1357-boolean-nurbs.png
19:27.02kanzurehttp://diyhpl.us/~bryan/irc/esolid_output.txt
19:27.18kanzureprogress! now i have a "known good" and i can slowly start to chip away at it
19:41.08``Erikneat
19:41.37``Erikesolid is a python thang? does that mean porting it to C, as well?
19:42.34``Erikdo the surfaces that touch eachother share trimming curves? are the black speckles at the seams from tesselating for ogl?
19:53.54kanzureesolid is written in C++ and doesn't have a LICENSE file (i should ask the guy if he could public domain it, though)
19:54.02kanzurei've been writing my own version in python that is "similar" to esolid
19:54.57kanzuresurfaces that touch each other do share trimming curves
19:55.11kanzurealso, that screenshot sucks- a union doesn't demonstrate what's going on
19:55.13kanzurehttp://heybryan.org/shots/2011-04-27-1440-boolean-nurbs-difference.png
19:55.36kanzurethe visualizer is some wacky shit, i don't think it's using the opengl nurbs routines and is just doing its own tessellation so it probably sucks a lot
19:57.42``Erikokie, impressive
20:01.34kanzurei also have made a swig wrapper for the C++ version to interface with python
20:01.54kanzurein particular so that i can slowly replace the C++ versions with my own versions, which so far i've been trying to simplify..
20:02.02kanzurethe C++ code base for esolid has a lot of redundancies, it's ridiculous
20:02.17kanzurehere's an if-then block for instance.. http://diyhpl.us/~bryan/irc/refactored0.txt
20:02.21kanzurebottom of the file is my refactored version
20:04.51``Eriktoo bad esolid is 'school' related, otherwise it may be worth submitting some of it to http://thedailywtf.com/
20:05.16kanzureby comparison boole-1.1 is significantly worse than esolid
20:05.32kanzurebut it makes me wonder.. did some poor human actually write this code?
20:05.42``Erikof course
20:05.48kanzurethere's maybe 10 to 20,000 LOC here... what did they do?
20:05.54kanzurejust write it all at once and pray it works the first time?
20:05.56kanzurethere's no unit tests
20:06.02``Erikprobably a couple undergrads did it
20:06.51kanzurecode quality is fairly consistent i think it was just john keyser entirely
20:07.17kanzuremakes sense; he's over at TAMU now running their scholastic comp sci / programming competitive action force team
20:07.48*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680420.dsl.bell.ca)
20:08.10kanzurenext thing on my todo list is figuring out how to check my python versions against the swigged versions
20:08.28kanzuresince swig won't accept my ArbitraryPatch against its _SWIGGED_K_PATCH object
21:44.30kanzurehow do i make up unit tests when i don't know what the values should be?
22:22.19``Erikhm, thennnnn ya don't understand the math you're trying to implement and should learn it?
22:24.18primaryRUDE
22:45.58kanzure``Erik: No, rather "nobody has ever tested any of this, so it could all be wrong anyway."
22:49.39kanzureand, even if you do understand the math, your code can still be wrong
23:20.01``Erik'this' being the esolid implementation?
23:29.43``Erikkinda odd that the ogre guys would do "things and stuff" to their code to require xcode to build on a mac, instead of allowing a unix style build. :/
23:33.26``Erikfor unit testing, is there a paper related that could help? deductive reasoning on the code comments/name/impl? I've seen "unit tests" created by simply feeding in inputs, recording the outputs, and calling those the "correct" values, not quite right... :)
23:49.06primarybecause mac
23:49.07primarySorry, wrong channel.
23:49.07primarykeyword highlighting
IRC log for #brlcad on 20110428

IRC log for #brlcad on 20110428

00:14.41*** join/#brlcad kunigami1 (~kunigami@187.106.4.220)
01:59.17kanzure``Erik: there's lots of strategies for testing
01:59.38kanzuresome people do unit tests, functional tests, integration tests, automated testing frameworks, non-automated testing frameworks, all sorts of stuff sold in books..
01:59.43kanzurebrlcad has a testing suite, right?
02:04.44``ErikBRL-CAD has function tests and regression tests, no real unit tests
02:05.45``ErikI advocated real unit testing for a "big" gov't project, wrote a couple papers outlining the full testing stack, pros, cons, etc... I'm quite aware of the different categories :)
02:06.15kanzurefun times.
02:06.38``ErikI'd argue that to make a real unit test, you must completely understand what the functional unit you're testing is supposed to do, there can be no ambiguity in the contract
02:06.54primary``Erik: Do you have links to those papers?
02:07.44``Eriknot sure they're public yet, I'll ask around tomorrow... I wrote them as internal documents and some drama with a small minded idjit stopped the regular release cycle
02:26.21primarywhat license do you publish them under ``Erik
02:30.09*** join/#brlcad crazy_imp (~mj@a89-183-124-85.net-htp.de)
04:05.38*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
06:18.23*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:18.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:53.58*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:05.27*** join/#brlcad mafm (~mafm@5.Red-81-38-237.dynamicIP.rima-tde.net)
09:35.54*** join/#brlcad Stattrav (~Stattrav@122.172.12.161)
09:35.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:46.02*** join/#brlcad mafm_ (~mafm@5.Red-81-38-237.dynamicIP.rima-tde.net)
13:00.21*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
13:00.21*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:14.10starseekerhmm:  http://software.intel.com/en-us/blogs/2011/04/04/tbb-adoption-in-cad-technical-insights/
14:15.02``Erikstarseeker, why'd you break everyone's computers? :D (you bailed before I could find ya)
14:17.47``Erikstarseeker: in your FindTCL.cmake, you have something where you set include paths to ${TCL_INCLUDE_PATH}/../generic ... why the ../ ? on fbsd, TCL_INCLUDE_PATH resolves to /usr/local/include/tcl8.5, adding /usr/local/include/tcl8.5/../generic doesn't quite work
14:19.38*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
14:19.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:20.04starseeker``Erik: erm.  I don't recall, unfortunately
14:22.25CIA-105BRL-CAD: 03r_weiss * r44528 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: (log message trimmed)
14:22.25CIA-105BRL-CAD: Updated functions 'nmg_do_radial_join', 'nmg_radial_build_list',
14:22.26CIA-105BRL-CAD: 'nmg_two_face_fuse' and 'nmg_ck_fu_verts' within file 'nmg_fuse.c'. For function
15:40.32*** join/#brlcad Stattrav (~Stattrav@117.192.134.244)
15:40.32*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:46.53*** join/#brlcad Stattrav (~Stattrav@117.202.27.145)
15:46.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:14.33*** join/#brlcad Stattrav (~Stattrav@117.202.17.251)
16:14.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:11.26*** join/#brlcad dli (~dli@67.55.46.44)
17:38.26CIA-105BRL-CAD: 03starseeker * r44529 10/geomcore/trunk/CMake/FindBRLCAD.cmake: Add tclcad to the list
18:54.42*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879058.dsl.bell.ca)
19:09.25CIA-105BRL-CAD: 03erikgreenwald * r44530 10/rt^3/trunk/cmake/FindBRLCAD.cmake: add bin to the library path for winderz
20:06.08*** join/#brlcad WhiteCalf (MK@whitecalf.net)
20:12.21*** join/#brlcad PrezWhiteCalf (MK@whitecalf.net)
20:17.46*** join/#brlcad WhiteCalf (MK@whitecalf.net)
20:25.43*** join/#brlcad PrezWhiteCalf (MK@whitecalf.net)
20:31.00*** join/#brlcad WhiteCalf (MK@whitecalf.net)
20:32.32*** join/#brlcad PrezKennedy (MK@whitecalf.net)
20:54.13*** join/#brlcad Computer (~Computer@unaffiliated/computer)
20:55.08Computerwhat do you personally use brlcad for?
22:09.33CIA-105BRL-CAD: 03Sapphire02 07http://brlcad.org * r2862 10/wiki/How_To_Know_About_A_Payday_Loan: New page: == Payday Loan - How To Know About A Payday Loan == There are some cases wherein you are not able to meet your expenses. Thus, people get to involve themselves on having loans. One...
22:12.09CIA-105BRL-CAD: 03Sapphire02 07http://brlcad.org * r2863 10/wiki/How_To_Know_About_A_Payday_Loan: /* Payday Loan - How To Know About A Payday Loan */
22:19.23dliwhat's going on with Sapphire02?
22:33.16*** join/#brlcad kunigami1 (~kunigami@187.106.4.220)
22:37.43*** join/#brlcad mafm_ (~mafm@21.Red-83-35-148.dynamicIP.rima-tde.net)
IRC log for #brlcad on 20110429

IRC log for #brlcad on 20110429

02:16.05*** join/#brlcad Stattrav (~Stattrav@117.202.17.251)
02:16.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
02:29.53*** join/#brlcad crazy_imp (~mj@a89-182-29-122.net-htp.de)
03:13.17CIA-105BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[How To Know About A Payday Loan]]": spam
06:02.49*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:02.49*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:15.19*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:15.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:32.42*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:32.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:01.09*** join/#brlcad Stattrav (~Stattrav@14.96.220.57)
07:01.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:33.04*** join/#brlcad Stattrav (~Stattrav@14.96.220.57)
07:33.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:45.03*** join/#brlcad mafm_ (~mafm@188.Red-88-22-161.staticIP.rima-tde.net)
09:53.31*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:21.29*** join/#brlcad mafm (~mafm@188.Red-88-22-161.staticIP.rima-tde.net)
10:51.58CIA-105BRL-CAD: 03davidloman * r44531 10/geomcore/trunk/src/utility/ByteBuffer.cxx: Removed a stray malloc from ByteBuffer::compact() and added a zero length string check in ByteBuffer::toHexString()
10:55.48CIA-105BRL-CAD: 03davidloman * r44532 10/geomcore/trunk/src/libNet/NetMsgFactory.cxx:
10:55.48CIA-105BRL-CAD: Switched the minimum available data check from using ByteBuffer()::limit() to
10:55.48CIA-105BRL-CAD: using ByteBuffer::remaining(). Using limit assumes that position is zero, which
12:59.24dloman_hrm, really really strange.  getting garbage in the data when sending large amounts (aka 350k) thru pkg.
13:22.27dloman_also, if i try to use pkg_send() to send all 350k at once, pkg_send() reports that all data has been sent, however, only about 25k shows up on the other side :/
13:36.18*** join/#brlcad PrezKennedy (MK@whitecalf.net)
14:29.41*** join/#brlcad PrezKennedy (MK@whitecalf.net)
15:36.31CIA-105BRL-CAD: 03tbrowder2 * r44533 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeIII.xml: delete spurious 'b'
16:16.09*** join/#brlcad joevano (~joevano@bzflag/developer/JoeVano)
16:16.55joevanobrlcad: Happy Birthday!
17:54.44CIA-105BRL-CAD: 03starseeker * r44534 10/brlcad/trunk/doc/docbook/system/mann/en/search.xml: Add brep to the search primitive types list.
18:08.43*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
19:04.49*** join/#brlcad Stattrav (~Stattrav@117.192.138.156)
19:04.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:00.10CIA-105BRL-CAD: 03starseeker * r44535 10/brlcad/trunk/doc/docbook/system/mann/en/search.xml: Whoops, how about valid xml.
20:08.09CIA-105BRL-CAD: 03bob1961 * r44536 10/brlcad/trunk/src/Makefile.am: Promote libdm and libtclcad from kitchensink_dirs to bench_dirs. Reason - asc2g needs libtclcad.
20:10.49CIA-105BRL-CAD: 03bob1961 * r44537 10/brlcad/trunk/include/raytrace.h: Added RT_APPLICATION_NULL macro.
20:12.51CIA-105BRL-CAD: 03bob1961 * r44538 10/brlcad/trunk/include/ged.h: Add enclosing parens to a few NULL macros.
20:27.23CIA-105BRL-CAD: 03starseeker * r44539 10/brlcad/trunk/src/libged/search.c: Make a stab at improving behavior of search when multiple paths are supplied.
21:59.35CIA-105BRL-CAD: 03bob1961 * r44540 10/brlcad/trunk/ (include/tclcad.h src/libtclcad/tclcad_obj.c): Refactor a big chunk of to_rt_gettrees into to_rt_gettrees_application.
22:24.32*** join/#brlcad kunigami1 (~kunigami@187.106.4.220)
22:28.01*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
IRC log for #brlcad on 20110430

IRC log for #brlcad on 20110430

02:29.38*** join/#brlcad crazy_imp (~mj@a89-182-9-99.net-htp.de)
06:09.23*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:09.25*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:22.40*** join/#brlcad mafm (~mafm@124.Red-83-45-72.dynamicIP.rima-tde.net)
10:18.04*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
10:18.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:49.14*** join/#brlcad merzo (~merzo@112-206-94-178.pool.ukrtel.net)
12:33.58*** join/#brlcad dli (~dli@67.55.46.44)
14:13.47*** join/#brlcad kunigami1 (~kunigami@187.106.4.220)
15:15.18*** join/#brlcad crazy_imp (~mj@a89-182-9-99.net-htp.de)
15:22.53*** part/#brlcad kunigami1 (~kunigami@187.106.4.220)
15:23.01*** join/#brlcad kunigami1 (~kunigami@187.106.4.220)
16:20.53*** join/#brlcad Stattrav (~Stattrav@117.192.148.252)
16:20.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:21.21*** join/#brlcad mafm (~mafm@124.Red-83-45-72.dynamicIP.rima-tde.net)
16:39.04*** join/#brlcad joevano (~joevano@c-71-193-108-171.hsd1.in.comcast.net)
16:39.04*** join/#brlcad joevano (~joevano@bzflag/developer/JoeVano)
17:54.05*** join/#brlcad crazy_imp (~mj@a89-182-9-99.net-htp.de)
17:57.21*** join/#brlcad PrezKennedy (MK@whitecalf.net)
18:41.26*** join/#brlcad Stattrav (~Stattrav@117.192.148.252)
18:41.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:37.48*** part/#brlcad joevano (~joevano@bzflag/developer/JoeVano)
21:23.54*** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net)
22:46.31*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680386.dsl.bell.ca)
22:58.55*** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680386.dsl.bell.ca)
22:59.20*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680386.dsl.bell.ca)
22:59.59*** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177680386.dsl.bell.ca)
IRC log for #brlcad on 20110501

IRC log for #brlcad on 20110501

01:26.25*** join/#brlcad merzo (~merzo@112-206-94-178.pool.ukrtel.net)
02:30.43*** join/#brlcad crazy_imp (~mj@a89-182-3-78.net-htp.de)
02:36.30*** join/#brlcad kunigami1 (~kunigami@187.106.4.220)
02:37.41kunigami1hi guys, let me ask a newbie question: in this github project (https://github.com/fohr/openshadinglanguage/tree/testrender), there's a link to download the source code, namely: https://github.com/fohr/openshadinglanguage.git
02:38.25kunigami1but when I do: git clone https://github.com/fohr/openshadinglanguage.git, it downloads a different version from that available from the download button: https://github.com/fohr/openshadinglanguage/tarball/testrender
02:39.19kunigami1does any one know how do I get this branch with git? thanks
02:51.51dlikunigami, the button gives you tagged version
02:57.47kunigami1dli, I'm not used to git, but your answer helped me to find what I wanted. After cloning I just had to do 'git checkout testrender' to switch to the desired branch
02:58.27dlikunigami, different branches, try: git branch -a
03:06.15kunigami1dli: this command lists the current branches and tells in which of them I am. thanks!
08:52.13*** join/#brlcad csanyipal (~csanyipal@226-170-85-95.dynamic.stcable.net)
08:52.18csanyipalHi,
08:57.35csanyipalI have a working copy of brlcad SVN repository, the svnversion number is: 41797.
08:59.20csanyipalI find in the brlcad/doc/html/ directory the toc.html that has anchors to following directories: articles, books and lessons.
08:59.55csanyipalWhen one open this toc.html in a browser these anchors don't works.
09:01.08csanyipalAfter I made in brlcad/doc/html/ directory symlinks to those directories, I can use toc.html to browse these documents.
09:01.54csanyipalSo why doesn't have this brlcad/doc/html/ directory already those symlinks?
09:31.09*** join/#brlcad Stattrav (~Stattrav@117.192.136.214)
09:31.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:34.20csanyipalShould those symlinks to be in the SVN repository?
14:16.29*** join/#brlcad mafm (~mafm@240.Red-83-40-127.dynamicIP.rima-tde.net)
14:55.09*** join/#brlcad kunigami1 (~kunigami@187.106.4.220)
14:55.18*** part/#brlcad kunigami1 (~kunigami@187.106.4.220)
14:55.23*** join/#brlcad kunigami1 (~kunigami@187.106.4.220)
19:40.03*** join/#brlcad mafm_ (~mafm@240.Red-83-40-127.dynamicIP.rima-tde.net)
20:11.36csanyipalI used BRL-CAD documentation for a Moodle course here: http://edu.csanyi-pal.info/moodle/ called 'BRL-CAD Articles, Books and Lessons'.
20:37.24*** join/#brlcad Stattrav (~Stattrav@117.192.129.83)
20:37.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
IRC log for #brlcad on 20110502

IRC log for #brlcad on 20110502

00:02.41*** join/#brlcad mafm_ (~mafm@53.Red-83-37-177.dynamicIP.rima-tde.net)
01:39.30*** part/#brlcad kunigami1 (~kunigami@187.106.4.220)
02:30.30*** join/#brlcad crazy_imp (~mj@a89-183-71-182.net-htp.de)
03:09.49*** join/#brlcad WhiteCalf (MK@whitecalf.net)
03:27.28*** join/#brlcad PrezKennedy (MK@whitecalf.net)
05:08.21*** join/#brlcad csanyipal (~csanyipal@226-170-85-95.dynamic.stcable.net)
05:08.33csanyipalHi,
07:58.17*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:28.11*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
08:28.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:37.15*** join/#brlcad mafm_ (~mafm@132.Red-83-45-252.dynamicIP.rima-tde.net)
13:26.13*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
13:26.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:27.13CIA-105BRL-CAD: 03davidloman * r44541 10/geomcore/trunk/src/utility/ByteBuffer.cxx: Include string.h to make compile without grumbles on ubuntu.
13:34.19CIA-105BRL-CAD: 03davidloman * r44542 10/geomcore/trunk/src/ (2 files in 2 dirs): printf was expecting a long long unsigned int but was getting passed a long unsigned in. Fixt.
13:37.34*** join/#brlcad PrezKennedy (MK@whitecalf.net)
13:39.33*** join/#brlcad PrezKennedy (MK@whitecalf.net)
13:40.45*** join/#brlcad WhiteCalf (MK@whitecalf.net)
13:41.42*** join/#brlcad PrezWhiteCalf (MK@whitecalf.net)
13:49.45*** join/#brlcad PrezKennedy (MK@whitecalf.net)
13:55.34*** join/#brlcad PrezKennedy (MK@whitecalf.net)
14:01.52*** join/#brlcad WhiteCalf (MK@whitecalf.net)
14:14.38*** part/#brlcad csanyipal (~csanyipal@226-170-85-95.dynamic.stcable.net)
14:14.52*** join/#brlcad willdye (~willdye@fern.dsndata.com)
14:29.36*** join/#brlcad mafm (~mafm@132.Red-83-45-252.dynamicIP.rima-tde.net)
14:32.41*** join/#brlcad PrezKennedy (MK@whitecalf.net)
14:41.46*** join/#brlcad PrezKennedy (MK@whitecalf.net)
14:58.43CIA-105BRL-CAD: 03starseeker * r44543 10/brlcad/trunk/src/librt/search.c: Go with QUIET instead of NOISY for search db_lookup calls.
15:02.04*** join/#brlcad WhiteCalf (MK@whitecalf.net)
15:09.27*** join/#brlcad PrezKennedy (MK@whitecalf.net)
16:14.38*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879414.dsl.bell.ca)
16:45.18*** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879414.dsl.bell.ca)
16:45.26*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879414.dsl.bell.ca)
16:45.36*** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879414.dsl.bell.ca)
17:12.47*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
19:20.53*** join/#brlcad Stattrav (~Stattrav@117.192.138.247)
19:20.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:24.02*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
19:41.11*** join/#brlcad Stattrav (~Stattrav@117.192.138.247)
19:41.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:01.33*** join/#brlcad mafm (~mafm@132.Red-83-45-252.dynamicIP.rima-tde.net)
20:53.16*** join/#brlcad Stattrav (~Stattrav@117.192.138.247)
20:53.16*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:01.19*** join/#brlcad Stattrav (~Stattrav@117.192.138.247)
21:01.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:10.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:19.46*** join/#brlcad Stattrav (~Stattrav@117.192.138.247)
21:19.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:46.51*** join/#brlcad csanyipal (~csanyipal@226-170-85-95.dynamic.stcable.net)
IRC log for #brlcad on 20110503

IRC log for #brlcad on 20110503

02:30.15*** join/#brlcad crazy_imp (~mj@a89-183-78-204.net-htp.de)
03:51.09kanzurehrmm
03:51.19kanzurei'm currently the maintainer of an 'old' codebase from 2004-2009 called nanoengineer
03:51.36kanzureit's gplv2-licensed nanotech cad
03:52.04kanzurethere's a lot of work that was put into it (about 5 to 10 developers over 4 years)
03:52.10kanzurebut it's no longer being actively developed
03:52.42kanzurei know the license is poisonous to brlcad but maybe there's something i could that would make the code appealing to tack into brlcad? :/
04:07.58starseekerkanzure: this one?  http://nanoengineer-1.net
04:08.59starseekerGPL is (unfortunately) a non-starter - however, you can go the other way and use BRL-CAD libraries in nanoengineer
04:10.01kanzuremeh
04:10.05kanzureyeah that's one of the sites
04:10.09kanzurehttp://nanorex.com/ too
04:10.14kanzureactual code: http://diyhpl.us/cgit/nanoengineer
04:10.47starseekerkanzure: believe me, the non-GPL restriction has been painful in the past
04:11.02kanzurewell, i know everyone who wrote code in this project and copyright changes are possible
04:11.17kanzurebasically a company was paying for the development of this code base, the company went belly up
04:11.31kanzureand while i love the software i don't have time to convert all of the old libraries and dependencies and upgrade its usage
04:11.39kanzurehaving said that, there's still some useful software in here somewhere
04:11.42starseekerLGPL-v2 or Modified BSD both work
04:11.59kanzureit's not directly related to solid modeling of course- it's atomically-precise CAD
04:12.24kanzureso the overall utility to brlcad might be minimal
04:13.11starseekerhard to say without a closer look
05:54.36Ralithkanzure: you could talk to the old devs and attempt a relicense; it'll be hard, but they'd probably rather their code be used at all than not.
05:55.10Ralitheasier if the project had some foresight and had copyright assigned to one person.
06:13.08kanzureit is
06:13.16kanzureit's assigned to the company ;)
06:13.23kanzurewhich is owned by a single dude
07:33.49*** join/#brlcad dli (~dli@67.55.46.44)
08:15.41*** join/#brlcad ScribbleJ (~scribble@99-35-164-204.lightspeed.dwgvil.sbcglobal.net)
08:15.47ScribbleJOMG an IRC channel
08:15.50ScribbleJI already love it
09:19.22*** join/#brlcad mafm (~mafm@87.Red-83-35-148.dynamicIP.rima-tde.net)
11:41.03dloman_Mernin
12:49.32``Erikyargh
13:37.09*** join/#brlcad culot (~culot@0xd0.org)
13:42.17culotHi, I am a FreeBSD committer and some days ago committed an update for the brlcad port (7.18.4) which was submitted by Erik Greenwald
13:42.42culotI tested the update on i386 and it worked well, however our automated build system reports that compilation fails on amd64
13:42.48culotsee: http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8.20110501074957/brlcad-7.18.4.log
13:43.09culotis it a known problem?
14:34.19``Erikyeah, I saw the email, my amd64 fbsd8 box is having issues at the moment, so I can't test fixes :/
14:35.34``Erik(pav emailed me, too)
14:36.45culot``Erik: ok thanks, I was not sure you received the mails so sorry for asking again here
14:37.36``Erika quick re-look makes it look like posix_memalign is defined in both /usr/include/mm_malloc.h and /usr/include/stdlib.h ... is this something that's changed on the amd64 branch?
14:37.54``Erik> /usr/include/mm_malloc.h:37: error: declaration of 'int posix_memalign(void**, size_t, size_t) throw ()' throws different exceptions
14:37.57``Erik> /usr/include/stdlib.h:160: error: from previous declaration 'int posix_memalign(void**, size_t, size_t)'
14:40.53culotI am not sure, I will have to check
15:11.18*** join/#brlcad dli (~dli@67.55.46.44)
15:13.54CIA-105BRL-CAD: 03davidloman * r44544 10/geomcore/trunk/ (2 files in 2 dirs): Add new Job: MakeAndRouteMsgJob. Will shortly supersede RouteMsgJob
16:08.01CIA-105BRL-CAD: 03starseeker * r44545 10/brlcad/trunk/src/tclscripts/mged/bindings.tcl: Don't do the mac keybinding fixes unless we're on Mac - they break zooming out on Linux.
16:18.33culot``Erik: would you be interested if I set up a jail for you on an amd64 box so you can test your fixes?
16:19.29culot``Erik: I would like to help you on this bug but I don't have much time now so I'm afraid giving you access to an amd64 box is the only help I could provide :'(
16:20.27``Eriksure, a jail would be great, I'm trying to get qemu installed on a machine right now
16:21.06culot``Erik: ok, I will give you access in a couple of minutes, just finishing the install
16:22.20``Erikawesome! if you do a depends on cad/brlcad, I wouldn't need sudo
16:22.58culotI'll give you root access so you can do whatever you need to
16:23.10``Erikaight
16:32.28culot``Erik: did you get my private message?
17:06.21``Erikyup, sorry, was talking to someone
19:21.18*** join/#brlcad Stattrav (~Stattrav@117.192.136.213)
19:21.18*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:21.45CIA-105BRL-CAD: 03starseeker * r44546 10/brlcad/trunk/ (4 files in 4 dirs): Gah. More consequences of our using Itcl/Itk internal headers. Also fix FindTCL to not return any sort of generic dir (correct or otherwise.)
19:40.36CIA-105BRL-CAD: 03starseeker * r44547 10/brlcad/trunk/src/ (3 files in 3 dirs): Need unix dir too...
19:55.36CIA-105BRL-CAD: 03davidloman * r44548 10/geomcore/trunk/ (22 files in 8 dirs):
19:55.37CIA-105BRL-CAD: Experimental build. There was something really screwy with the way pkg was
19:55.37CIA-105BRL-CAD: handling chunks of data larger than 24k, so i unwired the send and recv portions
19:55.38CIA-105BRL-CAD: of pkg and "rolled my own". Things are much more stable and much faster. There
19:55.38CIA-105BRL-CAD: is still a bit of work todo, but geomcore compiles and runs at this point.
20:46.47*** join/#brlcad mafm (~mafm@255.Red-88-11-184.dynamicIP.rima-tde.net)
22:48.52*** join/#brlcad merzo (~merzo@25-73-132-95.pool.ukrtel.net)
22:59.12*** join/#brlcad mafm (~mafm@255.Red-88-11-184.dynamicIP.rima-tde.net)
23:35.49*** part/#brlcad willdye (~willdye@fern.dsndata.com)
IRC log for #brlcad on 20110504

IRC log for #brlcad on 20110504

02:30.06*** join/#brlcad crazy_imp (~mj@a89-182-3-232.net-htp.de)
02:49.30*** part/#brlcad ScribbleJ (~scribble@99-35-164-204.lightspeed.dwgvil.sbcglobal.net)
05:14.03*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
05:17.46kanzurei sent an email to a prof about the licensing of his cad-related code, but he hasn't replied (it's been about a week)
05:17.51kanzureshould i follow-up with a phone call?
05:35.21CIA-105BRL-CAD: 03109.100.116.81 07http://brlcad.org * r2864 10/wiki/Main_Page: /* Third-party Projects */
07:32.06*** join/#brlcad merzo (~merzo@193.254.217.44)
07:58.47*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:23.37*** join/#brlcad mafm (~mafm@134.Red-81-35-69.dynamicIP.rima-tde.net)
10:50.27culot``Erik: FYI I committed your patch to correct the compilation issues on amd64, thanks
10:51.54``Erikcool beans, thanks
10:54.19*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
11:02.26*** part/#brlcad culot (~culot@0xd0.org)
11:27.40*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
11:56.40*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
11:58.28*** join/#brlcad pawleeq (~pavel@pc119.iabrno.cz)
11:58.33pawleeqhello
11:59.29pawleeqI have compiled 7.18.4 on ubuntu and I experience a problem with zooming in mgeds graphics window
11:59.35pawleeqit only zooms in
12:17.48*** join/#brlcad dli (~dli@67.55.46.44)
12:22.16pawleeqto be exact it zooms in on left, right and middle click
12:58.59starseekerkanzure: probably couldn't hurt
12:59.36starseekerpawleeq: just fixed that yesterday - try building latest trunk svn checkout
12:59.51pawleeqstarseeker: thank you
13:46.34CIA-105BRL-CAD: 03starseeker * r44549 10/brlcad/trunk/src/librt/CMakeLists.txt: Try not to error out on the librt-static build when optimized - metaballs are triggering some subtle problem either with the code or possibly the older compiler used for the test.
13:47.21starseeker``Erik: see if that fixes the build for you - I'd like to get a release put together, so any remining outstanding release-blocker issues I know about I'll try to squash today and tomorrow
15:36.36*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
15:36.36*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:40.03CIA-105BRL-CAD: 03starseeker * r44550 10/brlcad/trunk/src/librt/CMakeLists.txt: Whoops - fix silly typos
16:47.27CIA-105BRL-CAD: 03starseeker * r44551 10/brlcad/trunk/src/librt/CMakeLists.txt: Won't be a librt-static target unless static libs are being built.
16:57.37CIA-105BRL-CAD: 03starseeker * r44552 10/brlcad/trunk/src/vdeck/vdeck.c: Strict warning in vdeck on BSD - I think this is the fix?
17:06.15CIA-105BRL-CAD: 03starseeker * r44553 10/brlcad/trunk/src/libged/tables.c: More warnings on BSD - could also use a second opinion here.
17:19.30CIA-105BRL-CAD: 03starseeker * r44554 10/brlcad/trunk/src/mged/animedit.c: Add a few initializations.
17:20.20``Erikhrm
17:38.37CIA-105BRL-CAD: 03starseeker * r44555 10/brlcad/trunk/src/libged/editit.c: make a copy of the edit string to avoid const issues
17:48.34CIA-105BRL-CAD: 03starseeker * r44556 10/brlcad/trunk/src/libged/editit.c: er - how about using the copy while we're at it.
18:13.55CIA-105BRL-CAD: 03starseeker * r44557 10/brlcad/trunk/src/mged/ (cmd.h utility1.c): f_tables doesn't appear to be used, and looks like it lives in libged now.
18:20.25*** join/#brlcad mafm_ (~mafm@134.Red-81-35-69.dynamicIP.rima-tde.net)
20:07.21CIA-105BRL-CAD: 03Dloman 07http://brlcad.org * r2865 10/wiki/GeometryServiceNetworkProtocol: Updated header byte layout.
20:07.23CIA-105BRL-CAD: 03Dloman 07http://brlcad.org * r2866 10/wiki/GeometryServiceNetworkProtocol: removed pkg
20:12.06CIA-105BRL-CAD: 03Dloman 07http://brlcad.org * r2867 10/wiki/GeometryServiceNetworkProtocol: Drop depricated
20:13.10CIA-105BRL-CAD: 03Dloman 07http://brlcad.org * r2868 10/wiki/GeometryServiceNetworkProtocol: Remove references to pkg
20:26.56CIA-105BRL-CAD: 03erikgreenwald * r44558 10/geomcore/trunk/src/interfaces/cl/gsnet.lisp: reflect changes in GSNet protocol (elimination of magic, swapping of type and length)
21:06.07CIA-105BRL-CAD: 03erikgreenwald * r44559 10/brlcad/trunk/src/libged/ (combmem.c red.c): quell warnings
21:39.02*** join/#brlcad crazy_imp (~mj@a89-182-25-196.net-htp.de)
21:39.17*** join/#brlcad merzo (~merzo@162-173-94-178.pool.ukrtel.net)
22:40.23*** join/#brlcad Stattrav (~Stattrav@117.202.18.204)
22:40.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:52.26*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
IRC log for #brlcad on 20110505

IRC log for #brlcad on 20110505

00:08.33*** join/#brlcad docelic (~docelic@78.134.193.201)
00:20.00*** join/#brlcad docelic (~docelic@78.134.193.201)
03:04.41CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r2869 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/109.100.116.81|109.100.116.81]] ([[User talk:109.100.116.81|Talk]]); changed back to last version by [[User:Sean|Sean]]
03:05.10CIA-105BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:109.100.116.81]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
07:33.01*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
08:38.30*** join/#brlcad mafm_ (~mafm@22.Red-83-55-205.dynamicIP.rima-tde.net)
10:21.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:09.52CIA-105BRL-CAD: 03starseeker * r44560 10/brlcad/trunk/include/CMakeLists.txt: Add a couple headers.
12:34.18dloman_cd
12:34.32dloman_oops, wrong terminal =D
12:55.53*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:18.20``Erikhuh, bangor and bremerton were merged to make kitsap
13:18.43dloman_part of brac?
13:19.12``Erikback in '04
13:19.28dloman_wow, i was still in bck then.
13:19.34``Erikhttp://en.wikipedia.org/wiki/Naval_Base_Kitsap
13:19.36dloman_must be really out od sync
13:19.55``ErikI did mini-bootcamp in '91(90?) at bangor
13:20.06dloman_heh.... Why?
13:20.11``Eriknjrotc
13:20.39``Erikit was 3 days of kidgloves stuff, a 'field trip' with pt and marching
13:20.54dloman_oh yeah, forgot you was in rotc :)
13:21.33``Erikyes, post-rotc "f this s" involved growing the hair out, earrings, blue hair, etc :)
13:23.10dloman_still backlashing? :)
13:23.53``Erik(was talking to mike about things to do while sailing the area, he mentioned the fishing marker island with a picnic table and a waste deep volleyball court, which led to talk about hitting rocks or the poles, then the pic of the los angeles you pulled up yesterday, which got me reading about the incident, ... tangents on tangents)
13:24.17``Erikwaist deep, even
13:24.28dloman_was going to say, lol
13:24.36dloman_"You're playing v-ball in what?!?"
13:24.36``Erikthough with the silt and hillbilly garbage, waste deep might be correct...
13:38.20*** join/#brlcad mafm_ (~mafm@22.Red-83-55-205.dynamicIP.rima-tde.net)
14:38.36starseekerdigs in to understand how to use quaternions...
15:09.41CIA-105BRL-CAD: 03davidloman * r44561 10/geomcore/trunk/ (4 files in 4 dirs): Clean up some logger funkyness. Removed 'verbose' option. Didn't do anything anyways.
16:41.31*** join/#brlcad docelic_ (~docelic@78.134.205.19)
16:46.30kanzuremy mom runs a small business (woodworking company) and she is purchasing some software :/
16:46.33kanzurehttp://www.cabnetware.com/UserFiles/17/File/CWbrochure.pdf
16:46.46kanzureprobably going to be horribly overpriced for what it does
17:12.14``Erikstarseeker: there was an old article (late 90's?) that gave a decent programmers overview of quaternions without delving into the math, I think it was an gamasutra?
17:12.36``Erikah, here we go: http://www.gamasutra.com/view/feature/3278/rotating_objects_using_quaternions.php
17:26.26CIA-105BRL-CAD: 03davidloman * r44562 10/geomcore/trunk/src/utility/Logger.cxx: seems that bu_log is messing up the printing to stdout some how. Switch over to direct printing for now.
17:38.49CIA-105BRL-CAD: 03davidloman * r44563 10/geomcore/trunk/ (8 files in 5 dirs): Clean up some nastly little memory leaks.
17:42.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:42.48CIA-105BRL-CAD: 03starseeker * r44564 10/brlcad/trunk/src/other/ (5 files in 4 dirs): Try a setup to allow brlcad_config.h and togl_config.h to co-exist.
17:57.15*** join/#brlcad Stattrav (~Stattrav@117.192.142.113)
17:57.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:03.38CIA-105BRL-CAD: 03starseeker * r44565 10/brlcad/trunk/src/adrt/ (CMakeLists.txt isst_tcltk.c): Tweak isst code for changes and strict build - not tested yet.
18:25.48CIA-105BRL-CAD: 03starseeker * r44566 10/brlcad/trunk/src/adrt/ (CMakeLists.txt Makefile.am isst isst.tcl): Start setting up the actual Tcl/Tk application for isst.
18:27.13CIA-105BRL-CAD: 03starseeker * r44567 10/brlcad/trunk/src/adrt/isst: Borrow archer's set-up for running wish. Got successful startup of isst.
18:34.04CIA-105BRL-CAD: 03erikgreenwald * r44568 10/brlcad/trunk/src/adrt/CMakeLists.txt: add X11 include dir
19:23.47CIA-105BRL-CAD: 03starseeker * r44569 10/brlcad/trunk/src/adrt/isst: Add rudimentry ability to specify model and object on isst command line.
20:34.36CIA-105BRL-CAD: 03erikgreenwald * r44570 10/brlcad/trunk/CMakeLists.txt: look for GL/glext.h
20:35.28CIA-105BRL-CAD: 03erikgreenwald * r44571 10/brlcad/trunk/src/other/CMakeLists.txt: allow togl on non-X11 platforms. Mark TOGL_LIBRARIES and TOGL_INCLUDE_DIRS as advanced.
20:37.18CIA-105BRL-CAD: 03erikgreenwald * r44572 10/brlcad/trunk/src/other/togl/src/glext.h: add the SGI reference glext.h
20:38.06CIA-105BRL-CAD: 03erikgreenwald * r44573 10/brlcad/trunk/src/other/togl/src/togl.c: use system glext if possible, local copy if not
20:40.49*** join/#brlcad dli (~dli@66.49.170.199)
20:58.30CIA-105BRL-CAD: 03erikgreenwald * r44574 10/brlcad/trunk/src/other/togl/src/wglext.h: add local copy of wglext.h (msvc8 seems... lacking)
20:58.53CIA-105BRL-CAD: 03erikgreenwald * r44575 10/brlcad/trunk/ (CMakeLists.txt src/other/togl/src/toglWGL.c): wire in wglext.h if possible
21:20.43CIA-105BRL-CAD: 03erikgreenwald * r44576 10/brlcad/trunk/CMakeLists.txt: Define _FILE_OFFSET_BITS and _LARGEFILE64_SOURCE to 32b filesystem access to work around zlib's "little trick" that causes havoc with -Wundef.
21:28.18CIA-105BRL-CAD: 03erikgreenwald * r44577 10/brlcad/trunk/src/adrt/CMakeLists.txt: add opengl include path
21:40.48*** join/#brlcad crazy_imp (~mj@a89-183-74-132.net-htp.de)
IRC log for #brlcad on 20110506

IRC log for #brlcad on 20110506

03:19.46*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
04:14.02*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593224.dsl.bell.ca)
04:33.11*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
06:44.09*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:46.35*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:59.06*** join/#brlcad merzo (~merzo@193.254.217.44)
06:59.30*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:59.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:59.41*** join/#brlcad mafm_ (~mafm@138.Red-88-23-77.staticIP.rima-tde.net)
10:56.12*** join/#brlcad mafm (~mafm@138.Red-88-23-77.staticIP.rima-tde.net)
11:28.32d_rossbergwhat's the LIB_DIR in src/other/libregex/CMakeLists.txt?
11:29.01d_rossbergit looks like a left-over from the unrelated tcl
11:40.51*** join/#brlcad Stattrav_ (~Stattrav@122.167.171.243)
12:35.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:56.18*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:16.05starseekerd_rossberg: it should control where the library goes - it's being set by the parent CMakeLists.txt file
13:16.13starseekerare you seeing a problem?
13:16.37starseekercrosses his fingers and reboots after a major baselayout update...
13:19.17*** join/#brlcad dli (~dli@66.49.170.199)
13:22.24``Erikstarseeker: issues building togl on winderz. tkstubs.dll isn't being linked... manually added it, complained that some init func was defined in both tclStubs.dll and tcl.dll
13:32.18starseekerwinces
13:32.47starseekermight check tkhtml's cmake logic...
13:39.32``Eriklooks at bwish's cmake O.o
13:44.00starseekerthe tcl/tk related CMake logic is among the most gnarly bits, primarly because of how... personality filled Tcl/Tk's build process is to begin with
13:46.23starseekerIf I thought there was any chance of success I'd start a github of the latest tcl/tk 8.6 dev srcs and try to make a cleaned-up and comprehensive CMake build to present at the Tcl/Tk conference
13:48.19starseekercontends that Tcl/Tk's public/private API separation is seriously busted - either they need to expose enough public API to allow extensions to be implemented without having to reference internal APIs, or they need to snarf all the license compatible extensions into the core
14:02.40``Erikhm, isst exists as {builddir}/bin/isst, but does not get installed when I do "make install"
14:06.17d_rossbergstarseeker: that's the problem: LIB_DIR isn't set in any parent CMakeLists.txt file, only in tcl's CMakeLists.txt
14:08.15d_rossbergi did a grap over the whole brlcad branch
14:44.53*** join/#brlcad Stattrav (~Stattrav@117.192.130.88)
14:44.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:43.46*** join/#brlcad merzo (~merzo@178.94.161.13)
19:05.24*** join/#brlcad Stattrav (~Stattrav@117.192.130.88)
19:05.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:10.38*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
19:14.42*** join/#brlcad Stattrav (~Stattrav@117.192.130.88)
19:14.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:29.09*** join/#brlcad Stattrav (~Stattrav@117.192.130.88)
19:29.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:46.32*** join/#brlcad Stattrav (~Stattrav@117.192.130.88)
19:46.32*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:53.43*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
20:42.29CIA-105BRL-CAD: 03starseeker * r44578 10/brlcad/trunk/src/adrt/CMakeLists.txt: Add an install line for isst
20:47.22starseekernext time d_rossberg gets back - LIB_DIR is being set by the macro in the toplevel CMakeLists.txt file line 1545
20:52.11CIA-105BRL-CAD: 03starseeker * r44579 10/brlcad/trunk/src/other/togl/src/CMakeLists.txt: Use stubs on win32
20:55.20``Erikstarseeker: when installed, cmake gives me http://paste.lisp.org/display/121826 ... rm -rf /usr/brlcad/trunk and cmake works fine
21:00.00CIA-105BRL-CAD: 03erikgreenwald * r44580 10/brlcad/trunk/src/adrt/isst: add a shebang
21:04.31CIA-105BRL-CAD: 03erikgreenwald * r44581 10/brlcad/trunk/src/adrt/CMakeLists.txt: put isst in bin/ instead of lib/
21:05.05*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
21:14.03CIA-105BRL-CAD: 03erikgreenwald * r44582 10/brlcad/trunk/src/adrt/CMakeLists.txt: install as an executable instead of plain file
21:40.33*** join/#brlcad crazy_imp (~mj@a89-182-14-238.net-htp.de)
22:17.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
IRC log for #brlcad on 20110507

IRC log for #brlcad on 20110507

00:40.24*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
04:06.41CIA-105BRL-CAD: 0372.234.127.28 07http://brlcad.org * r2870 10/wiki/Documentation:
04:07.29CIA-105BRL-CAD: 0372.234.127.28 07http://brlcad.org * r2871 10/wiki/Documentation: fffff
05:57.52*** join/#brlcad Stattrav (~Stattrav@117.192.130.88)
05:57.52*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:46.32*** join/#brlcad Stattrav (~Stattrav@122.167.87.95)
06:46.32*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:12.21*** join/#brlcad merzo (~merzo@94-26-132-95.pool.ukrtel.net)
14:35.53*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
18:26.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:50.52*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
19:52.02*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
19:55.45*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
21:40.19*** join/#brlcad crazy_imp (~mj@89.182.18.71)
IRC log for #brlcad on 20110508

IRC log for #brlcad on 20110508

03:52.57*** join/#brlcad dli (~dli@66.49.170.199)
07:49.41*** join/#brlcad ibot (~ibot@rikers.org)
07:49.41*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
09:21.39*** join/#brlcad Stattrav (~Stattrav@117.192.148.24)
09:21.39*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:15.39*** join/#brlcad Stattrav (~Stattrav@117.192.148.24)
18:15.39*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:27.59*** join/#brlcad Stattrav (~Stattrav@117.192.131.205)
18:27.59*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:13.00*** join/#brlcad PrezKennedy (MK@whitecalf.net)
19:49.11*** join/#brlcad PrezKennedy (MK@whitecalf.net)
20:00.01*** join/#brlcad PrezKennedy (MK@whitecalf.net)
20:32.44*** join/#brlcad Stattrav (~Stattrav@117.192.131.38)
20:32.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:41.05*** join/#brlcad crazy_imp (~mj@a89-183-10-209.net-htp.de)
IRC log for #brlcad on 20110509

IRC log for #brlcad on 20110509

06:43.39*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:55.16d_rossbergstarseeker: because of the LIB_DIR: i still didn't got it, line 1545 in my top level CMakeLists.txt file is MESSAGE("${CONFIG_TIME_MSG_LABEL}..: ${CONFIG_TIME_MSG}")
07:45.04*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
07:45.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:02.23*** join/#brlcad Stattrav (~Stattrav@122.167.76.167)
08:02.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:50.52*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:57.10dloman_yawns
11:52.49CIA-105BRL-CAD: 03davidloman * r44583 10/geomcore/trunk/include/Portal.h: Fix includes for proper compilation on Ubuntu
13:07.57*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:42.25starseekerLIB_DIR is being set by the macro in the toplevel CMakeLists.txt file line 1545
13:43.03starseekerin trunk
13:43.16starseekerre-checks line number...
13:44.21starseekeroops
13:44.53starseeker404 rather
13:47.11starseekerd_rossberg: yeah, sorry - line 404
13:59.42d_rossbergstarseeker: ok, now i got it, thanks
14:39.32d_rossbergbtw, enigma can can be build with MSVC using mingwrep's libcrypt
16:05.42*** join/#brlcad Stattrav (~Stattrav@117.202.26.95)
16:05.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:09.12CIA-105BRL-CAD: 03starseeker * r44584 10/brlcad/trunk/src/adrt/ (CMakeLists.txt isst.bat): Add .bat file for isst on Windows.
19:12.41CIA-105BRL-CAD: 03erikgreenwald * r44585 10/brlcad/trunk/src/adrt/ (isst.h isst_tcltk.c): use bu_gettime() instead of gettimeofday
19:46.03CIA-105BRL-CAD: 03starseeker * r44586 10/brlcad/trunk/misc/CMake/test_srcs/time.c.in: whoops - need the zero on the ninth too
19:52.45CIA-105BRL-CAD: 03starseeker * r44587 10/brlcad/trunk/src/other/togl/ (6 files in 2 dirs): See if we can avoid putting headers in the src directory...
19:53.30CIA-105BRL-CAD: 03starseeker * r44588 10/brlcad/trunk/src/adrt/CMakeLists.txt: Ignore the bat file too.
19:55.35CIA-105BRL-CAD: 03erikgreenwald * r44589 10/brlcad/trunk/src/adrt/isst_tcltk.c: move variable declarations to beginning of block. Change trunc() to floor().
20:15.09CIA-105BRL-CAD: 03erikgreenwald * r44590 10/brlcad/trunk/src/adrt/isst_tcltk.c: Should be Issttcltk_Init, not Isst_Init.
20:17.17CIA-105BRL-CAD: 03erikgreenwald * r44591 10/brlcad/trunk/src/adrt/CMakeLists.txt: fix path info for pkgIndex.tcl
20:37.27*** join/#brlcad Stattrav (~Stattrav@117.202.26.95)
20:37.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:37.30CIA-105BRL-CAD: 03erikgreenwald * r44592 10/brlcad/trunk/TODO: add some items for next release
20:47.48*** join/#brlcad Stattrav (~Stattrav@117.202.26.95)
20:47.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:50.57CIA-105BRL-CAD: 03erikgreenwald * r44593 10/brlcad/trunk/src/adrt/librender/ (render.h render_internal.h): define RENDER_EXPORT for dll export/import
21:15.29*** join/#brlcad Stattrav (~Stattrav@117.202.26.95)
21:15.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:40.50*** join/#brlcad crazy_imp (~mj@a89-183-31-199.net-htp.de)
22:15.19*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
IRC log for #brlcad on 20110510

IRC log for #brlcad on 20110510

00:35.34*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
01:11.33*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177871643.dsl.bell.ca)
05:23.34*** join/#brlcad Stattrav (~Stattrav@122.167.76.167)
05:23.35*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:38.54CIA-105BRL-CAD: 03Maria geneva averia 07http://brlcad.org * r2872 10/wiki/How_Does_Car_Insurance_Works_In_The_Community: New page: == Car Insurance Quotes - How Does Car Insurance Works In The Community == There is something about today`s world that seems to give us restlessness? Is it because of the vast social or...
05:48.06CIA-105BRL-CAD: 0368.234.216.134 07http://brlcad.org * r2873 10/wiki/How_Does_Car_Insurance_Works_In_The_Community: Blanking spam page.
07:21.09*** join/#brlcad Stattrav (~Stattrav@122.167.76.167)
07:21.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:02.13*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:31.30*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
11:03.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:14.24CIA-105BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Maria geneva averia]] with an expiry time of infinite (account creation disabled): Spamming links to external sites
11:14.38CIA-105BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[How Does Car Insurance Works In The Community]]": Spam.
12:52.26*** join/#brlcad Stattrav (~Stattrav@117.202.17.194)
12:52.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:08.36CIA-105BRL-CAD: 03starseeker * r44594 10/brlcad/trunk/src/ (3 files in 3 dirs): See if a togl stub library works for Windows.
13:16.45CIA-105BRL-CAD: 03erikgreenwald * r44595 10/brlcad/trunk/NEWS: catch up on some news items
13:26.53CIA-105BRL-CAD: 03erikgreenwald * r44596 10/brlcad/trunk/src/other/togl/src/CMakeLists.txt: TOGL_STUB_LIBRARIES should be marked "advanced" to avoid cmake-gui clutter
13:30.15*** join/#brlcad merzo (~merzo@193.254.217.44)
13:52.48*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ)
14:56.39CIA-105BRL-CAD: 03starseeker * r44597 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: Add some comments to the third party logic.
14:59.29CIA-105BRL-CAD: 03starseeker * r44598 10/brlcad/trunk/CMakeLists.txt: Make the logic to prevent CMake from searching in CMAKE_INSTALL_PREFIX more robust.
17:04.36*** join/#brlcad mafm (~mafm@236.Red-81-39-254.dynamicIP.rima-tde.net)
17:28.17CIA-105BRL-CAD: 03starseeker * r44599 10/brlcad/trunk/TODO: fixed detection issue
18:11.56*** join/#brlcad merzo (~merzo@15-138-94-178.pool.ukrtel.net)
18:25.45CIA-105BRL-CAD: 03starseeker * r44600 10/brlcad/trunk/CMakeLists.txt: Er, oops - turn 64 bit off for 32bit compiler...
19:11.43CIA-105BRL-CAD: 03starseeker * r44601 10/brlcad/trunk/src/adrt/CMakeLists.txt: Still need isst script on WIN32
19:17.15CIA-105BRL-CAD: 03erikgreenwald * r44602 10/brlcad/trunk/src/adrt/CMakeLists.txt: add opengl libraries
19:27.35CIA-105BRL-CAD: 03starseeker * r44603 10/brlcad/trunk/src/adrt/CMakeLists.txt: Restore in-build-tree pkgIndex.tcl setup for isst.
19:28.45CIA-105BRL-CAD: 03starseeker * r44604 10/brlcad/trunk/src/adrt/isst_tcltk.c: Linux needs Isst_Init
19:29.49*** join/#brlcad Stattrav (~Stattrav@117.202.17.194)
19:29.49*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:01.32CIA-105BRL-CAD: 03bob1961 * r44605 10/brlcad/trunk/src/rt/ (do.c main.c opt.c): Fix rt commands use of "-c orientation" subcommand.
20:33.30CIA-105BRL-CAD: 03r_weiss * r44606 10/brlcad/trunk/ (5 files in 2 dirs): Updated nmg boolean functions using the classlist array. Changed the classlist type from 'long' to 'size_t'.
20:36.13CIA-105BRL-CAD: 03starseeker * r44607 10/brlcad/trunk/CMakeLists.txt: Make a stab at broader coverage for the 'searching in install paths' issue - don't know if this fully works as yet.
20:55.29CIA-105BRL-CAD: 03starseeker * r44608 10/brlcad/trunk/CMakeLists.txt:
20:55.30CIA-105BRL-CAD: Go for the SYSTEM paths - they aren't intended to be modified by the project
20:55.30CIA-105BRL-CAD: according to CMake, but until we find another way to avoid searching
20:55.32CIA-105BRL-CAD: CMAKE_INSTALL_PREFIX we seem to have little choice. Need to test this on
20:55.33CIA-105BRL-CAD: Windows to see if it helps there.
20:57.14CIA-105BRL-CAD: 03starseeker * r44609 10/brlcad/trunk/CMakeLists.txt: Fix comment's line number reference
21:40.36*** join/#brlcad crazy_imp (~mj@a89-183-46-218.net-htp.de)
22:06.21CIA-105BRL-CAD: 03starseeker * r44610 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: ffast-math is causing tessellation failures on some platforms.
IRC log for #brlcad on 20110511

IRC log for #brlcad on 20110511

00:17.19*** join/#brlcad dtidrow (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
02:27.52*** join/#brlcad merzo (~merzo@116-46-94-178.pool.ukrtel.net)
02:33.07*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096600985.dsl.bell.ca)
03:13.48*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601166.dsl.bell.ca)
03:45.50CIA-105BRL-CAD: 03Paydayloan251 07http://brlcad.org * r2874 10/wiki/Payday_Loan_-_How_To_Get_The_Best_Payday_Loan: New page: Do net get too hard on yourself on how you can get the best solution to your problem now if you are running out from your expenses because of some emergency cases because the '''[http://ww...
06:44.42CIA-105BRL-CAD: 03Rossberg 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Payday Loan - How To Get The Best Payday Loan]]": Spam
06:48.19CIA-105BRL-CAD: 03Rossberg 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Paydayloan251]] with an expiry time of infinite (account creation disabled, autoblock disabled): Spamming links to external sites
06:56.46*** join/#brlcad merzo (~merzo@193.254.217.44)
07:41.22*** join/#brlcad Stattrav (~Stattrav@122.167.76.167)
07:41.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:54.40*** join/#brlcad waprat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
10:08.17*** join/#brlcad mafm (~mafm@131.Red-83-37-177.dynamicIP.rima-tde.net)
10:21.11*** join/#brlcad mafm_ (~mafm@131.Red-83-37-177.dynamicIP.rima-tde.net)
11:26.30kunigamiI'm studying the osl language and I found a raytracer using it. The problem is that in rendering a glass sphere incorrectly: http://kuniga.files.wordpress.com/2021/04/corrected.png
11:27.36``Erikthose look like chrome balls, not glass
11:29.23``Erikthe scene specification actually lists them as glass, with a refraction coefficient and everything?
11:30.11kunigamiErik: yes, the dark sphere should be a glass one, like the original rendering http://kuniga.files.wordpress.com/2021/04/testrender_closures_fixed_refraction.jpg
11:31.01``Erikhm, it seems to handle reflection ok, but refraction is all wrong
11:31.37kunigamiah ok, nice to know this. I'll look through the code to see if I can identify anything
11:31.39``Erikstill might be worth studying to see how they interfaced *shrug* :)
11:32.10``Erikbbiab, heading to the office
11:34.16kunigamiok!
11:58.49kunigamithe description of the glass shader is here: http://pastebin.com/6dMgch1A
17:02.53*** join/#brlcad Stattrav (~Stattrav@117.192.131.185)
17:02.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:11.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:50.00*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
19:04.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:41.24*** join/#brlcad crazy_imp (~mj@a89-182-7-124.net-htp.de)
22:39.10starseekerhah, cool! http://farside.ph.utexas.edu/euclid.html
IRC log for #brlcad on 20110512

IRC log for #brlcad on 20110512

05:43.40*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
05:54.14*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
06:32.28*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:32.28*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:08.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:59.20*** join/#brlcad mafm_ (~mafm@251.Red-83-49-86.dynamicIP.rima-tde.net)
11:48.31dloman_yawns
12:00.35``Erikyargh
12:55.40*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:07.21``Erikawesome, the euclid book has greek and english side by side O.o
15:24.02dloman_im confused.... does a 'directory struct' point to a single DB object or a set of DB objects?
16:27.37d_rossbergi would say mainly to a single object (d_namep), but there are also members of a concatenated list
16:30.58*** join/#brlcad CIA-58 (cia@cia.atheme.org)
16:51.37*** join/#brlcad Stattrav (~Stattrav@117.192.144.223)
16:51.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:18.33*** join/#brlcad CIA-58 (cia@cia.atheme.org)
18:49.32*** join/#brlcad mafm (~mafm@251.Red-83-49-86.dynamicIP.rima-tde.net)
19:35.32*** join/#brlcad CIA-61 (cia@cia.atheme.org)
20:02.53starseeker``Erik: yeah - apparently the definitive version of Euclid's elements was done in the 1880's in Greek - "out of print" is putting it mildly
20:03.24starseekerI like that two column format - makes a nifty rosetta-stoneish setup for Greek/English
20:04.00starseekertoo bad he didn't include a little more background on the research and sources that went into the original Greek compilation - from what little I know it was quite the project
20:13.36*** join/#brlcad willdye (~willdye@fern.dsndata.com)
20:48.56*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
21:41.13*** join/#brlcad crazy_imp (~mj@a89-183-19-40.net-htp.de)
22:44.25*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20110513

IRC log for #brlcad on 20110513

04:43.16*** join/#brlcad Stattrav (~Stattrav@122.167.76.167)
04:43.16*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:27.51*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
09:00.31*** join/#brlcad mafm (~mafm@144.Red-88-23-76.staticIP.rima-tde.net)
10:10.39dloman_yawns
11:37.42dloman_http://www.youtube.com/watch?v=9BnLbv6QYcA&feature=related
11:37.45dloman_i lol'd
12:55.31*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:57.19dloman_starseeker: you're the primary author of search.c ...right?
13:13.25*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
13:28.27``Erikheh, my mom sent me an email with a classic... http://brlcad.org/~erik/shouldbe.html
13:31.24dloman_nice :)
13:31.53dloman_``Erik: the argc and argv passed to db_walk_tree, are those the 'start' points for the walker?
13:32.23*** join/#brlcad Stattrav (~Stattrav@117.202.23.71)
13:32.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:32.39``Erikyeah, the region/comb names
13:34.11dloman_awesome danke
13:48.37``Erikpeers around
13:52.21dloman_quiet today
13:54.02``Erikbrlcad is parked on his tofu name, so he's not 'here'. :/ have a couple things I need to ask him. Wait, sorry, baltimore, aks him. :D
13:54.53dloman_*snicker*
13:55.07dloman_i hate it when people axe me questions.
15:23.39starseekerdloman_: kinda - I built on top of some find code
15:23.45dloman_kk
15:23.56starseekeris it having trouble?
15:24.05dloman_not it, but me :)
15:37.30starseekerhmm: http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/
15:37.48starseeker"Qt will require OpenGL (ES) 2.0 to work. QWidgets will be layered on top of the scene graph (not the scene graph on top of QWidgets as is currently done with Qt 4)."
15:38.13starseekerwonder if that means Qt-in-OpenGL is going to get simpler?
15:41.12*** join/#brlcad mafm_ (~mafm@144.Red-88-23-76.staticIP.rima-tde.net)
17:46.30CIA-61BRL-CAD: 03davidloman * r44613 10/geomcore/trunk/tests/func/GE/ (CMakeLists.txt GeometryEngineTest.cxx): Work on a small test.
18:23.36*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:54.19*** join/#brlcad Stattrav (~Stattrav@117.192.141.51)
18:54.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:05.27*** join/#brlcad Stattrav_ (~Stattrav@117.192.133.142)
19:10.26*** join/#brlcad Stattrav (~Stattrav@117.192.129.225)
19:10.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:41.01*** join/#brlcad crazy_imp (~mj@a89-182-4-131.net-htp.de)
22:51.21*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593434.dsl.bell.ca)
23:41.42*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593434.dsl.bell.ca)
IRC log for #brlcad on 20110514

IRC log for #brlcad on 20110514

10:03.20*** join/#brlcad Stattrav (~Stattrav@117.192.134.167)
10:03.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
IRC log for #brlcad on 20110515

IRC log for #brlcad on 20110515

04:20.13*** join/#brlcad ibot (~ibot@rikers.org)
04:20.13*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
04:31.26*** join/#brlcad ebrown (~^echa^@110.138.166.185)
05:13.12*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
10:21.51*** join/#brlcad Stattrav (~Stattrav@117.192.158.93)
10:21.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:55.04*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
13:29.02*** join/#brlcad Stattrav (~Stattrav@117.192.158.93)
13:29.02*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:01.51*** join/#brlcad CIA-117 (cia@cia.atheme.org)
21:32.41*** join/#brlcad crazy_imp (~mj@a89-183-57-212.net-htp.de)
IRC log for #brlcad on 20110516

IRC log for #brlcad on 20110516

04:54.53*** join/#brlcad Stattrav (~Stattrav@117.192.128.2)
04:54.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:56.43*** join/#brlcad Stattrav_ (~Stattrav@117.192.128.2)
06:58.41*** join/#brlcad merzo (~merzo@193.254.217.44)
10:18.17CIA-117BRL-CAD: 03Homeloanbroker 07http://brlcad.org * r2882 10/wiki/Home_Loan_Broker_-_How_to_Become_a_Loan_Modification_Broker: New page: If you want to become a '''[http://www.mortgagecomparison.com.au/ home loan broker]''', or specifically a loan modification broker, then you must undergo some training or rather get a real...
11:24.44*** join/#brlcad finbrein (finbrein@CXXVII.voas.sl-laajakaista.fi)
11:26.19*** part/#brlcad finbrein (finbrein@CXXVII.voas.sl-laajakaista.fi)
11:35.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:43.48*** join/#brlcad Stattrav_ (~Stattrav@117.192.143.203)
12:01.02dloman_yawns
12:06.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:39.16*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
13:19.51*** join/#brlcad piksi (piksi@pi-xi.net)
13:34.32*** join/#brlcad merzo (~merzo@193.254.217.44)
15:27.11*** join/#brlcad dli (~dli@66.49.170.199)
15:50.43CIA-117BRL-CAD: 03erikgreenwald * r44614 10/brlcad/trunk/TODO: lights-regress seems to work now. tesselation issue on optimized build was due to -ffast-math, so Cliff removed the flag.
15:55.29*** join/#brlcad Stattrav (~Stattrav@117.192.143.203)
15:55.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:21.28CIA-117BRL-CAD: 03erikgreenwald * r44615 10/rt^3/trunk/cmake/FindBRLCAD.cmake: remove tie
17:33.04CIA-117BRL-CAD: 03starseeker * r44616 10/brlcad/trunk/misc/CMake/FindOPENNURBS.cmake: See if this helps on Windows...
17:41.41CIA-117BRL-CAD: 03erikgreenwald * r44617 10/geomcore/trunk/CMake/FindBRLCAD.cmake: remove tie
18:06.27CIA-117BRL-CAD: 03erikgreenwald * r44618 10/brlcad/trunk/CMakeLists.txt: Don't try the math expression if we don't have a void pointer size (???) (starseeker)
18:08.29CIA-117BRL-CAD: 03erikgreenwald * r44619 10/brlcad/trunk/misc/CMake/ (FindOPENNURBS.cmake FindUTAHRLE.cmake):
18:08.29CIA-117BRL-CAD: Expand on the OpenNURBS and Utah find routines a big - not making much use of
18:08.29CIA-117BRL-CAD: these yet, but the expanded tests happen to fail on Windows for the installed
18:08.29CIA-117BRL-CAD: BRL-CAD, which avoids some configure problems. Still haven't found a good way
18:08.29CIA-117BRL-CAD: yet to forcibly exclude the installed directory from the search on Windows.
18:08.30CIA-117BRL-CAD: (starseeker)
18:11.14*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
18:11.50CIA-117BRL-CAD: 03erikgreenwald * r44620 10/brlcad/trunk/misc/CMake/FindOPENNURBS.cmake: Clean up debug message
20:54.31CIA-117BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
20:54.31CIA-117BRL-CAD: deleted "[[Home Loan Broker - How to Become a Loan Modification Broker]]":
20:54.31CIA-117BRL-CAD: content was: 'If you want to become a '''[http://www.mortgagecomparison.com.au/
20:54.31CIA-117BRL-CAD: home loan broker]''', or specifically a loan modification broker, then you must
20:54.32CIA-117BRL-CAD: unde...' (and the only contributor was
20:54.32CIA-117BRL-CAD: '[[Special:Contributions/Homeloanbroker|Homeloanbroker]]')
20:54.54CIA-117BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
20:54.54CIA-117BRL-CAD: deleted "[[Casino Online - How To Find Craps Rules Online]]": content was: '==
20:54.54CIA-117BRL-CAD: Casino Online - How To Find Craps Rules Online ==Finding and searching the
20:54.54CIA-117BRL-CAD: '''[http://www.casinobonus24.com/ casino online]''' that you are look...' (and
20:54.54CIA-117BRL-CAD: the only contributor was
20:54.54CIA-117BRL-CAD: '[[Special:Contributions/Mariagbuilder1|Mariagbuilder1]]')
20:55.25CIA-117BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Homeloanbroker]] with an expiry time of infinite (account creation disabled): Spamming links to external sites
20:55.46CIA-117BRL-CAD: 03Erik 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Mariagbuilder1]] with an expiry time of infinite (account creation disabled): Spamming links to external sites
21:20.31*** join/#brlcad crazy_imp (~mj@a89-183-12-108.net-htp.de)
21:24.17*** join/#brlcad dli (~dli@66.49.170.199)
22:13.41kunigami_I had to go through older versions of osl and oiio just to discover I was using the wrong glass shader >.<
22:15.17``Erikwell, at lesat ya found it :)
22:17.04kunigami_:) yup
22:17.08``ErikI think the far bigger task is isolation and integration, a first cut might use a fixed 'flat' shader (always return #ff0000), then try phong or normal
22:17.44kunigami_hmm what do you mean by isolation?
22:18.12``Erikfiguring how much of what comes in the source tarball is actually required, removing things like demos and unused code, etc
22:19.11``ErikI've no idea how much came with it, so'z I might not make sense *shrug*
22:20.37kunigami_hmm ok. actually it seems the source is quite small. it is mainly the osl compiler, the shaders interpreter and the shaders tester
22:21.48``Erikhm, cool
22:22.01``Erikstarseeker mentioned something about an insane dependancy list for it
22:23.13kunigami_yes, there is also an important question: the idea is to create a dependence of osl or take a part of their code and start an independent development?
22:23.48kunigami_as far as I remember, brlcad has few explicit dependencies. on the other hand installing osl is not trivial]
22:23.48kunigami_
22:24.47``Erikmy guess is that the osl interface will exist in src/liboptical as a C style shader that interfaces OSL, OSL goes in src/other/osl/ (other deps might go in src/other)
22:28.37kunigami_so, there will be a single C like shader that will call the while osl system right?
22:29.15``Erikthat'd be my guess
23:06.18kunigami_a question regarding the wiki: is there any way to upload images in a personal directory? the last time I uploaded it went to a global scope. My main fear is that it overwrites some existing image...
23:14.58``Erikno, it's not set up to allow that. You can always upload it somewhere like google images or flickr or something and link it in the wiki
23:16.15kunigami_ok! thanks!
IRC log for #brlcad on 20110517

IRC log for #brlcad on 20110517

00:57.20starseeker``Erik: my take would be to focus on getting a working shader - integration into the build logic can come later
00:57.35starseekerfor the moment, we could even assume an installed osl
00:58.27starseekerI'd probably have to cmakeify at least one or two deps - to the best of my knowledge tbb doesn't currently use CMake, for example
01:05.49starseekeridly wonders if imageio could sub for freeimage in ogre...
01:05.54starseekeropenimageio rather
03:47.58``Erikstarseeker: the src/liboptical/sh_osl.c thing is what I meant, integrate it into our raytracing package. Not spend a lot of time writing shaders for it before... src/other with checks for system are after some basic integration
07:03.25*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:23.03*** join/#brlcad Stattrav_ (~Stattrav@111.93.134.142)
10:52.48*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
12:55.19*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
13:42.19*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
14:14.02dloman_bangs head against keyboard..... doesn't wanna write a custom treewalker :(
14:16.04``Erikwhy would you need to? we  have too many already?
14:17.03``Erikcinematics are dandy and all, but after half a dozen times, zomfg, give me a button to skip it, seriously
14:17.26dloman_trying to make a tree walker that does two things:  1) keeps track of full path and 2) creates the appropriate bu_ext
14:17.32dloman_i get 1 easy
14:17.40dloman_but 2 keeps eluding me.
14:18.16dloman_every different tree walker i've tried fails on 'badmagic' cause somehow, the directory* gets 'misaligned' with the db_i*
14:18.24``Erikooh, all the tree walkers are thinking prepped geometry, not disk... you MIGHT be able to create a memory image and do a wdb export into it, then have a magic bu_external
14:18.30``ErikI think that might be what, um
14:18.55``Erikbad magic probably means you're trying to use a bu_external as a .g file, which is not valid
14:19.30``Erikg_transfer.c dude
14:19.36dloman_hrm, dunno how.  just calling bu_get_external() and feeding it a dbip and directory
14:19.38``Erikyour answers are there :D
14:19.49dloman_kk, i've been all over search.c, keep.c paths.c
14:19.53dloman_thanks, i'll check it.
14:20.17``Eriksrc/gtools/g_transfer.c, brlcad mentioned it a while ago
14:20.42dloman_okay, that's half the info i already know.
14:20.55dloman_i can make valid bu_externals by simply looping thru the file.
14:21.07dloman_and i can get a good set of full paths by tree walking.
14:21.32dloman_now, i need to combine the two so I can do both in one pass over the file.
14:21.37dloman_..... that even possible?
14:21.42``Erika bu_external maps immediately to a single line of a .asc file
14:21.58dloman_righto.
14:22.00``Erikmaybe the g2asc program will help you more
14:22.02dloman_well, here's a question
14:22.07``Eriksince it has to do that by definition
14:22.26dloman_is there a way to take a db object name and get its full path?
14:23.29``ErikI'm questioning myself on the notion of what full path means in the BRL-CAD filesystem... I'm kinda thinking that there is no such thing as a path, it's imaginary :D or, rather, reconstituted based on relationships
14:23.48``Erikthe whole "flat namespace" has always bugged me a bit
14:24.26``Erikusing notation to denote a tree when everything sits at the same level and stacks metadata to denote associations... *shudder*
14:24.38dloman_hrm.  time to ponder and test code more.
14:24.42``Erikdenote note note denote note stop. morse dork. :D
14:25.01dloman_backs away slowly.
14:25.15``ErikI'm off today, man, cut me some slack
14:25.33dloman_=D
14:25.38``ErikI'm just saying that viewing it as a real 'path' may be problematic, it might not actually exist that way
14:26.00``Erikit's more like a strange ORM in reality
14:26.02dloman_that's why i'd like to be able to 'walk' the tree and verify the path.
14:26.33dloman_aka, a user specifies they want a list of all child objects of /some/path/to/an/obj.r
14:26.54dloman_where the actual .g file is named 'to'
14:26.57``Erikyeah, and that's why I'm bugged, it has to be hand assembled from the entire soup
14:27.11``Erikmebbe we'll do real pathing in v6
14:27.53``Erikyou'd have to stop at 'to' and pull everything in it to construct the tree, the tree does not explicitely exist in the .g
14:28.02``Erikit's assembled from name relationships at load time
14:28.03dloman_exactly
14:29.39``Erikgonna go swap laundry, the things you should probably be looking at are g2asc, libged tops, maybe pulling a loaded 'internal' tree and doing exports on each bit
14:30.21dloman_thinking about giving up and chalking it to 'premature optimization'
14:30.27dloman_and just doing in two passes
14:30.36dloman_slower, yeah, but hellova lot less frustrating
14:30.43``Erikgood luck O.o :D *think* butler might be able to help, brlcad might, but he's otherwise occupied...
14:30.55dloman_doody duty
14:30.57``Erikfor the muves guys, performance is not a concern
14:30.58dloman_*snicker*
14:31.07dloman_don't really care about them
14:31.10``Erikdropped off their package on saturday, btw
14:31.26dloman_im thinking of mged 2 or 3 performance.
14:31.36``Erikthey're the ones driving funding and deadlines... yeah, we want better, but if under teh gun, just gotta shut them up, right?
14:31.46dloman_yuppers.
14:31.58``Eriksoo mebbe you should KISS
14:32.31``Erikwho knows, maybe the simple slow approach is adequate
14:32.43dloman_yeah, i was just thinking that same thing.
14:32.44dloman_heh
14:35.12``Erik(yeah, you kinda already said it, I was agreeing)
14:35.34dloman_i was focusing on the 'stupid' part, lol
14:35.42dloman_my head hurts cause of this stuff.
14:35.46dloman_i sooooooo can't read C
14:35.47``Erik"keep it stupid, simple?"
14:36.15``Erikheh, different paradigm than you're used to
14:36.27dloman_that's Yodas version?
14:36.52``ErikI thought I was a really good programmer when I went back to college, bitched like crazy when I had to learn new languages and design paradigms...
14:37.15``ErikI think every new language and definitely every new paradigm has made me a much better programmer in all the languages I can use
14:37.58dloman_hehehe, just reading thru www.ihas1337code.com makes me realize just how much i missed by not going to college for CS.
14:38.23``Erikit twists your mind and makes you look at things differently... and then enlightenment :)
14:40.12``Erikthe, uh, monthly 'scrum', one of the points ed wanted to talk about was the future of GS and having you rotate to other stuff, drag you out of isolation and expose you to other stuff
14:40.30dloman_that'd be nice
14:40.48``Erikare you in the office? I know ed is in, he answered his phone a bit confused
14:41.01dloman_yeah, im here.
14:41.36``Erikwell, there ya go :D walk over and mention it, I'd be willing to go on speakerphone since I poked the tiger
14:42.12dloman_well, there's the issue of me being pissed that i can't make this thing work the way i want it to, as easily as it should be to implement.
14:42.29dloman_im stubborn like that, an i really want this to be done.
14:43.37``Erikdude, it's a whole bucketload of very specialized knowledge, the smart thing is to say "hey, this is hard" and get help...
14:43.51dloman_that's why i have you :P
14:44.02``ErikI mean, what'd you say if a coner tried to restart a reactor and refused to stop and say they didn't know what was going on?
14:44.23``Erikgetwhutahmean,verne?
14:44.36dloman_to be fair, things have gotten a whole lot better since i stopped trying to hammer rocks into swords :)
14:45.00dloman_well, in that case, i'd laugh, then leave the boat.  power to him :)
14:45.04dloman_but i know what you mean.
14:45.15``Eriknotes that he is not on the boat at the moment O:-) *duck*
14:46.16``Eriksorry, couldn't resist that one.. Cliff Ed and I talked a bit about the needs, state, possibilities, etc of GS and ed felt that you and brlcad needed some insight, but it was time to stop and see what was what
14:46.36dloman_right on
14:47.00dloman_i'd like to get it to a point where i can say:  Here, its working.  Barely, but its working to reqs.
14:47.16``ErikI think cliff and i did a big info dump that he grokked, but a little more data was needed for a good decision
14:47.38``Erikit might be that the lithp version is close enough to their requirements that we can say "good 'nuff till next fy"
14:48.06dloman_that's my fallback, so thanks for that :)
14:48.24``Erikis cliff in? be social, man, our downfall is lack of communication
14:48.42dloman_oh, we've talked a lot the last few weeks :)
14:48.59dloman_ive tripled my understanding of the brlcad libs in a short time.
14:49.26dloman_add in the fact that i am finally confident enough  to say "No, using that lib is stupid"
14:49.27``Eriktalking and communication are not necessarily parallel, and ed feels in the dark a lot of the time
14:50.22``Erikhe's a good guy to talk to, I'd strongly recommend heading over, sitting down and chattering a bit
14:50.36dloman_will do
14:50.59``Erikand like I said, I'm off today, but if you feel the need to call up and throw me on speakerphone *shrug* I'm here
14:52.45dloman_will do, thanks.
15:03.46kunigami_does the blue ball seem to be using a phong shader? http://imageshack.us/photo/my-images/101/phong3.png/
15:07.41kunigami_in this other image is used the microfacet-beckmann shader, http://imageshack.us/photo/my-images/40/imager03.png/ but the specular highlighting is blue instead of white
15:08.02``Erikkunigami_: yes, phone, but not radiosity or photon mapping, which the rest of the scene seems to be using... the granulatiry makes it look like a combination, almost
15:08.06``Erikphong, even
15:09.41``Eriklooks like the difference is a specular saturation issue, and the latter kinda looks wrong on reflection issues
15:15.35kunigami_but shouldn't the phong shader ball look like a snooker ball?
15:15.52``Erikon pure phong, it'll be very smooth with maybe banding
15:16.32``Erikif it's a photon map or radiosity type thing before, then the normal will be randomly permutated and you'll get the grainyness
15:17.46``Erikit could also be that a material property is effecting the normal
15:23.46kunigami_hmm ok! thanks
15:24.53``Erikeither way, I'd imagine it's a minor issued compared to the src/liboptical/sh_osl.c work... *shrug* just my opinion, you may want to email Daniel Rossberg about it to see his thoughts :)
15:25.08``Erikhe's the one listed as your mentor, right?
15:29.22kunigami_yup, it's him. ok, I'll send an email to him.
15:30.01kunigami_I think I already completed what I was expected to do on the bounding time (according to my final proposal)
15:30.35kunigami_thus, I was trying to do make more complex things before proceeding.
15:31.14kunigami_anyway, my next task was to understand brlcad shading system
15:37.24``Erikif it helps, sh_toon.c is something I just recently started, it's a very trivial example
15:37.59kanzurebeep boop
15:38.16kanzurei'm still working on my rewrite of esolid
15:38.23kanzureit's a lot of code
15:38.28kanzurethere are no unit tests
15:38.46kanzureand there's maybe another 5k lines to write before it might be working
15:38.47kanzurewhat should i do?
15:43.54``Erikesolid? I'm not aware of that, can you quickly summarize?
15:48.48``Eriksorry, gotta run, I'll be on later
15:49.19kanzurenurbs-based boolean operations
15:49.35kanzure(well, trimmed bezier patches)
16:20.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:09.15CIA-117BRL-CAD: 03davidloman * r44621 10/geomcore/trunk/ (7 files in 2 dirs): Clean up the IDataSource interface a tad.
17:17.48*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
17:25.11*** join/#brlcad Stattrav (~Stattrav@117.192.132.43)
17:25.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:46.32CIA-117BRL-CAD: 03davidloman * r44622 10/geomcore/trunk/src/GS/FileDataSource.cxx: Start work on getListing()
18:00.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:10.30starseekerah, bugger - http://dev.crypt.co.za/coffee/wiki?name=Project+Status
18:10.35starseekerhow'd I miss THAT?
18:21.00starseekerkanzure: did you get a license OK from the original devs?
18:34.59starseekerhmm... apparently tcl/tk switched to fossil??
18:42.39starseekerah, right - after that CVS business on SF
18:49.55kanzurestarseeker: no didn't get a response from him
18:53.40kanzurewhy would i be rewriting if i had a permissive license to use the original code?
19:41.56CIA-117BRL-CAD: 03starseeker * r44623 10/brlcad/trunk/src/other/togl/ (CMakeLists.txt src/CMakeLists.txt): Use LIB_DIR variable for install, so Windows gets things where it expects them.
19:42.10starseekerkanzure: oh, you're re-writing from SCRATCH?
19:42.17starseekerthought you were re-factoring
19:42.52kanzureheh
19:43.00kanzureyeah... i'm doing something dumb
19:43.07kanzureit's taking me forever and i can't really judge my progress along the way
19:43.27kanzurei mean, i sort of am able to - like i have two boxes that are generated and i'm somewhere in the middle of the intersection code
19:43.39kanzurebut i don't really know if all of my implementation works the same or not
19:46.42starseekerkanzure: if esolid had test cases, you should at least be able to feed those to your code to see if the results are the same
19:46.54kanzureit has no test cases
19:46.59starseekerwinces
19:47.10starseekerare you building off of the opennurbs libraries?
19:47.10kanzureit's roughly 20,000 lines of code
19:47.11kanzurewith no tests
19:47.38kanzureno i'm just doing a vanilla implementation/port first using esolid's code base
19:47.45kanzureand then i'll rip out all of the custom crap
19:47.55kanzureand replace it with opennurbs/opengl/scipy/numpy/clapack
19:48.17starseekerum... be careful about that - if you're building off of esolid's code base that might be seen as a "derivative work"
19:48.33kanzureyes i've examined the legal implications thoroughly
19:48.38kanzuredon't worry
19:48.45starseekernods.
19:49.26starseekermight be worth trying to call him if email didn't work - once in a while a phone call will get through where email won't
19:49.43kanzuresure
19:49.52kanzurebut honestly, if it doesn't have unit tests, it's not worth that much
19:49.57kanzuresomeone will have to do what i'm doing eventually anyway
19:50.05starseekertrue
19:51.42starseekerq
19:51.45starseekerwhoops
20:06.14kanzureso now i don't know what to do
20:06.25kanzurehttp://diyhpl.us/cgit/lolcad/plain/esolid/esolid.py
20:07.52kanzurewrite unit tests for the original code base, then re-write them for my own?
20:08.10kanzurekeep trucking and weep at the end as i slowly/painfully try to figure out why results are different?
20:08.40starseekerkanzure: how different would unit tests be between your code and the original?
20:08.51kanzurewell it's just 2x the amount of code
20:09.07kanzurebut other than that the initial upfront figuring out "wtf" is a one-time cost
20:09.53starseekerkanzure: might be worth verifying the original behavior
20:11.19kanzuretrue.. i should really do it
20:11.28kanzureHOW do these people write this code without testing?
20:12.21starseekermay have figured the tests were too messy to release
20:15.40CIA-117BRL-CAD: 03starseeker * r44624 10/brlcad/trunk/src/other/togl/CMakeLists.txt: whoops, typo.
21:20.47*** join/#brlcad crazy_imp (~mj@a89-183-22-49.net-htp.de)
21:43.33*** join/#brlcad Ralith (~ralith@d142-058-174-188.wireless.sfu.ca)
22:47.46*** join/#brlcad Ralith (~ralith@d142-058-174-188.wireless.sfu.ca)
IRC log for #brlcad on 20110518

IRC log for #brlcad on 20110518

01:47.26*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
02:01.25*** join/#brlcad PrezKennedy (MK@whitecalf.net)
06:29.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:07.37*** join/#brlcad merzo (~merzo@193.254.217.44)
07:27.21*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
08:24.51CIA-117BRL-CAD: 03122.3.171.14 07http://brlcad.org * r2883 10/wiki/Forex_Trading-_How_To_Understand_FOREX_Market_Sentiment: New page: Did you know that currencies is the most widely trade all aver the world'? This is the reason why the '''[http://www.forexinsider.co.uk/ forex trading]''' market would open 24/7. However, ...
08:55.01*** join/#brlcad Stattrav (~Stattrav@122.178.253.199)
08:55.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:20.04*** join/#brlcad Stattrav (~Stattrav@122.178.253.199)
09:20.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:36.41*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:41.50CIA-117BRL-CAD: 03indianlarry * r44625 10/brlcad/trunk/src/conv/step/PullbackCurve.cpp: Fixed array overrun in cubic interpolation routine
14:22.50*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
14:35.46CIA-117BRL-CAD: 03starseeker * r44626 10/brlcad/trunk/src/other/togl/ (CMakeLists.txt include/CMakeLists.txt src/CMakeLists.txt): Install glew.h, break out header and src logic.
14:37.43CIA-117BRL-CAD: 03starseeker * r44627 10/brlcad/trunk/TODO: *hopefully* we've now squashed all the red bugs.
15:03.57*** join/#brlcad dli (~dli@66.49.170.199)
15:26.05CIA-117BRL-CAD: 03starseeker * r44628 10/brlcad/trunk/NEWS: Refine the NEWS file items.
15:39.14*** join/#brlcad crazy_imp (~mj@a89-183-22-49.net-htp.de)
15:46.49*** join/#brlcad silvap (~silvap@static-96-255-52-7.washdc.fios.verizon.net)
15:47.56silvapany of you have individually have >10000 commits to brlcad?
15:48.03silvap-have
16:00.52``Erik10364  mike
16:00.53``Erik9406  brlcad
16:00.53``Erik3241  jra
16:37.02*** join/#brlcad Stattrav (~Stattrav@117.192.135.248)
16:37.03*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:58.49CIA-117BRL-CAD: 03indianlarry * r44629 10/brlcad/trunk/src/conv/step/ (EdgeCurve.cpp OpenNurbsInterfaces.cpp):
16:58.50CIA-117BRL-CAD: Generalized curve generation for the ellipse and circle entity loadBrep code;
16:58.50CIA-117BRL-CAD: also added curve reverse and start/stop point swap for entity 'edge_curve' based
16:58.50CIA-117BRL-CAD: on 'same_sense' boolean variable. This basically fixed some issues with ellipse
16:58.50CIA-117BRL-CAD: and circle conics.
18:38.31*** join/#brlcad Stattrav_ (~Stattrav@117.192.137.219)
19:23.58*** join/#brlcad Stattrav (~Stattrav@117.192.137.219)
19:23.58*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:29.19*** join/#brlcad Stattrav (~Stattrav@117.192.137.219)
19:29.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:37.16CIA-117BRL-CAD: 03bob1961 * r44630 10/brlcad/trunk/ (4 files in 3 dirs): Colors were not getting imported for combinations. Standardized attributes on import before calling object specific import func. Moved ATTR enum definitions from db5_types.c to raytrace.h
20:01.32CIA-117BRL-CAD: 03starseeker * r44631 10/brlcad/trunk/NEWS: Tweak NEWS
20:28.33*** join/#brlcad Stattrav (~Stattrav@117.192.137.219)
20:28.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:33.55*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
21:05.23*** join/#brlcad Ralith (~ralith@d142-058-174-188.wireless.sfu.ca)
21:21.24*** join/#brlcad crazy_imp (~mj@a89-183-69-41.net-htp.de)
21:23.27alex_jonihmm.. I can't recall to who I talked in here about http://juve.ro/blog-files/projects/01298803577/version4_x_final.PNG
21:23.44alex_jonianyways, here's an update: http://juve.ro/blog-files/projects/01298803577/version4_xxb_01.JPG
21:23.53alex_jonifrom: http://juve.ro/blog/projects/01298803577
21:31.26starseekeralex_joni: awesome!
21:32.40starseekerreally cool that you got it built
21:50.17alex_jonistarseeker: thanks, hopefully it'll work too
21:51.30starseekerwill you be trying it out soon?
21:54.57alex_joniyeah, hopefully these days
21:55.23alex_joniif not, surely over the weekend
22:13.19CIA-117BRL-CAD: 03starseeker * r44632 10/brlcad/trunk/TODO: Sigh - solids regression is having a problem. Not sure when this started up.
23:45.13dlialex_joni, I initially thought the image were from brl-cad :(
23:47.05*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
IRC log for #brlcad on 20110519

IRC log for #brlcad on 20110519

00:23.58*** join/#brlcad crazy_imp (~mj@a89-182-12-128.net-htp.de)
01:09.37starseekererrr.... huh?  regression passes on gentoo
01:17.16CIA-117BRL-CAD: 0367.180.102.232 07http://brlcad.org * r2884 10/wiki/Documentation:
04:13.48*** join/#brlcad ThePing (~phycho@174.127.64.107)
04:13.48*** part/#brlcad ThePing (~phycho@174.127.64.107)
06:33.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:05.11*** join/#brlcad merzo (~merzo@193.254.217.44)
10:05.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:44.15*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
11:51.12*** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br)
12:25.16*** join/#brlcad crazy_imp (~mj@a89-182-12-128.net-htp.de)
12:54.11*** join/#brlcad crazy_imp (~mj@a89-182-12-128.net-htp.de)
15:45.42CIA-117BRL-CAD: 03r_weiss * r44633 10/brlcad/trunk/ (5 files in 2 dirs): Updated nmg boolean functions using the classlist array. Changed the classlist type from 'size_t' to 'short'.
17:37.43CIA-117BRL-CAD: 03erikgreenwald * r44634 10/isst/trunk/ (14 files in 5 dirs): ISST repo is now in GIT. "git clone git://brlcad.git.sourceforge.net/gitroot/brlcad/isst.git" to get it.
17:38.03dlomanooooh git :)
17:41.33*** join/#brlcad mafm (~mafm@127.Red-88-18-69.staticIP.rima-tde.net)
18:07.24*** join/#brlcad Stattrav (~Stattrav@117.192.151.218)
18:07.25*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:49.42*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
18:58.47``Eriksurrounded by gits, might as well use git, right? ;>
19:11.46CIA-117BRL-CAD: 03davidloman * r44635 10/geomcore/trunk/ (4 files in 3 dirs): Implement a path stepper that can step thru FS directories and .g files with the same path. Needs cleanup and generalizing, but it works.
19:23.36CIA-117BRL-CAD: 03erikgreenwald * r44636 10/brlcad/trunk/src/adrt/isst_tcltk.c: export init functions for msvc
19:48.20starseekeris slightly confused by the "struct bu_mro" in struct region - is there any reason we don't just point to the bu_avs from the comb?
19:48.30starseeker(for attr_values)
19:57.43*** join/#brlcad Stattrav (~Stattrav@117.192.151.218)
19:57.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:09.13*** join/#brlcad Stattrav (~Stattrav@117.192.151.218)
20:09.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:33.01*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
21:36.17*** join/#brlcad merzo (~merzo@57-12-94-178.pool.ukrtel.net)
22:07.26CIA-117BRL-CAD: 03r_weiss * r44637 10/brlcad/trunk/ (5 files in 2 dirs): Updated nmg boolean functions using the classlist array. Changed the classlist from 'short' to 'char'.
22:18.35*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
22:18.35*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
22:19.32*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
22:19.32*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
22:19.57CIA-117BRL-CAD: 03starseeker * r44638 10/brlcad/trunk/CMakeLists.txt: Maybe someday this will work, or I'll figure out why I'm doing it wrong - CMAKE_SYSTEM_IGNORE_PATH should be ideal for excluding the install dir from Find results, but it doesn't seem to.
22:50.46starseeker``Erik: looks like we can use bu_avs_merge to duplicate an avs - just init a new one and then merge the old one into the new
23:53.16*** join/#brlcad mafm (~mafm@180.Red-88-18-69.staticIP.rima-tde.net)
IRC log for #brlcad on 20110520

IRC log for #brlcad on 20110520

00:15.29*** join/#brlcad merzo (~merzo@4-36-94-178.pool.ukrtel.net)
00:23.02*** join/#brlcad crazy_imp (~mj@a89-183-11-209.net-htp.de)
00:44.54CIA-117BRL-CAD: 03starseeker * r44639 10/brlcad/trunk/ (11 files in 6 dirs): Take a stab at switching from bu_mro (??) to bu_attribute_value_set - this will need a lot more testing (certainly of nirt and raytracing) to make sure nothing got busted.
01:21.12*** join/#brlcad silvap_ (~silvap@static-96-255-52-7.washdc.fios.verizon.net)
01:36.49*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
02:45.05*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
03:19.55``Erikdamnit, starseeker, I had 99% of it done... and the bu_avs_merge is NOT a map for what that function does
03:20.59``Eriknirt has a particularly tricky usage that is not a trivial conversion, that's what I left off for tomorrow morning
03:21.47``Erikthinks avs may need to be altered to accomodate the nirt usage
03:25.37``Erik(I'd originally recoded using merge, then realized it was wrong, that's what slowed me down and kept me from committing before I left)
05:16.21*** join/#brlcad waprat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
05:27.09*** join/#brlcad silvap (~silvap@static-96-255-52-7.washdc.fios.verizon.net)
06:34.51*** join/#brlcad Stattrav (~Stattrav@122.167.103.118)
06:34.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:02.44*** join/#brlcad merzo (~merzo@193.254.217.44)
07:50.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:22.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:52.09*** join/#brlcad mafm (~mafm@190.Red-88-23-77.staticIP.rima-tde.net)
10:17.56*** join/#brlcad mafm_ (~mafm@190.Red-88-23-77.staticIP.rima-tde.net)
10:22.31*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:41.11*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
10:51.24CIA-117BRL-CAD: 03erikgreenwald * r44640 10/brlcad/trunk/src/libbu/Makefile.am: reflect mro.c removal
10:59.38starseeker``Erik: ah, my bad
10:59.47starseekerfeel free to revert mine
11:01.00starseekerhad the mistaken impression you were going to go ahead and commit your intermediate state, so I thought perhaps you hadn't had time to fool with it...
11:02.13``Erikhm, I'd a half broken nirt
11:02.27``Erikrt_load_attrs() is not used by our code, so the difference in functionality may be irrelevant
11:02.44``Erikit was added in '01 by jra, same time as the mro stuff
11:02.56``Erikthe changes, other than that, were almost identical to mine
11:03.41``Erikgrepping the fickle user code now
11:03.42*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
11:03.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:04.08starseeker<snort> - maybe the "user code" is where rt_load_attrs and similar specialized functions should be living
11:04.42``Eriknot used in that code
11:05.02starseekeruh... then what the *bleep* is it doing in there?
11:07.02*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
11:07.53CIA-117BRL-CAD: 03erikgreenwald * r44641 10/brlcad/trunk/ (doc/deprecation.txt include/raytrace.h): mark rt_load_attrs deprecated
11:10.13CIA-117BRL-CAD: 03erikgreenwald * r44642 10/brlcad/trunk/src/nirt/if.c: remove unused variable
11:13.19``Erikruns bench and regress
11:15.46``Erikoptimized on x86_64 osX.6 fails in metaball.c using cmake, the 'const point_t *' issue
11:31.44``Erik32b fbsd's solids regress has 0 off
11:32.04``ErikI think the mged-regress on my mac is due to the system tcl and ogl, running a build-all
11:40.41*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
12:04.02CIA-117BRL-CAD: 03erikgreenwald * r44643 10/brlcad/trunk/src/tab/Makefile.am: disable strict flags, some lexers mix signed/unsigned.
12:17.19``Erikerm? 32b fbsd in Release has 3 off by many in solids
12:24.42*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
12:24.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:40.48*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:50.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:13.08CIA-117BRL-CAD: 03bob1961 * r44644 10/brlcad/trunk/src/libdm/dm-ogl.c: Minor mod.
13:19.04CIA-117BRL-CAD: 03bob1961 * r44645 10/brlcad/trunk/src/libdm/dm-wgl.c: Copy points/vectors to an array of GLdouble before sending to OpenGL. This seems to have remedied a bit of strange behavior seen only on windows (i.e. data arrows were sometimes being drawn incorrectly).
13:48.27``Erik7.18.4 has the same solids regression failure
13:57.28starseekerhmm.  Check 7.16.8?
14:03.53*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
14:52.41*** join/#brlcad Stattrav (~Stattrav@117.192.130.145)
14:52.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:19.38CIA-117BRL-CAD: 03erikgreenwald * r44646 10/brlcad/trunk/TODO: solids regression fails on optimized builds and goes back quite a ways (further than 7.16.8). Bump it to unscheduled and add notes.
16:28.47*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:31.21CIA-117BRL-CAD: 03starseeker * r44647 10/brlcad/trunk/src/libged/attr.c: attr get and show should work in read-only databases - it's only when we actually try to change something that we need to care about read-only.
17:37.30CIA-117BRL-CAD: 03starseeker * r44648 10/brlcad/trunk/src/librt/tree.c:
17:37.30CIA-117BRL-CAD: Hrm. Don't want to do a straight-up copy if the tree avs - that's got NULLs,
17:37.30CIA-117BRL-CAD: not actual values. Probably need to pull in the attributes from elsewhere, but
17:37.30CIA-117BRL-CAD: this isn't quite right - it's looking at primitives and the attributes in
17:37.30CIA-117BRL-CAD: question appear to be higher in the path.
17:38.00*** join/#brlcad Stattrav_ (~Stattrav@117.192.138.105)
18:12.49*** join/#brlcad Stattrav (~Stattrav@117.192.138.105)
18:12.49*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:21.11*** join/#brlcad Stattrav (~Stattrav@117.192.138.105)
18:21.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:31.59CIA-117BRL-CAD: 03starseeker * r44649 10/brlcad/trunk/src/librt/tree.c: Well... grab the attributes from the first region in the path and use them... does this get us what we need?
18:39.26*** part/#brlcad willdye (~willdye@fern.dsndata.com)
18:52.12CIA-117BRL-CAD: 03starseeker * r44650 10/brlcad/trunk/src/librt/ (db_tree.c tree.c): Try to make sure the comb data structure reflects the attributes.
18:58.30*** join/#brlcad willdye (~willdye@fern.dsndata.com)
19:30.05*** part/#brlcad willdye (~willdye@fern.dsndata.com)
21:36.52``Erikstarseeker: that model is borked, the region has an attribute "region=0". I changed it to 1 and everything magically worked
22:25.16starseeker``Erik: O.o
22:25.34starseekersoo.... none of my changes are needed then?
23:08.05*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
23:42.36*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
IRC log for #brlcad on 20110521

IRC log for #brlcad on 20110521

00:23.14*** join/#brlcad crazy_imp (~mj@a89-182-17-206.net-htp.de)
07:38.05*** join/#brlcad Stattrav (~Stattrav@122.178.234.245)
07:38.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:11.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:53.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:30.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:50.02*** join/#brlcad Stattrav_ (~Stattrav@117.192.147.51)
16:13.19*** join/#brlcad pawleeq_ (~pawleeq@212-96-188-229.cust.selfnet.cz)
16:13.31pawleeq_hello
20:05.10*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
20:10.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:02.57*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
IRC log for #brlcad on 20110522

IRC log for #brlcad on 20110522

00:23.21*** join/#brlcad crazy_imp (~mj@a89-183-40-23.net-htp.de)
01:41.55*** join/#brlcad WhiteCalf (MK@whitecalf.net)
06:07.56*** join/#brlcad Stattrav (~Stattrav@117.202.23.83)
06:07.57*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:35.38*** join/#brlcad Stattrav (~Stattrav@117.192.151.65)
07:35.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:38.46*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
14:54.00*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:18.36CIA-117BRL-CAD: 03Casinopaysafecard 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:Casino Paysafecard - How To PlayStealing Bundles Casino24.pdf]]"
21:53.37starseekerhmm:  http://wiki.cs.purdue.edu/cgvlab/doku.php?id=projects:spatial_geometric_constraints
21:55.02starseekerhttp://www.cs.purdue.edu/homes/cmh/electrobook/intro.html
21:58.18starseekerah, nuts - GPL http://www.cise.ufl.edu/research/constraints/GNU/FRONTIER-gnu/
22:07.04starseekermakes a note to grab papers from here: http://www.cise.ufl.edu/~sitharam/pub.html
IRC log for #brlcad on 20110523

IRC log for #brlcad on 20110523

00:23.32*** join/#brlcad crazy_imp (~mj@a89-183-26-57.net-htp.de)
06:14.47*** join/#brlcad merzo (~merzo@193.254.217.44)
06:30.41*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
06:30.48*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
11:10.11dlomanyawns
11:10.27*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:14.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:28.09*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
11:28.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:01.54kunigamihi, does anyone know a good reference on different shaders? or should I go for papers?
12:13.03*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
12:13.03*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:40.04``Erikwhat kind of shaders?
12:57.13CIA-117BRL-CAD: 03davidloman * r44651 10/geomcore/trunk/ (2 files in 2 dirs): Cleaned up console/debug printing calls.
13:15.49kunigamibrlcad suggested me to implement a polka dot shader, but I'm not sure on how to do it. I was wondering if is there any kind of 'handbook of shaders' :)
13:21.48CIA-117BRL-CAD: 03davidloman * r44652 10/geomcore/trunk/ (120 files in 35 dirs): More cleanup. Removed double newlines and dangling tabs/spaces.
13:51.29``Eriknah, not really a handbook... src/liboptical/ is where they sit, all those sh_*.c files
13:51.48``Eriksh_xxx.c is an empty 'skeletal' shader with lots of docs
13:58.54kunigami``Erik: I was actually looking for the algorithm for implementing these shaders.
14:12.30*** join/#brlcad PrezKennedy (MK@whitecalf.net)
14:31.27*** join/#brlcad Stattrav (~Stattrav@122.167.226.157)
14:31.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:44.28*** join/#brlcad Stattrav (~Stattrav@117.192.159.208)
15:44.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:54.41*** join/#brlcad willdye (~willdye@198.183.6.23)
15:54.58*** part/#brlcad willdye (~willdye@198.183.6.23)
16:03.36*** join/#brlcad willdye (~willdye@fern.dsndata.com)
17:02.51*** join/#brlcad willdye (~willdye@198.183.6.23)
17:04.28*** part/#brlcad willdye (~willdye@198.183.6.23)
17:31.23*** join/#brlcad Stattrav (~Stattrav@117.192.159.208)
17:31.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:43.13*** join/#brlcad willdye (~willdye@fern.dsndata.com)
17:43.51*** part/#brlcad willdye (~willdye@fern.dsndata.com)
19:52.46CIA-117BRL-CAD: 03starseeker * r44653 10/brlcad/trunk/src/librt/tree.c: OK, .g file with bad attributes was causing problems - revert silly hunt for region in path.
21:02.55*** join/#brlcad PrezKennedy (MK@whitecalf.net)
21:37.18*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
23:58.20CIA-117BRL-CAD: 03Kunigami 07http://brlcad.org * r2886 10/wiki/User:Kunigami/GSoc2011/Proposal:
IRC log for #brlcad on 20110524

IRC log for #brlcad on 20110524

00:23.41*** join/#brlcad crazy_imp (~mj@a89-182-239-11.net-htp.de)
01:11.53CIA-117BRL-CAD: 03davidloman * r44654 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/connector/: Slight reorg. Will ultimately separate out the classes that comprise the Java GSConnector and the Java GS Test Client
01:14.05CIA-117BRL-CAD: 03davidloman * r44655 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Change default returns to Exception throws for now.
06:31.24*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
06:33.40*** join/#brlcad merzo (~merzo@193.254.217.44)
06:37.22*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:32.54*** join/#brlcad Stattrav (~Stattrav@122.167.103.233)
07:32.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:15.15*** join/#brlcad WhiteCalf (MK@whitecalf.net)
09:16.24*** join/#brlcad PrezWhiteCalf (MK@whitecalf.net)
10:01.21*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
13:04.14dlomanquestion: If i want a listing of a regions 'children' in the form of a list of strings, whats the best way?
13:25.13``Erikin c/c++? shell? tcl?
13:26.56dlomanc
13:28.06dlomanim currently reading db_comb.c and the db_tree_flatten_describe() func
13:29.14``Eriksrc/libged/ls.c might be worth perusing, as well
13:29.31dlomanyeah, thats where i started =D
13:29.42dlomanthat and libged/list.c
13:32.06``Erikdb_lookup() (librt/db_lookup.c) seems pertinent
14:07.19*** join/#brlcad PrezKennedy (MK@whitecalf.net)
14:43.19CIA-117BRL-CAD: 03starseeker * r44656 10/brlcad/trunk/src/ (fb/CMakeLists.txt util/CMakeLists.txt): Add LINKER_LANGUAGE specifications for fbthreadtest and pldebug (from Guilherme Kunigami)
15:43.58CIA-117BRL-CAD: 03r_weiss * r44657 10/brlcad/trunk/src/librt/primitives/nmg/nmg_pt_fu.c:
15:43.58CIA-117BRL-CAD: Updated functions 'compute_loop_class' and 'make_near_list' within file
15:43.58CIA-117BRL-CAD: 'nmg_pt_fu.c'. Passed bn_tol into function 'make_near_list' to be used in a
15:43.58CIA-117BRL-CAD: compare. This change reduces the number of 'dangling face' errors during nmg
15:43.58CIA-117BRL-CAD: boolean operations such as when running the mged 'facetize' command.
16:04.57*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
16:31.20*** join/#brlcad dli (~dli@67.55.12.157)
16:58.13dloman``Erik: you ever implement the 'GEOMETRYLISTREQ' net msg?
17:01.23CIA-117BRL-CAD: 03davidloman * r44658 10/geomcore/trunk/ (3 files in 2 dirs): Implement a getListing() function that obscures the transition from FS to G from the caller.
17:02.05``Erika1no
17:02.11dlomanaight
17:22.18CIA-117BRL-CAD: 03davidloman * r44659 10/geomcore/trunk/ (6 files in 3 dirs): Add directory listing request and response to the gsnet protocol.
17:23.13CIA-117BRL-CAD: 03davidloman * r44660 10/geomcore/trunk/tests/func/GE/GeometryEngineTest.cxx: Check in changes to sandbox test file. Nothing to see here.
17:37.02CIA-117BRL-CAD: 03davidloman * r44661 10/geomcore/trunk/include/DirListResMsg.h: Fix the header define. Changed a Q to an S.
17:38.18CIA-117BRL-CAD: 03davidloman * r44662 10/geomcore/trunk/ (3 files in 2 dirs): Make GeometryService objects able to respond to directory requests. Ensure NetMsgRouter registration for DirListReq and DirListRes msgs.
17:39.26CIA-117BRL-CAD: 03davidloman * r44663 10/geomcore/trunk/src/GS/GSClient.cxx: Formatting. Tabs/indent/newlines.
17:55.14CIA-117BRL-CAD: 03davidloman * r44664 10/geomcore/trunk/ (3 files in 3 dirs): The directory list response needs to carry the requested path back to the caller.
18:00.37CIA-117BRL-CAD: 03davidloman * r44665 10/geomcore/trunk/ (3 files in 3 dirs): Implement a ListCmd for the test client.
18:05.21CIA-117BRL-CAD: 03davidloman * r44666 10/geomcore/trunk/src/libNet/NetMsgFactory.cxx: Make the NetMsgFactory aware of DirListReQ and DirListReS
18:33.55CIA-117BRL-CAD: 03davidloman * r44667 10/geomcore/trunk/src/libNet/netMsg/DirListResMsg.cxx: Fix msg type in constructor. ooops.
18:35.10CIA-117BRL-CAD: 03davidloman * r44668 10/geomcore/trunk/src/libNet/netMsg/DirListResMsg.cxx: Remove debug terminal printing.
18:36.23CIA-117BRL-CAD: 03davidloman * r44669 10/geomcore/trunk/src/GS/FileDataSource.cxx: SHould be feeding getFsDirList() the filesystem path, not the entire path.
19:04.11kunigamihi, I'm trying to implement a 'polka dot' shader. I've based myself on a renderman shader. The results are kinda weird: for a sphere: http://yfrog.com/5mpolkafailp ; cilinder seen from top: http://yfrog.com/njcilinderp ; goblet: http://yfrog.com/mxgobletp
19:07.08starseekerkunigami: that's with OSL?  
19:07.37kunigamistarseeker: no, I've implemented with BL-CAD
19:08.09starseekerah, very good
19:08.43starseekeroffhand, it looks like the dot spacing is running over some "edge"
19:09.21starseekerI confess I don't know much about the shader system - ``Erik, how does the mapping work for something like that?
19:10.28``Erikum, kinda depends for different primitives, I think it's [0,1] xy, but certain shapes sometimes do funny things.. try checkerboard on a sphere to see some weirdness
19:10.54``Erikor a cylinder, for that matter
19:17.56starseekerkunigami: quirks or not, it looks like you've got the idea pretty well - that's a shaded BRL-CAD raytrace
19:18.24starseekernow the next question - how to shade BRL-CAD results using OSL
19:21.22starseekerkunigami: iirc, you got a simple test raytracer working with OSL shading?
19:21.44starseeker(not with BRL-CAD geometry, obviously...)
19:22.03kunigamistarseeker: yes! Some guy did that working for spheres based on smallpt
19:22.37``Erikso now it's time to link the two together?
19:23.36kunigamicool! Well, my idea is to make OSL system do all the calculation and then return a 3-d float array. Is it better to do it through a special BRL-CAD shader acting as an interface or a independent tool?
19:24.01starseekerkunigami: I'd say probably as a special BRL-CAD shader, for the moment
19:24.20``ErikI'd think the shading interface, like src/liboptical/sh_osl.c having osl_render() which calls into OSL, then packs the pixel with the results
19:25.41CIA-117BRL-CAD: 03davidloman * r44670 10/geomcore/trunk/src/GS/cmds/ListCmd.cxx: Add some string filtering loops to pull out extraneous ./ ../ and // sequences.
19:26.42kunigamihmm ok!
19:26.57CIA-117BRL-CAD: 03davidloman * r44671 10/geomcore/trunk/src/GS/FileDataSource.cxx: Use 'top' flag when listing the 'top' of a .g file. Also use db_close and free where appropriate to release resources.
19:29.46CIA-117BRL-CAD: 03davidloman * r44672 10/geomcore/trunk/src/GS/DataManager.cxx: Make DataManager respond to Directory Listing request. Also check for error return values and send FailureMsgs when appropriate.
19:32.13CIA-117BRL-CAD: 03davidloman * r44673 10/geomcore/trunk/src/GS/ (GSClient.cxx GSCmdLineClient.cxx): Add in handling of DirectoryList request and response messages into the test client.
19:36.12kunigamiosl source code would have to be added on /src/other, right?
19:36.45starseekerkunigami: eventually, but don't worry about that for now
19:37.02starseekerthat's quite a job, and not of immediate interest
19:37.12starseekerjust go ahead and use your install of osl
19:39.10kunigamiok, great!
20:01.12CIA-117BRL-CAD: 03Kunigami 07http://brlcad.org * r2887 10/wiki/User:Kunigami/GSoc2011/Proposal: /* Timeline */ Updated accomplished tasks and changed the next ones.
20:24.14CIA-117BRL-CAD: 03starseeker * r44674 10/brlcad/trunk/src/adrt/isst_tcltk.c: Use TIE_EXPORT instead of manually calling out the _declspec statements in the .c file (VS2010 Express doesn't seem to like that...)
20:25.32CIA-117BRL-CAD: 03Kunigami 07http://brlcad.org * r2888 10/wiki/User:Kunigami/GSoc2011/Reports:
20:29.18``Erikheh, doh, was gonna commit a fix to issttcltk... I missed up and put #__declspec insead of __declspec :D
20:31.33starseeker``Erik: er, whatever :-)
20:31.35starseekercan do that too
22:05.55*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879469.dsl.bell.ca)
22:58.00*** join/#brlcad WhiteCalf (MK@whitecalf.net)
IRC log for #brlcad on 20110525

IRC log for #brlcad on 20110525

00:23.54*** join/#brlcad crazy_imp (~mj@a89-182-193-229.net-htp.de)
01:18.10*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:22.24*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
04:58.47*** join/#brlcad dli (~dli@dsl-69-172-110-67.acanac.net)
05:02.21*** join/#brlcad Stattrav (~Stattrav@122.167.103.233)
05:02.21*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:45.29*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:47.35*** join/#brlcad merzo (~merzo@193.254.217.44)
07:12.36*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
10:44.01dlomanyawns
11:05.13CIA-117BRL-CAD: 03davidloman * r44675 10/geomcore/trunk/ (5 files in 2 dirs): Drop antiquated DbObject and DbObjectManifest classes. No longer useful
11:06.42CIA-117BRL-CAD: 03davidloman * r44676 10/geomcore/trunk/ (include/BrlcadDb.h src/GS/BrlcadDb.cxx src/GS/CMakeLists.txt): Rough in skeleton for BrlcadDb class. Will contain all fns necessary for loading, reading, writing and saving a .g file.
11:07.11dlomannice!  sf.net is fast this morning!
11:08.30CIA-117BRL-CAD: 03davidloman * r44677 10/geomcore/trunk/src/GS/BrlcadDb.cxx: Oops. Make constructor implementation match declaration =D
11:09.16CIA-117BRL-CAD: 03davidloman * r44678 10/geomcore/trunk/src/GS/DataManager.cxx: Make DataManager handle DirListReqMsg objects appropriately.
11:26.59*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
12:27.08CIA-117BRL-CAD: 03davidloman * r44679 10/geomcore/trunk/ (include/StringUtils.h src/utility/StringUtils.cxx): Pull out commonly used, or otherwise generically useful functions into new StringUtils class.
12:27.38CIA-117BRL-CAD: 03davidloman * r44680 10/geomcore/trunk/src/utility/CMakeLists.txt: Wire StringUtils into cmake
12:28.20CIA-117BRL-CAD: 03davidloman * r44681 10/geomcore/trunk/ (include/FileDataSource.h src/GS/FileDataSource.cxx): Allow FileDataSource to take advantage of StringUtils class. Remove any duplicate functionality.
13:12.21CIA-117BRL-CAD: 03davidloman * r44682 10/geomcore/trunk/ (include/StringUtils.h src/utility/StringUtils.cxx): Add getLastStepOfPath() to StringUtils.
13:18.37*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
14:04.15CIA-117BRL-CAD: 03davidloman * r44683 10/geomcore/trunk/tests/func/utility/ (CMakeLists.txt StringUtilsTest.cxx): Implement a stringUtils functional test.
15:23.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:33.36CIA-117BRL-CAD: 03davidloman * r44684 10/geomcore/trunk/tests/unit/utility/StringUtilsUTest.cxx: Implement some unit tests for StringUtils class
17:46.35CIA-117BRL-CAD: 03davidloman * r44685 10/geomcore/trunk/ (include/StringUtils.h src/utility/StringUtils.cxx): Break out common functionality in path parsers. Structure function calls more logically.
17:48.27*** join/#brlcad mafm (~mafm@34.Red-83-49-87.dynamicIP.rima-tde.net)
17:53.36*** join/#brlcad mafm_ (~mafm@161.Red-83-50-132.dynamicIP.rima-tde.net)
18:15.30CIA-117BRL-CAD: 03davidloman * r44686 10/geomcore/trunk/ (2 files in 2 dirs): getLastStepOfPath was failing in certain cases. Created unit tests and fixed bugs.
18:18.09CIA-117BRL-CAD: 03davidloman * r44687 10/geomcore/trunk/ (include/BrlcadDb.h src/GS/BrlcadDb.cxx): Flesh out BrlcadDB implementation a bit by adding isValidPath() and list() along with other support functions like open() close() etc...
18:18.53CIA-117BRL-CAD: 03davidloman * r44688 10/geomcore/trunk/include/FileDataSource.h: Documentation and formatting....
18:20.18CIA-117BRL-CAD: 03davidloman * r44689 10/geomcore/trunk/src/GS/FileDataSource.cxx: Make FileDataSource use the BrlcadDb class. Remove duplicate code.
18:39.00CIA-117BRL-CAD: 03davidloman * r44690 10/geomcore/trunk/src/GS/BrlcadDb.cxx: Check for solids. Solids don't have children!
19:01.45*** join/#brlcad Stattrav (~Stattrav@117.192.155.188)
19:01.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:02.27CIA-117BRL-CAD: 03starseeker * r44691 10/brlcad/trunk/src/tclscripts/rtwizard/rtwizard.tcl: Make rtwizard's dirname line match archer's...
19:13.37CIA-117BRL-CAD: 03davidloman * r44692 10/geomcore/trunk/ (3 files in 2 dirs): Implement a simple oop wrapper around the bu_external struct
19:25.40kunigami_Hi, I have a newbie question: If I'm to include some library's headers and these header's depend on other headers, do I need to include both?
19:27.42CIA-117BRL-CAD: 03davidloman * r44693 10/geomcore/trunk/src/GS/ExtObject.cxx: free bu_external* on ~ExtObject
19:34.17CIA-117BRL-CAD: 03davidloman * r44694 10/geomcore/trunk/ (include/BrlcadDb.h src/GS/BrlcadDb.cxx): Implement contains() and getExtObj().
19:40.59kunigami_for example, I'm using a OSL header: oslexec.h. So I added OSL/include/ with include_directories(). but now, I get compile error from dependencies of oslexec.h such as openEXR
19:54.04CIA-117BRL-CAD: 03davidloman * r44695 10/geomcore/trunk/ (include/BrlcadDb.h src/GS/BrlcadDb.cxx): Implement a bulk getter: getExtObjects(...). works on a list of names and provides a list of ExtObject objects.
19:56.58*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601324.dsl.bell.ca)
20:32.49*** join/#brlcad willdye (~willdye@fern.dsndata.com)
20:34.56*** part/#brlcad willdye (~willdye@fern.dsndata.com)
20:49.21*** join/#brlcad mafm (~mafm@161.Red-83-50-132.dynamicIP.rima-tde.net)
21:11.05*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
23:23.34starseekerkunigami_: It depends on the headers, but if oslexec.h is pulling other .h files, you do need to include the directories that will let the compiler find them
23:24.29starseekerkunigami_: what's the error specifically?  (I'd suggest using http://pastebin.mozilla.org/)
23:29.46kunigami_I'm trying to compile the osl-raytracer out of the osl-system. But OSL depends on other libraries, so I was getting dependence errors. Now, I've included all these dependences on the cmake file, but I'm still getting some compile errors. I'll double-check my CMakeLists to see if I'm not doing anything silly :) BRB
23:32.57``ErikI find that when I'm doing something silly, if often becomes obvious as I'm in the process of sharing to get help... I'm probably the meanest one around and I don't make fun of people or think less if they make mistakes (though I might rib on the ones who should know better, but it's in jest)
23:33.15``Erikand with that, I'm out for the night, hasta la pasta, mi amiga2000's
IRC log for #brlcad on 20110526

IRC log for #brlcad on 20110526

00:24.17*** join/#brlcad crazy_imp (~mj@a89-182-248-36.net-htp.de)
00:30.16*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601324.dsl.bell.ca)
00:31.22IriX64http://pastebin.com/u/IriX64
00:31.34IriX64trying to install 7.18.5
00:48.56kunigami_Well, I have no idea on how to resolve this error: http://pastebin.mozilla.org/1234805
00:49.19kunigami_It's difficult to tell what I'm trying to compile tough
00:50.00kunigami_Here's the cmake file I'm using: http://pastebin.mozilla.org/1234806
00:52.22kunigami_A weird thing is that the raytracer depends on a file named oslexec_pvt.h, which is only available in the osl source, not in the generated lib (that is, on dist/include)
00:53.39starseekerkunigami_: have you tried sticking that file in the include dir?
00:54.46kunigami_I added its directory with: include_directories(/Users/kunigami/dev/osl/src/liboslexec/)
00:55.32starseekerkunigami_: grep in your build directory for osl and see which binary files match RendererServices
00:56.32starseekermy first guess is that you need to link in some other OSL library
00:59.40kunigami_grep says that simplerend.o and testrender.o matches
01:00.42starseekernothing else?
01:00.58starseekerwhere is RendererServices defined?
01:01.58kunigami_hmm this is the testrender build. In the osl build there are a bunch of files that maches. The only library is liboslexec
01:02.11kunigami_ls
01:02.14kunigami_oops
01:02.48starseekertry make VERBOSE=1 - does it definitely show the oslexec library being linked in?
01:04.18starseekermust head out - kunigami_, how did you build the original test program? I'd look at what you did there vs. what's going on here, if that succeeded...
01:04.46kunigami_I think so. The last executed command is? /usr/bin/c++    -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/testrender.dir/testrender.o CMakeFiles/testrender.dir/simplerend.o CMakeFiles/testrender.dir/sphere.o  -o testrender  /Users/kunigami/dev/osl/dist/macosx/lib/liboslexec.dylib /Users/kunigami/dev/osl/dist/macosx/lib/liboslcomp.dylib /Users/kunigami/dev/oiio/dist/macosx/lib/libOpenImageIO.dylib /opt/local/lib/libboost_filesystem-mt
01:04.47kunigami_/opt/local/lib/libboost_regex-mt.dylib /opt/local/lib/libboost_system-mt.dylib /opt/local/lib/libboost_thread-mt.dylib
01:05.12kunigami_There's a /Users/member:kunigami/dev/osl/dist/macosx/lib/liboslexec.dylib  there
01:07.29kunigami_I built the original system with almost the same configuration of cmake. The difference was that testrender was under osl sources: /osl/src/testrender
01:10.36kunigami_also, when linking libraries: oslexec, oslcomp and oslquery, CMakeLists does: TARGET_LINK_LIBRARIES ( testrender oslexec oslcomp oslquery) because these libraries are being generated too (I'm not sure if I was clear)
01:25.28kunigami_Well, I'll take a break now. Tomorrow I'm back!
02:28.10*** join/#brlcad CIA-56 (cia@cia.atheme.org)
04:45.04*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
06:09.15*** join/#brlcad CIA-61 (cia@cia.atheme.org)
06:15.14*** join/#brlcad Stattrav (~Stattrav@122.167.103.233)
06:15.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:21.22*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:21.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:27.51*** join/#brlcad crazy_imp (~mj@a89-182-248-36.net-htp.de)
06:34.11*** join/#brlcad merzo (~merzo@193.254.217.44)
06:35.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:22.08*** join/#brlcad mafm (~mafm@30.Red-83-45-252.dynamicIP.rima-tde.net)
11:29.38*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
11:39.40CIA-61BRL-CAD: 03erikgreenwald * r44696 10/brlcad/trunk/src/proc-db/ (CMakeLists.txt Makefile.am ringworld.c): Stub Niven's "ringworld" structure as a proc-db. It'd be an awesome stress test.
11:43.37dlomanhahahahahaha awesome :)
11:44.29``Erik:D a few details at http://en.wikipedia.org/wiki/Ringworld
11:44.58``Erik1.6m km wide, 1au radius
11:45.33``Erikwoops, oh, yeah, 1.6m km wide, 1.6k km tal
11:46.08``Erikcould whack it with rtweight and come up with a rough density, too
11:46.15dlomanso, whats the Material Code for scrith ? =D
11:46.40``Erik42. :D
11:48.36``Erikhuh, took him 10 years to write the sequel (ringworld engineers) to address the complaints about gaps
11:48.50``Erikhttp://en.wikipedia.org/wiki/The_Ringworld_Engineers
11:49.08``ErikSecondly, many fans had identified numerous engineering problems in the Ringworld as described in the novel.
11:49.36``ErikNiven says that one reason he wrote The Ringworld Engineers was to address these engineering problems.
11:49.55``Erikaaanyways, fun set of books :) I haven't picked up the latest one yet (2004)
11:51.14``Erikwas thinking of coming up with the set of parms for the proc-db first, so'z it could do everything from a halo to a ringworld, with enough data to generate a newtonian model
11:52.50``Erikthen an anchored fractal to generate the 'tiles'
11:55.07*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
12:06.01dlomanthat would be a fun project :)
12:08.05dlomanand, to be honest... the hardest part would be the terrain generation
12:22.32*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
12:22.32*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:35.39*** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br)
12:40.56*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:42.01``Erikterrain generation how? it's a pretty basic fractal exercise... done it before, will do it again
12:42.50``Erikoften, it's just taking a square, finding the center point, putting a random value there based on the neighbors, recurse... quadtree fractal pattern
12:54.53dlomanright on.
12:54.58dlomani ment relative difficulty
12:55.30dlomanthe ring structure (aka a circular 'trench') is all of about 3 cyls :)
12:56.01dlomanring.r = u s1.s - s2.s - s3.s
12:56.03dlomandone
12:56.22dlomanso the fractal terrain gen is much more 'difficult' than that :)
13:00.55``Erikfor a really basic one, yes... but we might need to go with DSPs to get the surface
14:33.57dlomanso it turns out that a sphere with a radius of 699500 km doesn't raytrace correctly :)  (at least on my box)
15:13.40CIA-61BRL-CAD: 03erikgreenwald * r44697 10/brlcad/trunk/src/proc-db/ringworld.c: remove 'count' check, since that doesn't exist.
15:13.55dlomanlol, i just oened that file to fix that :)  nice
15:21.26*** join/#brlcad mafm (~mafm@30.Red-83-45-252.dynamicIP.rima-tde.net)
15:53.49*** join/#brlcad WhiteCalf (MK@whitecalf.net)
17:00.38*** join/#brlcad Stattrav (~Stattrav@117.192.153.125)
17:00.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:25.15*** join/#brlcad dtidrow (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
18:04.44CIA-61BRL-CAD: 03erikgreenwald * r44698 10/brlcad/trunk/include/config_win_cmake.h: remove duplicate WITH_TK definition
18:05.32CIA-61BRL-CAD: 03starseeker * r44699 10/brlcad/trunk/src/librt/CMakeLists.txt: Use the same trick for librt as librt-static - Wno-error due to Mac OSX warning
18:07.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:12.01*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
19:31.41*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
19:33.31*** join/#brlcad crazy_imp (~mj@a89-182-248-36.net-htp.de)
19:40.44*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
19:41.20*** join/#brlcad Stattrav (~Stattrav@117.192.153.125)
19:41.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:15.18*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
20:38.12CIA-61BRL-CAD: 03bob1961 * r44700 10/brlcad/trunk/src/other/iwidgets/generic/ (4 files): Temporarily deleted a few troublesome options that currently break things like iwidgets::fileselectionbox and rtwizard. Need to find out what's really going on here.
21:14.20*** join/#brlcad merzo (~merzo@165-62-94-178.pool.ukrtel.net)
IRC log for #brlcad on 20110527

IRC log for #brlcad on 20110527

00:23.56*** join/#brlcad crazy_imp (~mj@a89-182-143-78.net-htp.de)
02:34.35*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
03:35.57*** join/#brlcad merzo (~merzo@1-45-132-95.pool.ukrtel.net)
04:22.07*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
06:52.54*** join/#brlcad merzo (~merzo@193.254.217.44)
07:06.05*** join/#brlcad Stattrav (~Stattrav@122.167.103.233)
07:06.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:23.35*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:25.32*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
07:25.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:42.35*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565552.dsl.bell.ca)
08:53.14*** join/#brlcad mafm (~mafm@62.Red-81-34-125.dynamicIP.rima-tde.net)
09:37.01*** join/#brlcad merzo (~merzo@193.254.217.44)
11:04.20*** join/#brlcad mafm (~mafm@62.Red-81-34-125.dynamicIP.rima-tde.net)
11:16.16*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
11:50.50*** join/#brlcad Stattrav (~Stattrav@122.167.103.233)
11:50.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:53.03dlomanso ``Erik, i did some data szie calcs in my head yesterday..... might have a memory issue :)
12:53.08*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:54.04dloman1.6x10^6 pix x 1.6x10^6 pix image is about 2.56 x 10^12 pixels... and at 1 byte per pixel... yeah, thats a bit large :)
13:10.56``Erik1552000000000000000000 square meters.
13:12.35dlomanm or km ?
13:12.48dlomani though we were saying 1 pix == 1 km
13:13.08``Erikmeters
13:13.16``Erikum, at 1km res, 1.5 petabytes
13:14.08``Erikeven when ya think you grok the scale of that puppy, it's still ungrokkable
13:18.55``Erikhm, 606x^2 widths of area
13:19.59``Erik1284.5 km pixels will produce 1g of surface 8b elevetion data
13:20.18``Erikor wait, no, my math is wrong
13:20.51``Erik1245.6 km edges will produce 1g
13:22.20``Eriksooooo, the US would be ~6 pixels at that resolution
13:22.44dlomanlol
13:22.53dlomanquestion, since i know nothing of the process:
13:23.27dlomanwhen brlcad 'preps' geometry... is that a good place to put in a LoD Proc Gen function(s) ?
13:24.01``Erikno, LoD requires some understanding of the viewpoints location, and prep doesn't know anything about that
13:24.17``Erikwe cannot do LoD with the raytracing data as it stands
13:24.33dlomanhrm, so does the geometry have *any* idea where the viewport is at anytime?
13:24.59``Erikthe geometry does not, the app is responsible for setting ray start points
13:25.57``Erikhm
13:26.12``Erikmebbe a fractal procedural displacement shader might work
13:26.35starseekerone of the things we need to do longer term is have the primitives provide the ability to take a view/geometry size and return an appropriate wireframe
13:26.58dlomanso whats the order of operations then?
13:27.23dlomancall 'rt', prep geometry, then start firing rays?
13:27.30``Erikyup
13:27.45``Erikall prep is completed before the first ray is shot
13:27.56starseekerhas been tempted to start that level of re-org once or twice, but it's deeply invasive and probably a fair bit of work
13:28.01dlomanaka, if the geometry is prepped *after* the call is made to rt, then the viewport data should be 'somewhere' that a function could get at.
13:29.15``Erikstarseeker: I'm setting up a git repo using the svn bridge on my desk fbsd box, um, /usr/tmp/brlcad.git I think? if you want to clone it for playground activities
13:29.21dlomancourse, this is 'logic' speaking and that may need not apply :)
13:30.18``Eriksets is schedule to involve; finding pants. getting coffee. cleaning house on his day off here O.o wee.
13:30.40dlomanoh you taking a 4 day then?
13:30.46``Erikyup
13:30.56``ErikCN today
13:32.26dlomanstarseeker: you taking a 4 day weekend also?
13:39.06starseekerno, i'll be in
13:52.14dlomanWell that's a great way to kick off the weekend.  my bank called.  Accounts been comprimized :/
13:56.45``Erikow, an actual compromise? not a false positive?
13:57.29dlomanthey shut down all my cards :) I have all my money.  So whether it was a true compirmise or not, i really don't care :/
13:57.51dlomanHowever, now i have to jump thru a ton of hoops to get my accounts back up
13:58.03dlomankinda annoyed atm :)
14:03.13``Erikbetter'n bein' empty handed, ah surpose
14:03.21dlomantrue that
14:03.33``Erikcranks up poplamoose while cleaning O.o
14:03.37dlomanpretty much why im not beating down the door of the base Bank of America
14:03.40``Erikpomplamoose, even
14:04.19``Erik(if'n ya don't know them, check them out on the youtubez, 'beat it' 'put a ring on it' 'nature boy'... awesome covers)
14:05.49dlomanoh god, they did a christmas commercial this last year......
14:06.16dlomanthey annoyed the hell out of me, lol
14:07.06``Erikthe hyundai one, yeah.. but they really don't suck, that was just a corporate obnoxiousness
14:07.10dlomanseems it was the editing on the commercial, these arent that bad :)
14:07.27``Eriktheir version of nature boy is effin' awesome
14:07.32dlomanheh, is that a moog?
14:37.21CIA-61BRL-CAD: 03davidloman * r44701 10/geomcore/trunk/ (include/BrlcadDb.h src/GS/BrlcadDb.cxx): Verbage change from 'path' to 'gPath' for clarity.
14:45.58CIA-61BRL-CAD: 03davidloman * r44702 10/geomcore/trunk/src/GS/BrlcadDb.cxx: Was mistakenly using StringUtils::getLastStepOfPath() as a .g file path validation check. Fixt. Now correctly using BrlcadDb::_isValidPath() call.
14:49.56CIA-61BRL-CAD: 03davidloman * r44703 10/geomcore/trunk/include/BrlcadDb.h: "//TODO Move these to a more common place?" added in reference to common return values dealing with errors for BrlcadDb function calls.
15:47.12CIA-61BRL-CAD: 03davidloman * r44704 10/geomcore/trunk/include/BrlcadDb.h: Add some notes about ByteBuffer::wrap() failure handling.
15:49.18CIA-61BRL-CAD: 03davidloman * r44705 10/geomcore/trunk/ (include/ExtObject.h src/GS/ExtObject.cxx): Add in a serialize method to ExtObject that creates a ByteBuffer and passed back a pointer to it. This allows the ByteBuffer to be exactly the size required.
18:12.09*** join/#brlcad Stattrav (~Stattrav@117.202.25.117)
18:12.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:17.52*** join/#brlcad Stattrav (~Stattrav@117.202.25.117)
19:17.52*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:32.19CIA-61BRL-CAD: 03r_weiss * r44706 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c:
20:32.19CIA-61BRL-CAD: Corrected logic in functions 'nmg_booltree_evaluate' and 'nmg_boolean' within
20:32.19CIA-61BRL-CAD: file 'nmg_bool.c'. This fix stops the error 'nmg_boolean() result of
20:32.19CIA-61BRL-CAD: nmg_booltree_evaluate() isn't tp' which occurs occasionally when performing nmg
20:32.19CIA-61BRL-CAD: boolean operations such as when using the mged 'facetize' command. This change
20:32.19CIA-61BRL-CAD: also allows boolean operations to return a null result without failing.
20:44.04*** join/#brlcad Stattrav (~Stattrav@117.202.25.117)
20:44.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:17.17*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
21:18.06starseekerdloman: ouch, sorry to hear that about your accounts!
21:18.23starseeker``Erik: just curious, do you know anything about Lua (scripting language?)
21:26.33``Erikunfortunately
21:26.47``Erikit's an ugly language, but it's simple and very embedable
21:27.38``Erikyou can use luac to generate luab files, compiled things... um, I heard lua 5 was supposed to fix a lot of stuff, I mostly dealt with lua 4 a llllong time ago, doing a platformer video game
21:34.05starseekerhmm... how's it compare to Tcl?
21:34.21starseekernotes 5 has been out for quite a while...
21:35.50``Erikmy info is outdated, at the time... tcl was worse to integrate and slower, but tcl felt "lisper"
21:36.09``Eriklua reminded me of basic
21:36.15starseekerwinces
21:36.41starseekerdarn... the "easier to integrate" bit really appeals...
21:36.53``Erikit's a tiny language, easy to integrate... compile yourself up a version and experiment
21:37.18starseekerwas looking over the Tcl build logic again and having bad things happen to his blood pressure...
21:37.56starseekerhas evil thought... stick a Tcl parser on top of Lua :-P
21:38.05``Eriktcl is stuck in the 80's, lua is designed for src/other/ type stuff... but the language panders to javascript/java/c++/perl programmers
21:39.52starseekerhmm... wonder if I can re-create the "mged command prompt" type environment
21:39.54``Erikgive it a shot, it's an easy one to learn... *shrug* all I can give is my opinion, and opinions are like a**holes :)
21:40.11starseekerwouldn't have Tcl under the hood though, so I suppose it's a guaranteed fail for acceptance
21:41.02``Erikmy vote is for removing tcl from teh core and providing a more abstracted interface so we can use python, ruby, cl, scheme, lua, ... perl... whatever anyone wants
21:41.48``ErikC is lingua franca, so that should be our exposed interface
21:42.30starseekerwould looove to find a way to get Tcl/Tk out of src/other altogether
21:43.38``Erikthat'd be interesting, I'm more concerned with doing "make librt" with no tcl having to be involved
21:44.09starseekerheh, CMake perspective talking for me I guess - making sure Tcl/Tk builds integrated and everywhere is like hauling around a 50 pound anchor
21:44.56``Erikyou're the one who decided to start not liking automake and push the cmake migration... you did it to yourself :D
21:45.28``Erikso release today is not happening?
21:46.19``Erikhttp://www.youtube.com/watch?v=LNpwBpZUrzk  <-- all sorts of awesome
21:46.49starseeker``Erik: well, having autotools and Windows builds separate is another and worse sort of boat anchor
21:47.12``Erikyes, windows is a definite ... issue
21:47.17starseeker``Erik: unfortunately, probably not today
21:47.46starseekerthat little change of Bob's got rtwizard up, but means we need another round of testing
21:47.52``Erikif you can get a build on thor, awesome... if not, well, it's a .0 and we expect pain in the transfer
21:48.09starseekerplus I suppose I should really figure out why rtedge isn't displaying in the rtwizard framebuffer...
21:48.41starseekeroh, and I didn't START not liking autotools - I NEVER liked it :-P
21:48.47``Erikpart of me wants to say "just throw it out" and take out lumps, and .2 will be a big cleanup release
21:48.56``Eriks/out/our/
21:49.08starseeker``Erik: <shrug>  we can do that
21:49.28starseeker``Erik: you can do the release too you know - I don't have some "magic key"
21:49.45``ErikI'm taking the day off, I'm not allowed to do work :D
21:49.50starseekerheh - cop-out
21:50.17``Erikindeed. I'll go back to scrubbing toilets and floors now. :/
21:51.04``Erik(almost tagged yesterday, btw... seriously, fuggit, it'll suck and we'll get "it don't work", but ...)
21:51.28starseekeryeah, I know
21:51.33starseekerupdates...
21:53.27``Erik7.20.2 will see the fixing of the osX ogl bug, the 32b tie bug, ... but 7.20.0 will not.
21:53.54starseeker``Erik: if we're going to do it - anything we should toss in the deprecation list now?
21:54.03starseeker(i.e. we want to get rid of this ASAP?)
21:54.04``Erikand the 7.20.0 winderz binary will be huge for the community, I think... 99% instead of 25% of the tools
21:54.36``Erikum, mro and the libtie change is all I can think of
21:55.12starseekerheh - mro is kinda "whoops, it's gone now" instead of "deprecated, will go away eventually"
21:55.12``Erikmaybe a statement about the altered attribute handling?
21:56.07``Erik"deprecated 7.20.0, deleted 7.20.0. Sucks to be you."
21:56.37``Erikit's a minor bump, we're allowed to be a bit mean
21:57.36starseekeryeah, I guess we'll go with condition c
21:57.46``Erikbtw, I started a cmake migration of the project who would lament the mro removal... it's making me nervous
21:58.55``Erikcan trunk succeed at a distcheck? I tried to keep my modifications synced between cmake and automake, but ...
21:59.33``Erikif automake can do a distcheck, benchmark and regress, I say tag and go
21:59.39starseekernods
21:59.47starseekerI'm trying an automake distcheck now
22:00.40``Erikseriously, crank http://www.youtube.com/watch?v=LNpwBpZUrzk up, get the sub going, tell bob it's for his own good
22:00.57starseekerheh
22:01.04starseekerhe's not in, actually
22:01.16``ErikPLAY IT
22:02.28starseekeris
22:02.52``Eriksince you're doing the gruntwork of releasing today, and it's a monster change, um, I will do a fbsd port cook on tuesday, and thinking this will be a very short run release
22:03.10``Erikwe might target 7.20.2 for, uh, 2 weeks from now?
22:03.23starseekernods
22:03.40starseekerum... PomplamooseMusic
22:03.43starseeker?
22:03.45``Erikyes
22:04.11``Erikpomplamoose is a duo band out of nyc, their cover of nat king coles nature boy is ... awesome
22:04.33starseekerthey seem to bet getting a lot of attention
22:04.36starseekerdo you know them?
22:04.39``ErikI've been a fan of the for a  few years, last winter they had a contract deal with hyundai on a commercial
22:05.15starseekercool
22:05.45``ErikI like to pretend that I find awesome bands before they become popular, I'm very "scene" like that
22:06.02starseekernods - it does happen, once in a while
22:06.35``ErikI think there're 4 that I've told people about that have gone on to commercials or some kinda recognition when I pointed to them as subs
22:07.02``Erikgoldfrapp, 2 weeks after I messaged every I knew about them, they showed up in a commercial
22:07.10CIA-61BRL-CAD: 03starseeker * r44707 10/brlcad/trunk/doc/deprecation.txt: Abrupt, but close to minimal and what appears to be the least painful way forward - mro is going, all hail bu_attribute_value_set.
22:07.20starseekerawesome
22:07.26``Erik(they probably shot the commercial before I heard them, but *shrug*)
22:07.48starseekerawaits the thunderbolt from brlcad...
22:08.37``Erikthe boy has a mini-me. the thunderbolt is 3 months out at the soonest
22:09.12``Erikand this is explicitely permitted in the rules set down
22:09.35starseekerhehe
22:09.57starseekerwell, for loose definitions of minimal
22:10.01starseekerclose though
22:10.08*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
22:10.16starseekerand I still think it's the least painful approach
22:10.37``Erikthe, uh, favor you volunteered for, I started on it, it's gonna be rough... they have a very intertwined dep chain with lots of #include action
22:12.02``Erik#include <Ap.h> instead of #include
22:12.09``Erik#include "Ap/Ap.h"
22:12.19starseekerwinces
22:12.21``Erikso a lot of -I action
22:12.36starseekerI suppose untangling it isn't an option
22:12.39``Erikor C changes...
22:13.17``Erikif you can convince geoff...
22:13.26starseekeruh... yeah
22:13.42starseeker-I it is
22:13.51starseekerinitially at least
22:14.02``Erikfrankly, I started my 'acst' branch to superseed both teams
22:14.23``Erikunfortunately, we lack a dietz
22:14.43``Erik"nothing succeeds like success", my gut feeling is that success will be punished
22:15.17starseekerwell, all we can do is try
22:17.00CIA-61BRL-CAD: 03starseeker * r44708 10/brlcad/trunk/ (README include/conf/MINOR include/conf/PATCH): Here we got - bump the version numbers.
22:19.03CIA-61BRL-CAD: 03starseeker * r44709 10/brlcad/trunk/ChangeLog: Update ChangeLog
22:21.02``Erikw00t
22:29.35CIA-61BRL-CAD: 03starseeker * r44710 10/brlcad/branches/STABLE/ (427 files in 165 dirs): Merge trunk r44709 to STABLE
22:30.11*** join/#brlcad Yoshi477 (~jan@d72-39-60-53.home1.cgocable.net)
22:34.11starseekernotes he somehow missed that the byacc maintainer also maintains a version of flex
22:35.23starseekerhmm...
22:59.31starseekerhmm, cool  http://tdb.samba.org/
23:00.34CIA-61BRL-CAD: 03starseeker * r44711 10/brlcad/tags/rel-7-20-0/: Tag 7.20.0
23:00.53starseeker``Erik: there ya go
23:01.36starseekerahhh, crud - forgot to update the date of release
23:02.16CIA-61BRL-CAD: 03starseeker * r44712 10/brlcad/trunk/NEWS: Ah, nuts - forgot to fix the date.
23:05.06CIA-61BRL-CAD: 03starseeker * r44713 10/brlcad/trunk/ (NEWS README include/conf/PATCH): Bump numbers.
23:05.24starseekerneeds to get outta here...
IRC log for #brlcad on 20110528

IRC log for #brlcad on 20110528

00:22.53*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
00:29.34*** join/#brlcad crazy_imp (~mj@a89-182-152-210.net-htp.de)
07:46.39CIA-61BRL-CAD: 03Seo1 07http://brlcad.org * r2889 10/wiki/Seo_service_-_For_starters: New page: For starters, there are a lot of great '''[http://lease-a-seo.com SEO services]''' provided by capable Warriors for hire in the Warriorforum that offer honest services. However, there are ...
11:06.32*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:54.05*** join/#brlcad kunigami_ (~kunigami@187.106.4.220)
12:02.01*** join/#brlcad dli (~dli@dsl-69-172-110-67.acanac.net)
13:09.12*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
13:26.48*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
13:36.14*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:49.20*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
13:58.35*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
14:11.07epilegstarseeker: I see that yesterday You updated the STABLE branch with v7.20.0 but there isn't a new source talball file for download
14:12.13epilegcan I upload new deb/rpm packages based on STABLE branch?
14:17.45``Erikprobably, but the official tarball should be up very soon, tuesday at the latest. If you want source builds to match the md5/sha1, might be worth holding off an actual change in the package mgmt upstream. This one might take a little more work, though, we've switched to cmake... it might be a good idea to make a tar from stable and try to update the spec/deb files to accomodate that, then tweak a little once the 'official' source is upload
14:19.15``ErikI suspect 7.20.2 will be fairly soon once we get feedback, this is a .0 release, so we kinda expect some turbulance :) give it a whack and let us know how bad it is ;)
14:25.12epilegI didn't switch to cmake the deb/rpm building process because there are some things that I'm not able to properly work
14:25.56epilegis there a way to specify the "man" dir with cmake?
14:27.13epilegis there a way to enable the pango rendering text with cmake?
14:39.38epilegalso, is there a way to set the "share" folder?
14:47.51starseekerepileg: it's not thoroughly tested, but you can try -DBRLCAD_INSTALL_MAN_DIR=... -DMAN_DIR=...
14:48.27starseekerfor share, it would be -DBRLCAD_INSTALL_DATA_DIR=... -DDDATA_DIR=...
14:48.40starseekeruh... dunno what pango is
14:49.00starseekershould clean up that project specific stuff at some point...
14:49.02epilegpango is a text rendering library
14:49.09starseekerdo we use it?
14:49.15epilegyes
14:49.18starseekerwhere?
14:49.44epilegin mged, arch and rtwizard
14:50.16starseekerum.  if it needs to be specifically linked in I probably missed it the first time around
14:50.23epilegif I compile brlcad without pango dev libs in my system, resulting execs do not properly render the text
14:50.42starseekerwe don't seem to directly use it in our code
14:50.51starseekeronly grep matches for pango are in misc and sh dirs
14:51.37starseekerI'm not sure that's us directly then
14:51.54starseekerare you using system Tcl/Tk?
14:52.08epilegI don't know, i just tell You what I get
14:52.36starseekertry ldd - does mged link to libpango?
14:53.10starseekerepileg: I would suggest trying a CMake build and see what happens
14:53.23epilegnot, I build them with "./configure --enable-optimized --enable-almost-everything --with-ogl --disable-debug"
14:53.49starseekerhmm.  Might be some subtlty with how X and Tk are doing text together
14:53.51epilegI already try cmake and I get a non rendering text on them
14:54.01starseekereven with libpango installed?
14:55.06starseekerah, wait - that might be the freetype stuff with Tk - I think I might be assuming freetype for the Tk build on some platforms...
14:55.23starseekerepileg: which version of Debian is this?
14:55.49epilegldd mged http://paste.debian.net/118256/
14:57.04starseekerhuh, weird
14:57.21epilegyes even with libpango installed. in the same system, using autotools, text rendering, with cmake, not text rendering
14:57.43starseekerprobably something about the Tk build then
14:58.06starseekeris depressed but not surprised
14:58.16epileghahaha
14:59.19starseekerDebian does some funny stuff
14:59.53starseekerone of the ultimate motivators for me trying Gentoo was Debian acting funny when it came to customization and settings
15:00.11starseekerGod I'd love to ditch tcl/tk
15:00.13epilegwell, I do this in Ubuntu 10.10
15:00.30starseekerk - only way I can test that is if it works in VirtualBox
15:01.25epilegwell, I always compile and create deb/rpm on virtualbox machines
15:01.40epilegwithout problems
15:04.04starseekerepileg: I don't suppose you could try the CMake build with a system Tcl/Tk?
15:05.09epilegI use exactly this:
15:05.09epilegcmake -DBRLCAD-ENABLE_OPTIMIZED_BUILD=ON -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DBRLCAD-ENABLE_STRICT=OFF
15:05.35starseekerepileg: OK - what happens with cmake -DBRLCAD-ENABLE_OPTIMIZED_BUILD=ON -DBRLCAD-ENABLE_STRICT=OFF
15:05.49starseekerand a system tcl/tk installed
15:07.13epileggive mi time to test this
15:07.19starseekersure
15:07.23starseekerno hurry
15:07.42starseekerI'll only be online for a little while - just post the results when you have them
15:07.47starseekerwe read scrollback
15:08.13epilegok
15:39.19epilegstarseeker: same result
15:39.49epilegtwo captures of the results
15:39.51epileghttp://imageshack.us/photo/my-images/832/autotools.png/
15:40.12epileghttp://imageshack.us/photo/my-images/810/cmake.png/
15:45.07starseekerhuh - http://www.thermalanalytics.com/products/eclectic/
15:45.20starseekergpl and needs info to download though...
15:46.27starseekerlooks like different fonts are being used
15:47.58epilegmay be, but both compiled and installed in the same system, just different is autotools and cmake
15:48.48starseekerepileg: yeah, then my first suspicion is how Tk is being built/installed
15:49.00starseekerO.o - "Eclectic was developed by the U.S. Army TACOM"
15:50.09starseekerwell well well
15:55.33epilegI've to go
15:55.44starseekerepileg: later - thanks for trying things out!
15:56.03epilegno problem :-)
15:56.15starseekerO.O - Eclectic can import our .asc files??
16:00.53*** part/#brlcad kunigami_ (~kunigami@187.106.4.220)
18:02.01*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
18:42.33*** join/#brlcad Stattrav (~Stattrav@117.192.129.172)
18:42.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:44.43*** part/#brlcad epileg (~epileg@unaffiliated/epileg)
21:53.49*** join/#brlcad merzo (~merzo@153-26-94-178.pool.ukrtel.net)
22:47.35*** join/#brlcad bhinesley (~bhinesley@99.144.90.118)
IRC log for #brlcad on 20110529

IRC log for #brlcad on 20110529

00:30.14*** join/#brlcad crazy_imp (~mj@a89-182-228-136.net-htp.de)
00:44.53``Erik*read* pango is part of the GTK suite, I can't think of any bit of our stuff that uses it directly.... it may be required by something in, say, pkgconfig or something
03:34.49*** join/#brlcad merzo (~merzo@18-11-94-178.pool.ukrtel.net)
04:38.01*** join/#brlcad Stattrav (~Stattrav@117.192.129.172)
04:38.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
04:54.47*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
05:24.57*** join/#brlcad Stattrav_ (~Stattrav@117.192.129.172)
06:10.41*** join/#brlcad Stattrav (~Stattrav@117.192.129.172)
06:10.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:31.18*** join/#brlcad dli (~dli@dsl-69-172-110-67.acanac.net)
07:57.19*** join/#brlcad mac- (mac@mac.banda.pl)
07:57.21mac-hi
08:45.08*** join/#brlcad dli (~dli@dsl-69-172-110-67.acanac.net)
10:01.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:59.52*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:43.50*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:52.30*** join/#brlcad kunigami (~kunigami@187.106.4.220)
14:16.12*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:44.48*** join/#brlcad Stattrav (~Stattrav@117.202.18.71)
14:44.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:17.49mac-anyone live ?
17:18.42mac-can you tell me if it is possible to draw some mechanical parts and then simulate movement of them in BRL-CAD ?
17:19.19mac-i.e. with input data of placement from external source of data?
17:36.35piksidon't know actually
17:36.43piksisounds like you want solidworks-like features
17:37.14mac-maybe more like Nastran
17:37.28piksii'm not sure, if there are such features i've never used them
17:37.56mac-but I do not need to get result of mechanic calculations from BRL-CAD, because I wish to perform all calculations in Octave
17:38.19mac-then wish to visualize results by parts movement in i.e. BRL-CAD
17:38.45mac-I thought that I can do that in Salome but got difficulties - no one could help me
17:42.27mac-is there any official Forum for BRL-CAD ?
18:05.38bhinesleymac: http://sourceforge.net/projects/brlcad/forums
18:24.02*** join/#brlcad Stattrav (~Stattrav@117.202.18.71)
18:24.02*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:28.14mac-thanks
20:38.36piksimac-: i don't think there is
21:24.06bhinesleypiksi: see my last statement
21:28.22piksioh, my eye didn't catch that one
22:26.52bhinesleyCould someone review/approve a patch for me?
22:26.59bhinesleyhttps://sourceforge.net/tracker/?func=detail&aid=3258381&group_id=105292&atid=640804
22:27.09bhinesleyI'm going to be making some similar changes in a bit.
22:27.30bhinesleyjust a 'lil tcl
22:35.42*** join/#brlcad ibot (~ibot@rikers.org)
22:35.43*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
23:44.56*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20110530

IRC log for #brlcad on 20110530

00:08.12*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
00:24.34*** join/#brlcad crazy_imp (~mj@a89-182-144-90.net-htp.de)
01:22.49bhinesleyhere's a similar one that would be nice to have reviewed: https://sourceforge.net/tracker/?func=detail&aid=3309109&group_id=105292&atid=640804
01:26.26bhinesley... and for those on the go, here are three really easy ones: 3267991, 3247828, 3309107 :)
01:26.31bhinesleythanks in advance
02:02.15CIA-61BRL-CAD: 03Kunigami 07http://brlcad.org * r2891 10/wiki/User:Kunigami/GSoc2011/Reports:
04:22.30*** join/#brlcad MinstrelGypsy (~kvirc@bas2-sudbury98-1177726421.dsl.bell.ca)
05:15.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:49.42*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
08:49.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:32.15*** join/#brlcad crazy_imp (~mj@a89-182-144-90.net-htp.de)
11:50.38*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:33.58*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:58.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:34.55*** join/#brlcad merzo (~merzo@193.254.217.44)
14:26.03*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:06.45*** join/#brlcad mafm (~mafm@193.153.53.166)
18:45.43*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565378.dsl.bell.ca)
18:46.35IriX64pardon, but in your CMake build, how do I disable -Werror, surely you can't expect me to fix all the warnings
18:50.13IriX64tried passing -DCMAKE_DISABLE_STRICT=ON but no joy
18:51.17IriX64ill continue to play, ciao
19:36.50*** join/#brlcad Stattrav (~Stattrav@117.192.140.111)
19:36.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:24.09*** join/#brlcad dloman_ (~claymore@BZ.BZFLAG.BZ)
20:26.13*** join/#brlcad roberthl_ (~robert@v1.rhl.me.uk)
22:25.32*** join/#brlcad mafm (~mafm@193.153.53.166)
23:36.54CIA-61BRL-CAD: 03Documentshredding 07http://brlcad.org * r2892 10/wiki/Document_Shredding_-_How_To_Document_Destruction_Training: New page: If you speak of '''[http://www.shreddingservices4.com/document-shredding-nyc/ document shredding]''', their is a need for you to undergo a training so that you can do whatever you wanted t...
IRC log for #brlcad on 20110531

IRC log for #brlcad on 20110531

00:25.40*** join/#brlcad crazy_imp (~mj@a89-182-235-192.net-htp.de)
00:55.01*** join/#brlcad bhinesley (~bhinesley@99.144.90.118)
01:25.31*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:36.24starseekerbhinesley: I'll review the patch tomorrow
02:36.37bhinesleycool, thanks
05:23.45*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
06:43.58*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:44.26*** join/#brlcad roberthl (~robert@v1.rhl.me.uk)
06:44.33*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
09:05.48*** join/#brlcad Stattrav (~Stattrav@122.167.103.233)
09:05.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:00.51*** join/#brlcad mafm (~mafm@220.Red-88-22-160.staticIP.rima-tde.net)
10:31.26dlomanyawns
10:37.13CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Document Shredding - How To Document Destruction Training]]": This is spam. Please, someone with permissions, block User:Documentshredding
10:38.03CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Seo service - For starters]]": This is spam. Please, someone with permissions, block User:Seo1
10:38.41CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Credit Cards Australia - How to Rate Credit Card Australia]]": This is spam. Please, someone with permissions, block User:Creditcardsaustralia
10:39.52CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Casinopaysafecard]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
10:40.04dlomanoooooh, i has block perms.  Hehehehe, when did that happen?
10:40.11dloman"THE POWER!!!!!"
10:40.42CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Seo1]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
10:41.13CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Creditcardsaustralia]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
10:41.55CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Image:Casino Paysafecard - How To PlayStealing Bundles Casino24.pdf]]": This is spam.
10:43.09CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Documentshredding]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
10:45.55CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r2893 10/wiki/Documentation: Reverted edits by [[Special:Contributions/67.180.102.232|67.180.102.232]] ([[User talk:67.180.102.232|Talk]]); changed back to last version by [[User:72.234.127.28|72.234.127.28]]
10:46.28CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:67.180.102.232]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
10:50.03CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r2894 10/wiki/Documentation: Rolling back to last good version
10:51.46CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:72.234.127.28]] with an expiry time of infinite (anonymous users only, account creation disabled): Inserting nonsense/gibberish into pages
10:52.28CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:122.3.171.14]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
10:52.51CIA-61BRL-CAD: 03Dloman 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Forex Trading- How To Understand FOREX Market Sentiment]]": This is spam.
11:02.08``Erikprobably about when you created your wiki account and brlcad set you up
11:24.53*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:43.37*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:08.18*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:19.28CIA-61BRL-CAD: 03brlcad * r44714 10/brlcad/trunk/include/bu.h: consider different encoding types for proper flexibility
13:48.58starseeker``Erik: http://www.thermalanalytics.com/products/eclectic/
14:02.46*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
14:26.21*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
14:43.17*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:06.11*** join/#brlcad DarkCalf (DC@173.231.40.98)
15:07.49starseekerO.o http://scantailor.sourceforge.net/
15:16.08*** part/#brlcad PrezKennedy (DC@173.231.40.98)
15:18.17*** join/#brlcad DarkCalf (DC@173.231.40.98)
15:35.03*** join/#brlcad dli (~dli@dsl-69-172-110-67.acanac.net)
15:54.34*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
15:55.21*** join/#brlcad Stattrav (~Stattrav@117.192.136.106)
15:55.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:08.19CIA-61BRL-CAD: 03starseeker * r44715 10/brlcad/trunk/src/tclscripts/mged/g2asc.tcl: Reviewed and applied patch from Brandon Hinesley (one of our 2011 GSoC students) that replaces MGED's g2asc saving dialog with the proper use of tk_getSaveFile.
16:26.21CIA-61BRL-CAD: 03brlcad * r44716 10/brlcad/trunk/AUTHORS: note the code contribution from sf patch 3258381 (mged's export ASCII: Changed input box to a save file dialog) that cliff applied in r44715
16:41.04*** join/#brlcad kjander (~kristoffe@ip70-190-7-201.ph.ph.cox.net)
16:49.44kjanderhave any private engineering firms adopted brl-cad?
16:50.15kjanderi should say, does anyone have experience with a private engineering firm making that adoption?
16:50.43``Erikcommercial companies rarely advertise what products they use, I know that beoing has used it, but only because they've sent change requests or info requests
16:51.05starseekerkjander: depends also on what use
16:51.30starseekerif you mean as their primary in-house CAD tool, I have not heard of anyone doing that
16:53.27kjanderright. i work with a small engineering startup and was curious if it would make a decent replacement for something like solidworks. i definitely see the pitfalls, the engineers aren't used to it, the commandline would seem primitive and the programmatic access it provides not much of an advantage. but also, as a startup, cad licensing costs can be brutal and i wanted to see if i could pitch brlcad as a viable alt
16:54.20kjanderit's mostly for soft mockups of design, material interrogation is not a primary concern
16:54.27``ErikBRL-CAD is mostly designed as an analysis package and may not be optimal for design work... we don't do, say, line drawing with scales
16:56.24*** join/#brlcad dli (~dli@dyn-199-015.vpn.199.Concordia.CA)
16:57.10kjanderthanks ``Erik and starseeker. I think it that quick exchange you've already answered my question
17:19.27*** part/#brlcad kjander (~kristoffe@ip70-190-7-201.ph.ph.cox.net)
17:26.18*** join/#brlcad dli (~dli@69.172.110.67)
17:27.33CIA-61BRL-CAD: 03bob1961 * r44717 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Removed bot2pipe from mArcherCoreCommands.
17:55.49bhinesleyIs it a bad idea to submit two separate patches that affect the same file?
18:46.55starseekerbhinesley: no, that's fine
18:47.22bhinesleyit doesn't make it any more difficult to approve?
18:49.00starseekerwell, depends on the change
18:49.09starseekerfeel free to submit it however you think best
18:49.37bhinesleyokay
18:49.52bhinesleyI was trying to avoid putting unrelated changes in the same patch
18:50.26starseekerhow extensive are the changes?
18:50.41bhinesleynot very... 10-20 lines each
18:51.07starseekershrugs - either way, we'll sort it out ;-)
18:51.32bhinesleyalright
18:52.48bhinesleyjust trying to not be a PITA
18:54.59bhinesleywaits patiently for his book to arrive: http://www.amazon.com/Practical-Programming-Tcl-Tk-4th/dp/0130385603/ref=pd_ecc_rvi_cart_1
18:55.03starseekerbhinesley: as long as you're improving things, your not a PITA :-)
18:55.09bhinesleyhaha
18:55.10bhinesleyright on
19:06.30*** join/#brlcad mafm (~mafm@230.Red-81-43-146.staticIP.rima-tde.net)
21:47.48*** join/#brlcad Stattrav (~Stattrav@117.192.156.95)
21:47.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:54.24CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:526 buy viagra]]": content was: '[http://viagra-soft-flavoured.abanteae.pl CLICK HERE TO BUY SOFT VIAGRA]' (and the only contributor was '[[Special:Contributions/83.24.64.144|83.24.64.144]]')
21:54.34CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:83.24.64.144]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
21:59.15*** join/#brlcad Stattrav (~Stattrav@117.192.156.95)
21:59.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:03.17CIA-61BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2895 10/wiki/User:Bhinesley: Started logging my progress onto the wiki
IRC log for #brlcad on 20110601

IRC log for #brlcad on 20110601

00:18.44*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
00:20.59starseekeris chagrined to discoverer he is having to read up on our basic ray/object intersection algorithms to make sense of them
00:21.58bhinesleywell if it makes you feel any better, I had to look up chagrined to make sense of what you're saying
00:24.00starseekerheh
00:24.22starseekerTim Daly of Axiom likes to say "there is no such thing as a simple job"
00:24.59*** join/#brlcad crazy_imp (~mj@a89-182-228-164.net-htp.de)
03:50.11*** part/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
05:12.35*** join/#brlcad Stattrav (~Stattrav@122.167.103.233)
05:12.35*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:42.00starseekerO.o http://advancingusability.wordpress.com/2010/11/09/cutexture-a-framework-for-qt-user-interfaces-in-ogre3d/
05:45.00starseekerO.O https://qt.gitorious.org/qt-labs/qmlogre
05:45.56starseekerdrools: http://www.youtube.com/watch?v=b_3xfFuwGOQ
05:46.56starseekerthat might just be the Qt/Ogre integration solution
08:34.11*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
08:34.47epilegi got problems setting man dir in cmake
08:36.59epilegif I set: $ cmake [...] -DBRLCAD_INSTALL_MAN_DIR=share/man
08:36.59epilegI get:
08:36.59epileg[...]
08:36.59epilegGenerating Tk man pages...
08:36.59epilegCMake Error at src/other/tkhtml/CMakeLists.txt:102 (install):
08:36.59epileg<PROTECTED>
08:36.59epileg[...]
09:21.24*** join/#brlcad mafm (~mafm@193.153.198.34)
09:26.11*** join/#brlcad mafm (~mafm@193.153.198.34)
10:30.01epilegif I use: -DBRLCAD_INSTALL_DATA_DIR=share
10:30.01epilegman pages are not installed too
10:58.30dlomanyawns
11:28.14*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
11:58.37*** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br)
12:36.39*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:45.54*** join/#brlcad Stattrav (~Stattrav@117.192.138.140)
12:45.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:47.41*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:03.41CIA-61BRL-CAD: 03bob1961 * r44718 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Needed to override ArcherCore::cmd because core commands added in Archer (including Core plugins) were not getting recognized. Added code to append core commands coming from plugins to mArcherCoreCommands.
13:39.27``Erikhttp://news.slashdot.org/story/11/05/31/202238/Free-Software-Faces-a-Test-With-Qt
13:44.35``Erikhttp://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/
14:25.06d_rossbergis there a special reason why the build of static libs is switched off for MSVC in BRLCAD_Util.cmake?
14:41.46*** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br)
14:47.19starseeker``Erik: heh - the comments pretty thoroughly trashed that slashdot posting
14:50.42starseekerd_rossberg: uh... a vague memory was that they weren't adding much for the Windows build and were significantly increasing the build time...
14:50.46starseekerI'd have to check the logs
14:51.21starseekerd_rossberg: do you need them?
14:51.35starseekerthe windows build is amazingly slow as it is...
15:00.15*** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br)
15:04.54*** join/#brlcad merzo (~merzo@193.254.217.44)
15:06.47*** join/#brlcad DarkCalf (DC@173.231.40.98)
15:11.50d_rossbergstarseeker: i need them for the brlcad.dll
15:12.20d_rossbergthey are build on request only anyway, or?
15:12.45d_rossberg"BUILD_STATIC_LIBS"
15:13.30starseekerd_rossberg: what's the difference on Windows between static and dynamic libs?
15:15.21starseekerd_rossberg: The way I had it set up - Debug builds don't build static unless you explicitly ask for them
15:15.32starseekerRelease builds do build them, except with MSVC
15:16.31starseekerd_rossberg: the quick way to try it is to take out the "AND NOT MSVC" and see what happens
15:17.21starseekerreally does need to do more scrubbing on the CMake build logic
15:19.32d_rossbergdynamic: you get a file (.dll) which has to be installed with the program; static: you get a file with object code which has to be linked with something executable
15:20.10d_rossbergi'll try a run with "NOT MSVC" removed
16:21.00*** join/#brlcad Stattrav (~Stattrav@117.192.138.140)
16:21.00*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:28.03CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload:
16:28.03CIA-61BRL-CAD: uploaded "[[Image:Moose Mascot.png]]": This image was drawn by Nicholas Reed in
16:28.03CIA-61BRL-CAD: 2009 depicting BRL-CAD's magnificent moose mascot. BRL-CAD's was started in
16:28.03CIA-61BRL-CAD: 1979 by Mike Muuss. You're clever enough to figure out the rest.
16:29.49CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Image:Moose Mascot.png]]": too big
16:31.46CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload:
16:31.46CIA-61BRL-CAD: uploaded "[[Image:Moose Mascot.png]]": This image was drawn by Nicholas Reed in 2009 depicting BRL-CAD's magnificent moose mascot. BRL-CAD's was started in 1979 by Mike Muuss. You're clever enough to figure out the rest.
16:31.46CIA-61BRL-CAD: This image was used in 2011 for the [http://brlcad.org/d/node/89 BRL-CAD Logo Competition].
18:01.58*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:10.52*** join/#brlcad dli (~dli@66.49.232.17)
18:45.18CIA-61BRL-CAD: 03bob1961 * r44719 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Clear out bindings on the <Enter> event for the geometry window in Ged::init_view_bindings.
19:40.57kunigami_Hi, since I'm not able to link OSL libraries, I was thinking in building them together with BRLCAD. Do you think that this is feasible or I will have to change too much of the cmake configuration files?
19:45.19*** join/#brlcad Stattrav (~Stattrav@117.192.138.140)
19:45.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:38.56CIA-61BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2898 10/wiki/User:Bhinesley: /* Log */
IRC log for #brlcad on 20110602

IRC log for #brlcad on 20110602

00:25.25*** join/#brlcad crazy_imp (~mj@a89-182-221-38.net-htp.de)
00:31.43starseekerkunigami: you haven't been able to determine the reason it's not working?
00:31.49starseekerkunigami: have you asked on the osl list?
03:05.05bhinesleyif anyone has a minute, I'd really appreciate a review of this patch: https://sourceforge.net/tracker/?func=detail&aid=3309109&group_id=105292&atid=640804
03:06.31bhinesleyit changes mged's text box for inputting a new database name to a better dialog
03:08.19bhinesleyhelp a young noob earn svn access ;-)
03:08.28bhinesley*commit
03:09.10bhinesleyand eliminate channel spam
03:38.10CIA-61BRL-CAD: 03starseeker * r44720 10/brlcad/trunk/src/tclscripts/mged/mged.tcl: Apply patch 3309109 from Brandon Hinesley - use tk dialog for File->New in mged.
03:58.44CIA-61BRL-CAD: 03brlcad * r44721 10/brlcad/trunk/NEWS: cliff applied sf patch 3309109 (mged's new db input box changed to save file dialog) from brandon hinesley providing an improved file->new dialog for mged
03:59.47bhinesleythanks :)
04:03.34CIA-61BRL-CAD: 03brlcad * r44722 10/geomcore/trunk/src/libNet/CMakeLists.txt: apparently libpkg is needed, link failure on 10.6 with pkg symbols
07:17.06*** join/#brlcad Stattrav (~Stattrav@122.167.103.233)
07:17.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:25.47*** join/#brlcad mafm (~mafm@116.Red-83-49-86.dynamicIP.rima-tde.net)
13:48.22CIA-61BRL-CAD: 03davidloman * r44723 10/geomcore/trunk/src/libNet/netMsg/GeometryManifestMsg.cxx: Remove some debug printers
14:02.56dlomanhttp://www.27bslash6.com/missy.html
14:02.58dlomanlol
14:06.08crazy_impheyho
14:06.22crazy_imphow can i translate & rotate a group in mged?
14:06.48crazy_imp(or convert the given group into a solid, which would be fine too :)
14:07.30dlomaneither use the 'matrix selection' menu or the  
14:07.43dloman'oed' command
14:08.25dlomaneither way, the concept is to prvide a path from the root of the db tree all the way down to a solid, splitting the path where you want to edit
14:12.14crazy_impis it possible to show the commands issued by the matrix selection?
14:12.45dlomanthat i dunno
14:12.49dlomanif your path is:
14:13.07dlomanall/armor/upper/toparmor.r/toparmor01.s
14:13.33dlomanthen the oed command for editing 'upper' would look like this:
14:13.56dlomanoed all/armor/    upper/toparmor.r/toparmor01.s
14:14.02dlomanthat would put you in matrix edit mode
14:14.28dlomanyou should, at that point, be able to manipulate 'upper' and everything in the tree below it.
14:14.59dlomanfor rotations, please note that the keypoint of toparmor01.s will be the 'rotate about' point
14:16.17crazy_impok, thanks :)
14:16.25dlomanno prob!
14:20.47crazy_impdloman: what kind of "object" is armor?
14:22.05dlomancombination
14:22.30dlomanobject type path:  comb/comb/comb/region/prim
14:22.58crazy_impk
14:32.51crazy_impwith the oed command i only get one primitive :|. let's say i have foo.r made from a.s, b.s and c.s (as union) -> 'oed foo.r /b.s' edits only b.s
14:33.11dlomancorrect.
14:33.35dlomanthe first object on the right hand path will be the object in edit
14:33.39dlomanso in your case
14:33.50dlomanif you:  'B foo.r'
14:34.03dlomanthen 'oed / /foo.r/a.s'
14:34.11dlomanyou will be in matrix edit mode on foo.r
14:34.45crazy_imp\o/
14:52.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:53.40crazy_impdloman: is it possible to have a second region like foo.r, made from the same solids but at a different position (making the changes only to the region and not to the solids) - so if i change the solid, it'll be changed in both regions?
14:54.01dlomanyes, that's basic instancing.
14:54.10dlomanjust do a copy
14:54.22dloman'cp foo.r foo2.r'
14:56.57crazy_imphm, oed / /foo2.r/b.s fails now
14:57.13dlomanis foo2.r displayed?
14:57.21dlomanvia 'e foo2.r' ?
14:58.00crazy_impah, ok :)
14:58.42crazy_impbut i can't change the solid now, sed b.s says it's "multiply referenced" (which makes sense)
14:58.44crazy_impbrb
14:59.19dlomanyou can edit the solid individually with 'sed' command, just not via matrix edit
15:10.51crazy_impit's a little bit confusing i can't edit the original b.s, but if i change foo2.r/b.s every b.s changes :D
15:16.43dlomanyeah :/  a lot of times, instancing is more trouble that its worth.
15:20.33crazy_impthe other way round would be more intuitive imho
15:27.51*** join/#brlcad mafm (~mafm@116.Red-83-49-86.dynamicIP.rima-tde.net)
16:05.46CIA-61BRL-CAD: 03davidloman * r44724 10/geomcore/trunk/ (2 files in 2 dirs): Change some verbage for clarity.
16:07.28CIA-61BRL-CAD: 03davidloman * r44725 10/geomcore/trunk/ (5 files in 2 dirs): Modify iDataSource interface a bit. Added/fixed lots of functionality to FileDataSource.
16:09.20CIA-61BRL-CAD: 03davidloman * r44726 10/geomcore/trunk/src/GS/GSClient.cxx: Fix handling of GeoChunk. Was returning false instead of true. Removed debug printing.
16:11.16CIA-61BRL-CAD: 03davidloman * r44727 10/geomcore/trunk/ (include/ExtObject.h src/GS/ExtObject.cxx): Reworked cstr to take full path rather than just object name. Fixed deconstructor memory freeing. Added EXT_MAGIC to serialization/deserialization routines. Various other fixes.
16:12.58CIA-61BRL-CAD: 03davidloman * r44728 10/geomcore/trunk/ (include/BrlcadDb.h src/GS/BrlcadDb.cxx): Add NULL_POINTER return value static. Add in recursive functions for pulling an entire tree of geometry rather than just the children of an object.
16:14.30CIA-61BRL-CAD: 03davidloman * r44729 10/geomcore/trunk/src/GS/DataManager.cxx: Cascading changes from the mods to FileDataSource, BrlcadDb and ExtObject
16:24.38CIA-61BRL-CAD: 03davidloman * r44730 10/geomcore/trunk/tests/func/GS/FileDataSourceTest.cxx: Using ExtObject now not MinimialObject
16:25.16*** join/#brlcad merzo (~merzo@189-2-94-178.pool.ukrtel.net)
16:34.56*** join/#brlcad Stattrav (~Stattrav@117.192.134.147)
16:34.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:45.22*** join/#brlcad Stattrav (~Stattrav@117.192.134.147)
16:45.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:22.17*** join/#brlcad Stattrav (~Stattrav@117.192.134.147)
17:22.17*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:12.41*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
18:12.48yukonbobhello, #brl-cad :
18:12.51yukonbob:)
18:49.58CIA-61BRL-CAD: 03davidloman * r44731 10/geomcore/trunk/ (5 files in 5 dirs): Remove dependancy for libge. Replaced by simpler BrlcadDb and ExtObject classes
18:50.09*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
19:00.44*** join/#brlcad merzo (~merzo@174-237-132-95.pool.ukrtel.net)
22:02.37*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
22:11.59*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
23:18.19CIA-61BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2899 10/wiki/User:Bhinesley: /* Log */ today
23:23.23*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
IRC log for #brlcad on 20110603

IRC log for #brlcad on 20110603

00:12.43*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
00:25.48*** join/#brlcad crazy_imp (~mj@a89-182-173-66.net-htp.de)
00:32.54*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
01:07.01crazy_impis it possible to extrude a face along a curve? (like the pipe solid, but with another shape)
02:23.53bhinesleydo you mean a revolve, like this: http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%202010%20User%20Documentation/index.html?url=WS1a9193826455f5ffa23ce210c4a30acaf-540f.htm,topicNumber=d0e304250 ?
02:24.00bhinesleyif so, I believe the answer is no
02:28.13bhinesleyIt looks like someone attempted it: http://brlcad.org/wiki/User:Pacman87
02:28.26bhinesleyI do not see any indication that it was finished though
02:29.51bhinesleyand actually, what you asked for sounds more like a sweep than a revolve
02:31.19bhinesleylike this: http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%202010%20User%20Documentation/index.html?url=WS1a9193826455f5ffa23ce210c4a30acaf-5303.htm,topicNumber=d0e319229
04:41.46bhinesleysighs peacefully
04:41.47bhinesleyAll that reading paid off, I'm finally getting somewhere with migrating/refactoring the man command
04:49.58bhinesleyShould Archer continue to use the MGED man pages for the time being?
05:03.51bhinesleyAlso, what do you guys think about adding a filter for the list of man pages, or perhaps just having it jump to a given letter of the alphabet on keypress? There are many commands on there, making it kind of a pain to navigate.
05:07.00CIA-61BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2900 10/wiki/User:Bhinesley: /* Log */ modified today's entries
07:36.37*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
07:36.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:20.46crazy_impbhinesley: the sweep would allow more complex curves / paths, but the revolve would do the trick too with more (with some more segments)
08:34.58*** join/#brlcad mafm (~mafm@142.Red-81-34-12.dynamicIP.rima-tde.net)
10:42.40kunigamistarseeker: I never get replies from OSL list :) But thanks to Sean's email I've figured out the error! I'll update the news soon!
10:52.09*** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br)
11:48.59*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
11:56.43*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
12:34.33starseekerhuh: http://www.askoh.com/stcad/index.html
13:00.24*** join/#brlcad mafm (~mafm@220.Red-88-22-160.staticIP.rima-tde.net)
13:16.46*** join/#brlcad mafm_ (~mafm@220.Red-88-22-160.staticIP.rima-tde.net)
14:33.58*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:36.34*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:23.41*** join/#brlcad piksi (piksi@pi-xi.net)
15:48.50*** join/#brlcad Stattrav_ (~Stattrav@117.192.147.206)
17:05.21``Erikstarseeker: 7.20.0 is missing a lot of it's cmake stuff :/
17:08.11*** join/#brlcad Stattrav (~Stattrav@117.192.147.206)
17:08.12*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:39.41*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
17:48.15*** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br)
18:03.29kunigamihi, does anyone know how to clear a flag on cmake? I did the following test: http://pastebin.mozilla.org/1241499
18:04.10kunigamibut when I run make VERBOSE=1, it seems that the -Werror flag is added even after I clean up CMAKE_CXX_FLAGS
18:11.29bhinesleytry --disable-strict or -DBRLCAD-ENABLE_STRICT=OFF
18:16.29bhinesleykunigami: probably the prior
18:29.41kunigamibhinesley: Actually I'd like to turn off these flags only when compiling part of the code. So I was wondering if I could do this within cmake files
18:33.36bhinesleyOh, gottcha.
18:45.03``Erikdon't think it's set up like that, but if you dig into the CMakeFiles directory, you'll find a file flags.make you can edit (it'll be overwritten if you change the CMakeLists.txt)
19:02.18kunigamiBut can't I add this to CMakeLists so that whenever I run cmake the generated Makefile does not contain those flags?
19:02.56kunigamiThat's because OSL headers raises warnings that are treated as error by BRL-CAD build, so I'm getting compilation errors
19:04.41kunigamiSo I'd like to temporarily turn off some of the flags (I think only -Werror is enough) and after linking to OSL I turn them on again
19:17.19``ErikI jabbed starseeker, he's the cmake guy
19:18.23starseekerkunigami: there is a way
19:18.40starseekerbut why not just turn off the strict flags?
19:19.22starseekerif you want to get more systematic...
19:19.24starseekerlooks it up
19:20.34starseekerok.
19:20.41starseekersrc/other/CMakeLists.txt is an example
19:21.17starseekerfor the specific directory and sub-directories, you can do add_definitions(-Wno-error) or something like that
19:21.26starseekerif you want to do it just for a single library...
19:22.32starseeker<PROTECTED>
19:22.40starseekerthat's probably what you're looking for
19:26.16``ErikNice. http://www.youtube.com/watch?v=sR2296df-bc  (short ringworld animation)
19:27.13*** join/#brlcad Stattrav (~Stattrav@117.192.147.206)
19:27.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:32.57CIA-61BRL-CAD: 03erikgreenwald * r44732 10/brlcad/trunk/src/proc-db/ringworld.c: add some size/mass notes
19:37.51CIA-61BRL-CAD: 03erikgreenwald * r44733 10/brlcad/trunk/src/libgcv/ (CMakeLists.txt Makefile.am bottess.c): start of the j3dbool style tesselator
19:42.47*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
19:44.21CIA-61BRL-CAD: 03Trgjos 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:Cash-payday-advance.pdf]]"
19:51.12CIA-61BRL-CAD: 03Trgjos 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded "[[Image:5128.pdf]]"
20:28.01bhinesleystarseeker ``Erik: I'm moving the Manual Page Browser out of Archer/MGED and into a common script. Should this go in tclscripts/helpcomm.tcl, a new file tclscripts/man_browser.tcl, or somewhere else?
20:46.11kunigamistarseeker: thank you
20:47.32starseekerbhinesley: I'd vote for tclscripts/man_browser.tcl
21:07.42bhinesleyruns with it
21:16.05kunigamihmm I think that what is causing the compile error is the -pedantic flag. Adding -Wno-error is not resolving :(
21:17.13starseekertry -DBRLCAD-ENABLE_COMPILER_WARNINGS=OFF
21:20.49kunigamicool. it works well. thanks again
22:34.03*** join/#brlcad kunigami (~kunigami@201.53.197.251)
IRC log for #brlcad on 20110604

IRC log for #brlcad on 20110604

00:26.00*** join/#brlcad crazy_imp (~mj@a89-182-194-68.net-htp.de)
01:09.54starseekerwow - this old chicken scheme CMake file is quite impressive
04:24.08``Erikcool, salvagable? educational?
04:24.33starseekerdefinitely educational - possibly partially salvagable
04:24.41starseekerlooks like the build has changed quite a lot
04:25.21starseekerI stuck it on github as a hedge against the copy of the tarball someone posted vanishing - https://github.com/starseeker/chicken
04:25.49starseeker(chicken-2.6 branch has the original tarball contents.  master is 4.7.0 - will try to adapt the CMake build logic to the new stuff there)
04:27.37starseeker``Erik: overall chicken is still looking like the best combination of license, features and embeddability of the options I can scare up, plus the advantage of a head start on the CMake stuff
04:28.21starseekerrather impressively, the 2.6 version actually built successfully on my gentoo box - not bad given how old it is
06:37.08*** join/#brlcad Stattrav (~Stattrav@117.192.128.135)
06:37.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:17.30*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
08:17.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:58.53*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
10:58.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:42.59*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
16:55.53*** join/#brlcad tupone (~tupone@gentoo/developer/tupone)
16:57.16*** part/#brlcad tupone (~tupone@gentoo/developer/tupone)
17:51.33CIA-61BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2903 10/wiki/User:Bhinesley: /* Log */ Logged yesterday, and my plan for today
17:53.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:00.27CIA-61BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2904 10/wiki/User:Bhinesley: /* Log */ Reversing order, so that new entries are on top
18:22.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:38.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:12.40*** join/#brlcad Stattrav (~Stattrav@117.192.132.10)
19:12.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:25.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:40.27*** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net)
21:35.17CIA-61BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2905 10/wiki/User:Bhinesley: /* Experience */ removed redundant statement
22:53.51*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177879044.dsl.bell.ca)
IRC log for #brlcad on 20110605

IRC log for #brlcad on 20110605

00:26.13*** join/#brlcad crazy_imp (~mj@a89-182-147-86.net-htp.de)
00:28.34*** join/#brlcad Stattrav (~Stattrav@117.192.132.10)
00:28.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
04:17.50*** join/#brlcad Stattrav (~Stattrav@223.177.104.197)
04:17.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:05.45*** join/#brlcad Stattrav (~Stattrav@203.196.190.162)
11:05.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:10.43*** join/#brlcad Stattrav (~Stattrav@203.196.190.162)
11:10.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:13.25*** join/#brlcad crazy_imp (~mj@a89-182-147-86.net-htp.de)
11:29.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:44.56*** join/#brlcad Stattrav (~Stattrav@27.57.139.96)
15:44.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:03.48*** join/#brlcad Stattrav (~Stattrav@27.57.139.96)
16:03.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:29.15CIA-61BRL-CAD: 03Kunigami 07http://brlcad.org * r2906 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */
17:03.08*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
18:34.15*** join/#brlcad Stattrav (~Stattrav@203.196.190.162)
18:34.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:54.29*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
20:02.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:16.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
23:11.52*** join/#brlcad kunigami (~kunigami@201.53.197.251)
23:34.24*** join/#brlcad piksi (piksi@pi-xi.net)
IRC log for #brlcad on 20110606

IRC log for #brlcad on 20110606

00:26.15*** join/#brlcad crazy_imp (~mj@a89-182-196-119.net-htp.de)
01:20.19*** part/#brlcad kunigami (~kunigami@201.53.197.251)
02:10.55*** join/#brlcad waprat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
02:48.35*** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862)
03:39.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
03:58.31*** join/#brlcad DarkCalf (DC@173.231.40.98)
04:38.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:06.13*** join/#brlcad merzo (~merzo@193.254.217.44)
08:17.52*** join/#brlcad Stattrav_ (~Stattrav@27.57.104.252)
09:32.02*** join/#brlcad Stattrav (~Stattrav@203.196.190.162)
09:32.02*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:27.19dlomanyawns
11:34.03*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
12:23.27*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
12:24.27*** join/#brlcad juanman (~quassel@186.136.168.73)
12:24.33*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:08.42``Erikhm, cia's being a bit slow
14:48.10*** join/#brlcad DarkCalff (DC@173.231.40.98)
14:55.42CIA-61BRL-CAD: 03tbrowder2 * r44734 10/brlcad/trunk/src/libfb/if_X24.c: correct spelling error
15:00.03CIA-61BRL-CAD: 03erikgreenwald * r44735 10/brlcad/trunk/src/conv/g-egg.c: Add a -9 flag to trigger the new bottess stuff for testing.
16:46.49CIA-61BRL-CAD: 03erikgreenwald * r44736 10/brlcad/trunk/src/conv/g-egg.c: add 9 to the getopt list and break after setting use_bottess
17:17.42*** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br)
17:25.18CIA-61BRL-CAD: 03brlcad * r44737 10/geomcore/trunk/tests/unit/test_runner.cxx: fix funky function spacing
17:27.47*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
17:30.51CIA-61BRL-CAD: 03erikgreenwald * r44738 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: Squash uninitialized variable warnings.
17:45.10CIA-61BRL-CAD: 03starseeker * r44739 10/brlcad/trunk/CMakeLists.txt: Go with IGNORE_PATH for avoid install path - seems to be working in tests on Linux...
18:41.00CIA-61BRL-CAD: 03erikgreenwald * r44740 10/brlcad/trunk/ (99 files in 99 dirs): Add CMakeLists.txt to EXTRA_DIST.
18:46.10CIA-61BRL-CAD: 03erikgreenwald * r44741 10/brlcad/trunk/misc/Makefile.am: add CMake/ stuff to EXTRA_DIST
18:59.51CIA-61BRL-CAD: 03starseeker * r44742 10/brlcad/trunk/CMakeLists.txt: Add an option to play nice as a subbuild of another project - turns off the distcheck support, timing code and cpack settings that would be the responsibility of a parent project.
19:01.22``Erikstarseeker: http://pastebin.ca/2075689
19:35.00CIA-61BRL-CAD: 03brlcad * r44743 10/brlcad/trunk/BUGS: seem to have found a bu_log bug
19:35.04CIA-61BRL-CAD: 03erikgreenwald * r44744 10/brlcad/trunk/src/other/step/include/Makefile.am: add scl_cf_cmake.h.in to EXTRA_DIST
19:36.23CIA-61BRL-CAD: 03erikgreenwald * r44745 10/brlcad/trunk/src/other/ (9 files in 9 dirs): add CMake/* stuff to EXTRA_DIST
19:48.06CIA-61BRL-CAD: 03brlcad * r44746 10/brlcad/trunk/ (12 files in 7 dirs): (log message trimmed)
19:48.07CIA-61BRL-CAD: accept kunigami's sf patch 3250116 (Corrected funcionality to bu_basename) that
19:48.07CIA-61BRL-CAD: makes bu_basename() correspond more closely with basename() albeit with
19:48.07CIA-61BRL-CAD: different memory management behavior, the latter being more consistent with
19:48.07CIA-61BRL-CAD: bu_dirname(). this annoyingly requires that all bu_basename calls must now
19:48.07CIA-61BRL-CAD: bu_free the memory returned but is the non-destructive thread-safe reentrant
19:48.07CIA-61BRL-CAD: option for now. a compromise to consider may be to pass the fill-buffer in as a
19:49.31CIA-61BRL-CAD: 03Tbrowder 07http://brlcad.org * r2907 10/wiki/Geometry_Service_Project_Main: /* Implementation Particulars */
19:51.19CIA-61BRL-CAD: 03brlcad * r44747 10/brlcad/trunk/doc/deprecation.txt: the gnu autotools-based build system was officially deprecated with the release of 7.20, so mark it as such so we can begin to migrate callers properly over the next few months.
19:56.13CIA-61BRL-CAD: 03brlcad * r44748 10/brlcad/trunk/doc/deprecation.txt: if something is deprecated, presumably there's something better -- point them to it. should include the version it was deprecated on too for when it's marked obsolete.
20:03.15CIA-61BRL-CAD: 03erikgreenwald * r44749 10/brlcad/trunk/src/fb/ioutil.c: fix missing argument to bu_log and bu_free
20:09.43CIA-61BRL-CAD: 03brlcad * r44750 10/brlcad/trunk/src/libbu/basename.c: expand bu_basename() support to more closely mimic basename() while ensuring that NULL will not be returned. return '.' for NULL and empty paths like basename() does.
20:10.26CIA-61BRL-CAD: 03erikgreenwald * r44751 10/brlcad/trunk/src/libbu/brlcad_path.c: free "tmp_basename" instead of stack allocated "buffer".
20:23.25CIA-61BRL-CAD: 03brlcad * r44752 10/brlcad/trunk/src/libbu/basenametester.c: oop, ac > 1 .. don't prompt by default
20:48.24CIA-61BRL-CAD: 03starseeker * r44753 10/brlcad/trunk/ (27 files in 26 dirs): Needs more testing, but simplify down the install dir variables.
20:55.58CIA-61BRL-CAD: 03brlcad * r44754 10/brlcad/trunk/AUTHORS: credit code contribution from kunigami (sf patch 3250116) that improved/fixed bu_basename() to be consistent with basename(). both bhinesley and kunigami made their first contribution back in March.
20:58.42CIA-61BRL-CAD: 03brlcad * r44755 10/brlcad/trunk/TODO: safer and better performance to avoid the memory allocation on every call, so should consider having the caller pass a buffer in instead of returning one for bu_basename/bu_dirname
21:01.03tofuwaves
21:04.43CIA-61BRL-CAD: 03starseeker * r44756 10/brlcad/trunk/CMakeLists.txt: Minor tweaks to CMakeLists.txt file.
21:11.20CIA-61BRL-CAD: 03starseeker * r44757 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Whoops, missed some variable changes. May be more to fix - needs testing.
21:14.46CIA-61BRL-CAD: 03brlcad * r44758 10/geomcore/trunk/tests/func/GS/CMakeLists.txt: if the geometry engine libs are going to get disabled, then the build targets that use it shouldn't remain enabled
21:19.23CIA-61BRL-CAD: 03brlcad * r44759 10/geomcore/trunk/tests/unit/CMakeLists.txt: testing a mod to the string interface, but bytebuffer is non-functional, so swap out and enable only the StringUtilsUTest.
21:20.19CIA-61BRL-CAD: 03brlcad * r44760 10/geomcore/trunk/include/ (FileDataSource.h GeometryChunkMsg.h SvnDataSource.h): remove unused headers from the geometry engine
21:20.24bhinesleybrlcad: welcome back
21:20.33brlcadthanks bhinesley
21:20.48brlcadand congrats
21:21.03bhinesleythanks
21:21.26CIA-61BRL-CAD: 03starseeker * r44761 10/brlcad/trunk/ (3 files in 2 dirs): Go with KDE style lookup for Carbon and Cocoa - much simpler.
21:23.57brlcad(on commit access)
21:23.59CIA-61BRL-CAD: 03brlcad * r44762 10/geomcore/trunk/ (5 files in 4 dirs): fortunately, there's already a very common name for this type of operation. instead of getLastStepOfPath(), rename to simply basename().
21:24.10brlcadyou and kunigami are good to go, the patches have been fantastic
21:24.47brlcadshould no longer be working in isolated silence... daily frequent commits expected ;)
21:26.43kunigami_cool! For now, I'm still doing experiments that are not ready for commit. Or should I add them as long as they do not break the existing code?
21:26.53brlcadkunigami_: the latter
21:27.24bhinesleyoh awesome, thanks!
21:27.32brlcadas long as you don't break the build, you should almost always commit
21:27.49brlcadyou cannot commit too frequently
21:29.25brlcadplus it helps give the other devs insight into what you're doing, what you've tried, why you ended up going down a particular dev path, etc
21:30.38bhinesleyBy "break the build" I'm assuming you mean resulting in it not compiling. Should we still commit if, say, a command is broken?
21:39.44CIA-61BRL-CAD: 03starseeker * r44763 10/brlcad/trunk/CMakeLists.txt: More minor CMakeLists.txt changes.
21:41.21CIA-61BRL-CAD: 03brlcad * r44764 10/geomcore/trunk/tests/unit/utility/StringUtilsUTest.cxx: twas different code, don't convert to c string only to convert back to std::string
21:43.16starseekerbhinesley: sure
21:44.19CIA-61BRL-CAD: 03brlcad * r44765 10/geomcore/trunk/src/utility/StringUtils.cxx:
21:44.19CIA-61BRL-CAD: de-invent the wheel, refactor to common functionality in libbu. we could call
21:44.19CIA-61BRL-CAD: basename() directly, but bu_basename() is better reuse and has more safeguards.
21:44.19CIA-61BRL-CAD: keep the wrapper so callers can keep their pretty std::strings.
21:45.08starseekerbrlcad: welcome back!
21:45.18starseekerheh - caught up on sleep did ya? :-P
21:48.41brlcadnever really had sleep deprivation (at least no more than usual), in fact I think I've been getting used to MORE sleep than usual
21:49.00starseekerO.o
21:49.11starseekerwow, that's lucky
21:49.12brlcadmore just lots going on, traveling, working on the house, taking care of things
21:49.19starseekernods
21:58.53CIA-61BRL-CAD: 03starseeker * r44766 10/brlcad/trunk/TODO: Note Archer uses of search need to be updated.
22:19.22CIA-61BRL-CAD: 03starseeker * r44767 10/brlcad/trunk/CMakeLists.txt: Reorganize distcheck global logic a bit.
22:21.07bhinesleyis very glad he has rsnapshot run every 4 hours, because several files were just overwritten
22:52.42CIA-61BRL-CAD: 03starseeker * r44768 10/brlcad/trunk/CMakeLists.txt: Note that distcheck, as well as target ordering, are related to the command override logic.
23:24.06*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
23:50.38brlcadbhinesley: also why it's important to commit frequently :)
23:51.46brlcadif you're writing code and an hour goes by without a commit, you're probably doing something wrong
23:51.52brlcadnot working in smaller incremental steps is the usual fail
23:52.39brlcadif you work incrementally, you can almost commit as frequently as you save a file
23:54.12bhinesleygood to knwo
IRC log for #brlcad on 20110607

IRC log for #brlcad on 20110607

00:01.09brlcadyeah, once you start making a little progress, your commits (and your commit messages) will be just as important if not more important than progress updates .. good stuff
00:01.58bhinesleynods
00:02.03bhinesleythere will be a lot going through today
00:10.31*** join/#brlcad Stattrav (~Stattrav@117.192.142.216)
00:10.31*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
00:26.32*** join/#brlcad crazy_imp (~mj@a89-182-166-16.net-htp.de)
01:09.43*** join/#brlcad Stattrav (~Stattrav@117.192.142.216)
01:09.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
01:24.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
01:41.07CIA-61BRL-CAD: 03bhinesley * r44769 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): (log message trimmed)
01:41.07CIA-61BRL-CAD: This was an incremental step towards: 1) adding the man command to archer 2)
01:41.07CIA-61BRL-CAD: creating a megawidget for the manual page browser, to eliminate code duplication
01:41.07CIA-61BRL-CAD: among Archer and MGED. Progress already made on the actual megawidget will be
01:41.07CIA-61BRL-CAD: added in a bit.
01:41.07CIA-61BRL-CAD: -Man command now works in Archer
01:41.08CIA-61BRL-CAD: -Changed the method of adding commands to the Manual Page Browser ToC from "insert end" to using -listvariable as recommended here: http://www.tkdocs.com/tutorial/morewidgets.html
02:44.55CIA-61BRL-CAD: 03bhinesley * r44770 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Removed doarcherMan, and set Help->Man Pages to call the man command directly
03:22.01brlcadwoot
03:31.18bhinesley:-P
03:31.36CIA-61BRL-CAD: 03brlcad * r44771 10/brlcad/trunk/NEWS: brandon added the 'man' command to archer.
03:33.03bhinesleyah
03:33.19bhinesleyshall I make an effort to keep that updated?
03:33.28starseekerit's usually easier
03:33.39starseekeradd user-visible stuff
03:34.00bhinesleyok
03:34.52starseekerbrlcad: what plans did you have for the architecture of libgcv?  I've been reading up on the issue indianla1ry ran into with trying to turn the step-g factory mechanism into a library - the whole "compiler removing static" thing
03:35.12starseekerthere appears to be No Good Solution if you stick to straight C++
03:35.44starseekernot compiler, linker stripping out static rather
03:35.46CIA-61BRL-CAD: 03brlcad * r44772 10/brlcad/trunk/NEWS:
03:35.47CIA-61BRL-CAD: brandon also improved the manual page browser gui behavior with improved
03:35.47CIA-61BRL-CAD: performance (using listbox variable binding instead of adding items manually)
03:35.47CIA-61BRL-CAD: and adding a ListboxSelect event binding so keys, clicking, and dragging work.
03:36.15brlcadbhinesley: yeah, any time you make a change that is *user* visible, it warrants a one-line entry in the NEWS file
03:37.10brlcadthe file has a specific format (described at the bottom) and the commit message per line is important
03:38.01starseekeris getting desperate enough to consider embedding scheme or lisp to escape the limits of C++/C...
03:38.02brlcadthe svn log is automatically parsed with a script that pulls each commit message for each feature line which we use to review features, so try to only commit one line at a time and make your commit message as descriptive as needed
03:38.39brlcadstarseeker: not sure what you're referring to
03:39.01brlcadstep-g's factory mechanism isn't a very good way to do things..
03:39.18starseekererm.  what's the better way?
03:39.45brlcadfirst, what's the goal? :)
03:39.45starseekerwas under the impression the factory design was the recommend approach to that sort of problem...
03:39.50brlcadfactory sure
03:39.57brlcadthere's lots of ways to make factory
03:40.06bhinesleybrlcad: I'm not sure I follow... you're saying keep commit messages brief?
03:40.32starseekerarchitect the library in such a way that you can write one file per format, add it to the library without changing anything else, and have the conversion routines be able to find it when some program using the library asks for it
03:40.50brlcadbhinesley: no no, the messages can/should be any details not encoded in the 70-char news line, like why or bug report numbers or who reported a bug or who requested the feature, ets
03:41.09bhinesleyoh okay
03:41.13brlcadstarseeker: one file per format is probably not feasible
03:41.15bhinesleythat's what I figured
03:41.25starseekergrowl
03:41.39brlcadi mean, there'd be just one set of function hooks per format
03:41.49brlcadala src/librt/primitives
03:41.55brlcadbut it's a set of funcs that you'd need
03:42.08brlcadprobably not just read and write
03:42.26brlcadbut even those two, rather different requirements
03:44.30brlcadstarseeker: as for the rest (add it to the library without changing anything else, and have the conversion routines be able to find) .. that's pretty easy
03:44.48brlcadeven a simple freshman textbook factory implementation will do that
03:45.02brlcador dynamic loaded library snippets
03:45.42starseekerwhat's the problem with step-g's implementation then?
03:45.55starseekerI was under the impression indianla1ry designed it fairly carefully
03:46.58brlcadit's using the sdai (app interface) from the step class libraries
03:47.28starseekerI'm not sure that's the reason it wouldn't work as a lib though...
03:47.29brlcadit static-initializes variables, then searches at runtime for those classes
03:47.48starseekerright - most of the C++ Factory discussions I can find do something like that
03:47.55brlcadthe problem was there was some compiler (erroneously) optimizing away those static classes so they didn't exist iirc
03:48.08brlcadnot the way sdai did it
03:48.14brlcadit was a nit pick detail
03:48.15starseekershakes his head - that's not a compiler error, according to everything that I can find
03:48.25brlcadthe overall approach they intended was 'okay'
03:49.12brlcadit relied on static variable initialization ordering, which isn't guaranteed
03:49.33starseekerhttp://programmerjoe.com/2007/03/18/the-abstract-factory-pattern-in-c/
03:49.51starseekerthat article mentions the linker stripping out "unreferenced" static variables
03:50.01brlcadthey needed to require an init point other than main() (like loading a library or an explicit init() method)
03:51.01brlcadright off the bad, that write-up isn't entirely accurate
03:51.22brlcadlack of an ability to instantiate an object at runtime given the name of a class .. you can, it's just complicated
03:52.29starseekerit must be, I can't find anything so far telling me how to do it
03:52.57brlcadhe states the problem: "you won't be referencing these classes and objects directly, so you have to force the linker to include them by adding references"
03:53.32brlcadit's all in how you build up the factory, and there are lots of ways to go about it
03:53.47brlcadsdai's method was a little sucky, but a simple reference fixes the optimization problem
03:54.02brlcadactual code example I wrote a few years ago:  https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/experimental/v2_99continuing/bzflag/src/include/Factory.h
03:55.02brlcadthat's the abstract factory, here showing a real factory: https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/experimental/v2_99continuing/bzflag/src/bzfs/SpawnPolicyFactory.h
03:55.34brlcadand then the 'simple fix' that lets the linker know that you don't want it to optimize away:  https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/experimental/v2_99continuing/bzflag/src/bzfs/SpawnPolicyFactory.cpp
03:55.45brlcad(see the _init() function)
03:56.32starseekeryes
03:56.41brlcadif I wanted to avoid the explicit list of types (which isn't all that bad really, factory lists don't really tend to change that frequently)
03:57.01brlcadI'd just have made loadable library modules, and load / register them all in _init()
03:57.32brlcadthink dlopen() style
03:58.02starseekerum... wouldn't that get rather messy if you started to have hundereds of types floating around?
03:58.39brlcadnot really, it's still just an entity list
03:58.43starseekeralso, is that portable? (loadable library modules)
03:58.56brlcadpretty much, but I'd start with an explicit list
03:59.51starseekerso is that _init call in a library or an executable?
04:00.04``Erikmight be worth seeing how OS's deal with, say, network cards... I think that might be somewhat analogous. FBSD has a set of common functions and some macro fu to 'register'
04:00.18brlcadstarseeker: an exectuable in that case, but it could go into a lib too
04:01.53brlcadthe libgcv api should get written down first before getting mired in implementation detail like this, issues that might screw up the api if done poorly
04:02.00``Erikmy concern is that different formats hold different kinds of data, so your intermediate format is either a massive superset or a minimal subset :/
04:02.47brlcad.g or .step are both fairly massive supersets
04:02.55brlcador at least have arbitrary storage capability
04:03.23starseekermassive superset doesn't worry me - a pivot format in a conversion library of this nature will be conceptually broad of necessity
04:03.33brlcadin-mem .g ftw imnsho ;)
04:03.47starseekerwe we need is a technically sound way to manage that complexity and extend it cleanly
04:03.51brlcadthat's how most of the code is already written anyways, least effort
04:04.19brlcadbest performing too, of known options
04:04.55starseekerif we focus on just what .g supports, yeah that's the simple route.  But it means the conversion library will remain special purpose, because there are a LOT of things we don't support now in the .g format
04:04.58brlcadbut the api shouldn't care -- it's more "import from X" .. then "export as Y"
04:05.14brlcadusing in-mem .g or whatever else is just the in-between implementation detail
04:05.25starseekersure, but the devil's in the details
04:05.54brlcadnothing says we have to only focus on what .g supports
04:06.11brlcadjust need a mechanism for storing and recovering
04:06.16starseekeruh... if we're using .g as the in-mem pivot format...
04:06.17brlcadwhich .g has
04:06.27brlcadexample
04:06.57``Erikbones, keyframes, animation stuff, programmable definition (povray), ...
04:07.17``Erikv5 has deficiencies
04:07.30brlcadI can store opengl-style pixel shader information into a .g file along with textures and texture mapping data ... even though brl-cad can't use it
04:08.05brlcadjust need to know that's what was stored so when an exporter wants the data, it can pull it
04:08.41starseekerbut if you need to convert that to format FOO pixel shader information for three other export formats, where does that logic live?
04:09.02``Erikyou can shove lightwave objects and scenes in an attribute, but without knowledge of the magic black box, conversion is impossible
04:09.05starseekerI doubt we want each exporter to implement all of its own conversion logic for that sort of thing
04:09.12starseekerthere will be lots of overlap
04:09.50brlcadstarseeker: how's that different than asking "if you need to convert that sphere to format FOO, where does that logic live?"
04:10.01brlcadit lives in format FOO's converter
04:11.22brlcadthe only thing an underlying format is going to give you is structure, not necessarily easier access or reduction of export logic
04:11.36brlcad*memory* structure
04:12.25brlcadso .g doesn't have a memory structure for pixel shaders, boo hoo .. don't care really .. libgcv defines a structure and shoves it in, knows the structure, so it can pull it out
04:13.11brlcadthis isn't unique to .g in the least .. there's not a single format that doesn't have this issue and would need a similar 'fix'
04:14.22brlcadstep would be the closest to being a format that has in-memory structure for almost everything, but it's still NOT everything and you pay for the complexity
04:14.47brlcadcan see either working, though, easily enough (step or .g)
04:14.54starseeker's instinct is that the complexity might be worth paying for...
04:15.36brlcadwrite a complet g-step and say that again :)
04:16.23starseekerfair enough - but that gets back to trying to understand how to Do It Right - and explicit lists get long fast when we're talking about STEP
04:16.34``Erikd'no, starseeker... it's not our job to be a zomfg utility conversion toolkit... we do better than most already, but that's a hell of a calling
04:16.48brlcadit's not? :)
04:16.53starseeker``Erik: I'm not saying we need to be that overnight, but I'd like to architect so that we can grow into that
04:17.04brlcadwe do better than everyone at this point (open source)
04:17.37starseekerthinks the best way to get other interests on board is to position ourselves to do it better than ANYONE, closed or open
04:17.50brlcadmy thoughts were to leverage existing code as much as possible, because it really is a huge task once you involve more than a couple formats
04:18.38``Eriksome commercial packages do a very impressive job of importing and exporting, but they have tons of resources to throw at satisfying their customers
04:19.06brlcadtake the converters main() as they stand now, rewrite them so that stl-g's main is something like stl2g() but the g is opened as an in-mem db and a context is preserved
04:19.12starseekersure.  That's why it's so important we be able to grow incrementally, being clean from the start and gradually expanding our abilities
04:19.36brlcadrepeat for all formats, and you have a slew of conversion funcs from files to in-mem .g with very very minimal code change
04:19.40CIA-61BRL-CAD: 03bhinesley * r44773 10/brlcad/trunk/src/tclscripts/ (archer/Archer.tcl man_browser.tcl pkgIndex.tcl): Added the ManBrowser mega-widget (nonfunctional). This will eliminate code duplication of the Manual Page Browsers among Archer and MGED.
04:20.07``Erikmany conv/ files can be simplified by migrating them to the existing libgcv tesselation functions
04:20.08brlcadregister all of those funtions into a table in libgcv and bingo, universal converter
04:20.13starseekerbrlcad: My understanding was that we were going to have a lot of code changes anyway as we reduced the duplication of logic during the libgcv conversion
04:20.19``Eriktriangles are a good lcd
04:20.21brlcad``Erik: yeah they can....
04:20.26brlcadbut it's a royal pita
04:20.32brlcadi've tried a couple times
04:20.52``ErikI've made an attempt, as well :)
04:20.53brlcadalmost all of them have slight tweaks, write out different data at random points in the output, etc
04:21.48``ErikI threw in a generalized tesselation function into the new stuff I'm doing that'll return a full tree of BoTs, it might be the change we need to migrate
04:22.24brlcadstarseeker: ideally, but not necessarily .. reducing the code duplication there is not nearly as trivial as what I described
04:22.58brlcad``Erik: I saw .. by trying to tessellate from scratch with a different algo... good luck with that ;)
04:23.22brlcadeven if it works reliably, that's still 100k lines of code to refactor
04:23.31``Erikhave a working java example, surprisingly small
04:23.32brlcadeven if it reduces 10-fold, that's weeks of work
04:23.38``Eriknmg is just plain horrible
04:23.57brlcadbecause it guarantees topology
04:24.13brlcadwhat's the approach you're using do for that?
04:24.27``Erikthere's a trick in the latest approach that kinda surprises me, slicing all intersecting triangles before catagorizing
04:25.16``Erikthe original '86 paper has a whole chain of refinements, UnNBoolean seems to be the latest real example. I think the NMG stuff was originally based on that old '86 paper, then prematurely abstracted and implemented... poorly.
04:25.31brlcadthere's only three or four methods I'm aware of that preserve topology
04:26.10``Erikat the heart, this is still the same approach that nmg was supposed to be
04:26.54``Eriklee admitted that he didn't know what he was doing and screwed it up, daytona noted that too much information was thrown away at the beginning of the pass, ... *shrug* we'll see
04:27.00``Erikand I think my cat just farted at me
04:27.28brlcadnmg is the radial-edge method, there's winged-edge, half-edge, quad-edge, doubly linked faces, ..
04:28.37``Erikmost of those assume arbitrary polygons, i'm sticking to pure triangles
04:29.06brlcadI'm not defending nmg as much as saying it's hard to do it while still guaranteeing topology, preserving the manifold property
04:29.36``Erikhttp://unbboolean.sourceforge.net/
04:30.07``Eriks/N/B/
04:31.08louipchuh replace N with B?
04:31.33``Erikyeh, louis, I said unnboolean, shoulda been unbboolean :)
04:31.38brlcad``Erik: fwiw, the polyhedral paper they reference came *before* radial-edge
04:31.56``Erikerm, the portugeuse 2008 paper?
04:32.06louipcah cool
04:32.34louipcnew competitions?
04:32.46brlcadby a couple years
04:32.54brlcadhe states it: Constructive Solid Geometry for Polyhedral Objects, by D. H. Laidlaw, W. B. Trumbore, and J. F. Hughes
04:33.19``Erikthere's a chain of papers that go from 86 to 08
04:33.35brlcadthe portuguese paper he wrote :)
04:33.38CIA-61BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2908 10/wiki/User:Bhinesley: /* Log */ Yesterday, today, and plan for tomorrow.
04:34.21brlcadI have trumbore's paper around here somewhere
04:34.35brlcadit's decent, simple
04:35.08``Erik*grouse* pine frequently crashes on brlcad.org, and mutt won't even run. need to migrate
04:35.12brlcaddefinitely wouldn't declare the approach better (or worse)
04:35.59louipcwhat os?
04:36.00brlcadiirc, the method also attempts to preserve manifold, but fails for some n-manifold cases that radial solved
04:36.41brlcadradial solved the problem, but with complexity .. the failure in nmg isn't the method but the implementation
04:38.54``Erikthere seems to be a lot of success with the KISS deviation from what nmg tried, shouldn't take too long to implement and would bump up a couple 9's on success rate for real geometry
04:40.01``ErikI'll read up on radial edge, but the task as stated is pretty low investment
04:40.48brlcaddone again from scratch, I'd probably be looking at winged edge or radial
04:40.58brlcadthe bigger issue for CAD is the manifold property
04:41.48brlcadif something has three holes, it should preserve those three holes through conversion, not some other number .. or catastrophic for analysis, turn into a non-manifold
04:42.19brlcadthe latter is the biggest problem and the hardest to guarantee without structure
04:44.41``ErikI'd love to just use nurbs as the intermediary and focus effort now, but several people want visual tesselations to shove in ogl, that's what I'm working towards... not serious interrogation, just quick visualization
04:45.24brlcadexcept the very next thing they'll want is to dump that to something other than opengl and shoot rays at it, pretending it means something
04:45.29brlcadyou know it as well as I
04:47.32``Erikunfortunately, they'll try... so we call BoT's an approximation and push 'em towards nurbs
04:48.08``Eriktime for sleep, catch ya'll later :)
04:48.16brlcadhey, it's your seconds ticking by
04:48.21brlcadI just think it's a waste of time
04:49.34brlcadand I'll annongly keep saying it .. we should be focusing on robust solid modeling and geometry managemenet
04:50.06brlcadanything else is outside our domain, a distraction, wasted divergent resources and wasted effort
04:50.59``Erikdude, I agree... I tried to pitch putting my funded time to nurbs... but was told I had to have improved tesselation by the end of the fy, it's on my objectives, need something for accomplishments in late sept... :/ process is screwing product yet again
04:51.51louipcI'd say UI is the most important at this point :P
04:51.55brlcadso give them g-egg ;)
04:52.07brlcadlouipc: it is to the community at large
04:52.31``Erikthey were trying to put me on tweaking marching cubes, which is simply wrong for our kind of geometry, so I think I managed a small victory in changing that direction
04:52.37brlcadbut not to the elephant contributor that pays to get what they think is most important :)
04:52.53louipchehe
04:53.07louipcname the price ;)
04:53.54``Erikafter all the overhead (equipment, facilities, mgmt, support staff), I think it's in the neighborhood of 240000usd/year
04:54.01brlcadlouipc: nominally, http://www.ohloh.net/p/brlcad/estimated_cost
04:54.58brlcadheh, that's probably missing a digit
04:55.22louipcwaow
04:55.59brlcador did you mean per year per person
04:56.13``Erikdisturbingly, I'm pretty sure that the failbomb upstairs has already cost more than all of BRL-CAD
04:56.17``ErikI meant per person per year
04:57.28``Erikso yeh, sleep. hasta la pasta
04:57.43louipcnite
04:57.50brlcadstill thinks the easiest path forward is unit testing libbn then libnmg, evaluating robust up the call hierarchy
04:57.56brlcadcheers
05:02.36CIA-61BRL-CAD: 03brlcad * r44774 10/brlcad/trunk/NEWS: cliff and erik developed a tcl/tk version of isst made available through the cmake build for 64-bit platforms. recommit for docs.
05:02.59brlcadstarseeker: did you see the bug report about the bindings?
05:03.25brlcadsaid both mouse buttons now zoom out, probably related to "zoom out keybinding fixed on Linux/*BSD" made prior to release
05:05.26CIA-61BRL-CAD: 03brlcad * r44775 10/brlcad/trunk/NEWS:
05:05.26CIA-61BRL-CAD: cliff fixed the zoom-out mouse binding on linux/bsd that probably stopped
05:05.26CIA-61BRL-CAD: working after I made a fix for Mac bindings. problem may need revisiting,
05:05.26CIA-61BRL-CAD: though, becuase there's already a report that both left/right mouse now zoom out
05:05.26CIA-61BRL-CAD: for some platform.
05:08.45CIA-61BRL-CAD: 03brlcad * r44776 10/brlcad/trunk/BUGS: both mouse buttons zoom in now on some common platform
05:10.25CIA-61BRL-CAD: 03brlcad * r44777 10/brlcad/trunk/NEWS: cliff improved the mged 'search' command so you can specify multiple paths now and it will report them appropriately. recommit for docs.
05:13.46CIA-61BRL-CAD: 03brlcad * r44778 10/brlcad/trunk/NEWS: richard reportedly fixed a segment splitting bug that would affect all tessellation and polygonal conversions. recommit for docs.
05:15.14CIA-61BRL-CAD: 03brlcad * r44779 10/brlcad/trunk/NEWS: richard fixed a crash that was occuring during facetization/conversion of large models. bad book keeping? recommit for docs.
05:18.03CIA-61BRL-CAD: 03brlcad * r44780 10/brlcad/trunk/NEWS: bob fixed a bug introduced in asc2g where the new standard attribute logic was causing the color tables and other attribute data to not get converted properly. recommit for docs.
05:20.41brlcadstarseeker: "improve path resolution logic for search paths" means what?
05:22.01CIA-61BRL-CAD: 03brlcad * r44781 10/brlcad/trunk/NEWS: remove items that weren't user-visible. annotate is not yet 'published', attribute standardization is all under the hood, libtie was already announced in 7.18.4
05:23.18CIA-61BRL-CAD: 03brlcad * r44782 10/brlcad/trunk/NEWS: cliff added a -q quiet lookup option tot he ls command so that the lookup failure message can be suppressed (particularly important for scripting)
05:28.00CIA-61BRL-CAD: 03brlcad * r44783 10/brlcad/trunk/NEWS: multiple names separated by commas for parsing, using past tense
05:33.05CIA-61BRL-CAD: 03brlcad * r44784 10/brlcad/trunk/NEWS:
05:33.05CIA-61BRL-CAD: cliff and I addressed numerous stability and robustness issues in the red
05:33.05CIA-61BRL-CAD: command. now should handle standard attributes more consistently, be robust to
05:33.05CIA-61BRL-CAD: bogus user input, be robust to empty/null input, and correctly preserve values
05:33.06CIA-61BRL-CAD: creating a copy if the name is changed.
05:40.01CIA-61BRL-CAD: 03brlcad * r44785 10/brlcad/trunk/NEWS: (log message trimmed)
05:40.02CIA-61BRL-CAD: previously undocumented keith's modification because the change wasn't expected
05:40.02CIA-61BRL-CAD: to be user-visible, but it turns out it was (for pixel accurate grazing
05:40.02CIA-61BRL-CAD: selection), so credit us both for changing the spatial partition traversal
05:40.02CIA-61BRL-CAD: ordering. keith originally fixed a traversal 'bug' where it was walking cut
05:40.02CIA-61BRL-CAD: planes something like XYXYXYXYX (missing Z). he changed it to traverse
05:40.03CIA-61BRL-CAD: YZXYZXYZX, but that caused a different cell to get selected first and
05:44.07CIA-61BRL-CAD: 03brlcad * r44786 10/brlcad/trunk/NEWS:
05:44.07CIA-61BRL-CAD: I added a LIBRT_BOT_MINTIE environment variable override that lets the user
05:44.07CIA-61BRL-CAD: specify at what level libtie is used to evaluate a bot. lets you override
05:44.07CIA-61BRL-CAD: during database loads affecting subsequent raytrace calls (better suited to
05:44.07CIA-61BRL-CAD: repeat single-ray shots ala muves).
05:46.00CIA-61BRL-CAD: 03brlcad * r44787 10/brlcad/trunk/NEWS: cliff changed the search output order to list shallow items prior to deeply nested items.
05:48.20CIA-61BRL-CAD: 03brlcad * r44788 10/brlcad/trunk/NEWS: cliff extended search's power by adding support for '.' relative path search results where object lists are returned instead of full paths
05:52.34CIA-61BRL-CAD: 03brlcad * r44789 10/brlcad/trunk/NEWS:
05:52.35CIA-61BRL-CAD: I added a -f flag to the red command to force overwriting any existing
05:52.35CIA-61BRL-CAD: combinations. if you run red, change the object name while editing, yet that
05:52.35CIA-61BRL-CAD: new name already exists, it will abort. with the -f flag, it will overwrite.
05:56.21CIA-61BRL-CAD: 03brlcad * r44790 10/brlcad/trunk/NEWS: technically, many of our items are verbless clauses as the action verb is implied (usually 'added').
05:58.43CIA-61BRL-CAD: 03brlcad * r44791 10/brlcad/trunk/src/tclscripts/ (CMakeLists.txt Makefile.am): add the new man_browser.tcl file to the dist
06:15.46CIA-61BRL-CAD: 03brlcad * r44792 10/brlcad/trunk/NEWS: reword the intro description with details about the new cmake build and additional reasoning for the migration.
07:30.11*** join/#brlcad Stattrav (~Stattrav@117.202.24.91)
07:30.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:08.49*** join/#brlcad ibot (~ibot@rikers.org)
08:08.49*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
08:22.01*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
09:17.57*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
09:17.57*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:37.38starseekerbrlcad: the search path thing is the whole "make sense out of .././.././" type paths
11:38.13starseekerthere's another new zoom bug?  I thought the only zoom bug was the one introduced by the mac keybinding change
11:54.07starseekerthat report was 7.18.4 - I think thats the mac thing
11:54.28starseekerwill check later
12:03.50CIA-61BRL-CAD: 03davidloman * r44793 10/geomcore/trunk/: Add /Debug to svn:ignore (Build byproduct)
12:06.30CIA-61BRL-CAD: 03davidloman * r44794 10/geomcore/trunk/src/interfaces/java/: Add /bin to svn:ignore (Build byproduct)
12:45.19kunigami_hi, do I already have an SVN account for commit? If so, which is my password?
12:49.49``Erikit's your sourceforge account
12:50.15``Erikyou should have uploaded ssh keys
12:51.28kunigami_hmm how do I do that?
12:53.36``Eriklog into the web page at sourceforge, click account at the top right, click services, click edit ssh keys
12:54.29``Erikhttps://sourceforge.net/apps/trac/sourceforge/wiki/Subversion  is the help page for all of that
12:55.02``Erik(might be able to do https with your sf password, but I think ssh is the recommended route)
12:59.28kunigami_thank you! I seems that there may be a delay when updating the ssh-keys. I still don't have acess, so I'll wait a bit
13:03.39brlcadstarseeker: I must have missed that the report was for 7.18.4
13:03.55brlcadthat would be more promising, I'll follow up
13:04.23brlcadkunigami_: your sf.net username/password should work just fine too
13:05.17kunigami_I'm getting the following error:
13:05.20kunigami_svn: Commit blocked by pre-commit hook (exit code 1) with output:
13:06.01kunigami_<PROTECTED>
13:06.32kunigami_brlcad/trunk/include/osl-renderer.h : svn:mime-type is not set
13:07.09``Erikyou have to do a propset, it should tell you exactly what to do in the error msg
13:07.39kunigami_oops. you're right. sorry for that
13:08.57``Erikhttp://brlcad.org/wiki/Cvs2svn has an example autoprop file to avoid that in the future
13:13.26CIA-61BRL-CAD: 03Paydayway 07http://brlcad.org * r2909 10/wiki/Forex_Trading-_How_To_Understand_FOREX_Market_Sentiment: New page: Investors can trade almost any currency in the world. Investors, as individuals, countries, and corporations, may trade in the forex if they have enough financial capital to get started an...
13:13.55CIA-61BRL-CAD: 03kunigami * r44795 10/brlcad/trunk/ (6 files in 2 dirs): This is my first commit. It adds a ols shader as well as a osl-renderer which by now just sets a color
13:14.12``Erikw00t, grats
13:14.27kunigami_yay! cool!
13:25.39brlcadwoohoo
13:27.10CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/protect: protected "[[Forex Trading- How To Understand FOREX Market Sentiment]]": [edit=sysop:move=sysop]
13:27.22CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
13:27.22CIA-61BRL-CAD: deleted "[[Forex Trading- How To Understand FOREX Market Sentiment]]": content
13:27.22CIA-61BRL-CAD: was: 'Investors can trade almost any currency in the world. Investors, as
13:27.22CIA-61BRL-CAD: individuals, countries, and corporations, may trade in the forex if they have
13:27.22CIA-61BRL-CAD: enou...' (and the only contributor was
13:27.22CIA-61BRL-CAD: '[[Special:Contributions/Paydayway|Paydayway]]')
13:27.45CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Paydayway]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
13:47.39``Erikbrlcad: is sf backend 1.5 now?
13:48.04brlcadkunigami_: http://brlcad.org/wiki/Mime-types
13:48.27brlcad``Erik: I haven't migrated it, so unless they did for us, probably not
13:48.39brlcadcould be something to work on today
13:49.03CIA-61BRL-CAD: 03kunigami * r44796 10/brlcad/trunk/ (4 files in 2 dirs): Changed .c to .cpp and now I'm exporting the osl-renderer functions so that C code can call them
13:54.25CIA-61BRL-CAD: 03erikgreenwald * r44797 10/brlcad/trunk/TODO: Remove the LIBRT_BOT_MINTIE task. Bump bottie crash and repo backend to next release.
14:21.43brlcadwoot, another logo submission
14:35.45CIA-61BRL-CAD: 03brlcad * r44798 10/brlcad/trunk/NEWS:
14:35.45CIA-61BRL-CAD: in retrospect, my addition of the LIBRT_BOT_MINTIE variable was during prep,
14:35.45CIA-61BRL-CAD: which erik replaced with override during database load, so credit him on the
14:35.45CIA-61BRL-CAD: change that toggles tie BoT raytrace optimization on/off as an environment
14:35.45CIA-61BRL-CAD: variable override.
16:03.55CIA-61BRL-CAD: 03tbrowder2 * r44799 10/brlcad/trunk/NEWS: correct spelling
17:02.52*** join/#brlcad Stattrav (~Stattrav@117.192.154.39)
17:02.52*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:21.43kunigami_a question regarding the macro BRLCAD_ADDLIB(libname srcs libs)
17:22.25kunigami_when I pass libs as "abc.dylib;def.dylib" is does not call target_link_libraries
17:23.07kunigami_but when I pass libs as "abc.dylib def.dylib", that is, replacing ";" for " " , it does call target_link_libraries
17:23.55kunigami_that's strange because there's a replacement: STRING(REGEX REPLACE " " ";" libslist1 "${libs}") right on the beginning of the macro
17:33.02CIA-61BRL-CAD: 03tbrowder2 * r44800 10/brlcad/trunk/doc/README.Linux: correct relative path typo for 32-bit configuration
18:33.38brlcadthat wasn't a question :)
18:36.27kunigami_hehe, let me complete :) Is that true or am I missing something?
18:39.48brlcad'yes'
18:40.08brlcadthose aren't mutually exclusive options ;)
18:40.17brlcadthat said, sounds like a starseeker question
18:52.00CIA-61BRL-CAD: 03kunigami * r44801 10/brlcad/trunk/ (5 files in 2 dirs): Moved osl-renderer.h from /include to /src/liboptical. there's no need to such headers to be public
18:55.11brlcad~kunigami++
18:55.20brlcadwas going to comment on that yesterday
18:56.11brlcadyou should also change the #include to be a relative path reference so it's "private" status is clear (e.g., #include "./osl-renderer.h")
18:56.33kunigami_ok!
18:56.57brlcadkunigami_: have you been able to make a (brl-cad) shader do anything yet?
18:58.15kunigami_I made the polka dot shader: http://kuniga.files.wordpress.com/2021/05/goblet1.png it's very ugly, but I think I got the idea
19:30.12starseeker``Erik: were you refering to the kernel module loading process? (kldload and friends?)
20:10.56*** join/#brlcad ibot (~ibot@rikers.org)
20:10.56*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
20:11.32``Erikgets some popcorn
20:13.04starseekerbrlcad: I guess it comes down to what we consider immediate needs to be
20:13.15brlcadif dynamic loading becomes desirable, that can be added *very easily* using any number of methods
20:13.47brlcadso what is the immediate need? what is dynamic loading fixing?
20:13.54brlcad(again, forget step-g for a minute)
20:14.40starseekerfor me the immediate question is "can we design an API/library that can expand to handle arbitrary geometry files"
20:15.47starseekerstep-g aside, it's quite clear there are an awesome number of object times we *potentially* will want/need to convert
20:15.50brlcadcase in point .. you can design an *API* to handle arbitrary geometry files with or without dynamic
20:16.07starseekers/times/types
20:16.46starseekerif the api design can be considered fully independent of the implementation, we can start with the api - I wasn't sure that was a practical reality
20:16.48brlcadright, and if it's going to be "arbitrary", you don't even really know what all the types are
20:17.24starseekerright.  which is why flexible and general mechanisms for expanding what types the library can handle are so important
20:17.38brlcadright
20:17.40brlcadbut mind you, the API is agnostic to the implementation
20:18.10brlcadthe library *architecture* is not necessarily agnostic, as that's basically the implementation detail nuts and bolts
20:18.34brlcadbut if you don't have the API nailed down yet, you don't really have a grasp on requirements to be designing architecture anyways
20:18.51brlcadwhereas you can easily come up with an architecture that might mess up your API
20:19.08brlcadhorse -> cart ;)
20:20.09starseekerwas worried that the issue with Factory classes and C++ (which is by no means unique to step-g) meant that a good mechanism for generality might be problematic
20:20.43starseekerhence my interest in learning enough about the approaches to implementing that generality to be sure it wasn't a complete and total blind alley
20:21.13brlcadsure, but that's where a lil knowledge is leading to fear .. there are hundreds of other proof-positive implementations of factories and c++ that do this just fine
20:21.33brlcadand of dynamic loading and of scripted loading and of network loading .... etc
20:23.00starseekerbrlcad: the existence of the Apache mod system I guess I can accept as proof that it can be done
20:23.12brlcadif you really want to make it type AWARE and type extensible, that will definitely affect the API
20:23.31brlcadjust about every single commercial game loads data modularly ;)
20:23.43starseekeruh... don't we want it to be type aware?
20:23.44brlcadheck, even liboptical does it .. we just don't have any
20:24.15brlcadI haven't thought about an API too much yet (which is really what's needed first), but my inclination would be no
20:24.26starseekerO.o
20:24.31brlcadthere are too many entity types, and there will always be some entity type you don't recognize
20:24.44brlcadbasically akin to keeping it as a typeless system
20:24.57starseekerso we handle the ones we do recognize, and gracefully fail on the ones we don't
20:25.02brlcadinteractors know what they can interact with (and they are types in themselves)
20:25.29brlcadeach geometry format module can handle the ones they recognize
20:25.50brlcadwe have some abstract way for registering annotated  "data"
20:27.00starseekerI guess what I need to do is lay out my notion of an API
20:27.06starseekermaybe that'll clarify it for me
20:27.08brlcadyeah
20:27.54brlcadtry to write the public header, or a main() that shows how the API might be used in simple terms
20:28.18starseekerat this point I don't agree that it should be typeless, so I guess I need to run head-first into why it should be
20:28.26brlcadthere you answer questions like, do you allow iterating over individual objects
20:28.28starseekernods - will do
20:28.40brlcadhow to deal with hierarchy information
20:28.45brlcadwhat to do with metadata, etc
20:29.00brlcad"typeless" is being used very loosely here
20:29.45brlcadtypeless in the language sense .. if it were C, there wouldn't be a sphere struct; if c++, there would not be a sphere class .. that's what I mean by typeless
20:30.17starseekeryeah... I'm not seeing that, but let me play with the API thing for a day or two and I'll see
20:30.18brlcadthere'd be some bundle data saying "I'm a sphere and I have these parameters and these values"
20:31.36brlcadit's the difference between librt reading objects off disk and knowing "this is a sphere entity with some data" and having an actual rt_ell_internal object with sphere data in it
20:32.05brlcadthe latter is going to be a veritable hell for a conversion library, and I'd argue probably unnecessary
20:32.42starseekerwell, let me crunch on it
20:32.48brlcadit'd just make the library way more complex when you can perform the same work, turn that sph into a set of polygons and write out stl *without* an rt_ell_internal in memory
20:33.00starseekerhow?
20:33.26brlcadjust like how librt does it now
20:34.04starseekeruh... don't the tessellation routines need to know the details of the sphere?
20:34.51brlcadyep
20:35.01brlcadthey don't necessarily need an rt_ell_internal though
20:36.11brlcaddata-driven object-oriented design
20:36.31brlcadI think one of my game programming gems has a relevant article, I'll see if I can dig it up
20:37.33starseekernods - that might be helpful
20:37.47starseekerI'll try and cook up an API
20:40.35CIA-61BRL-CAD: 03erikgreenwald * r44805 10/brlcad/trunk/ (6 files in 4 dirs): add/use dlfcn wrapper
20:43.57CIA-61BRL-CAD: 03erikgreenwald * r44806 10/brlcad/trunk/src/liboptical/material.c: remove the HAVE_DLOPEN stuff, since that's handle in bu now
20:45.36CIA-61BRL-CAD: 03erikgreenwald * r44807 10/brlcad/trunk/src/liboptical/sh_stack.c: more HAVE_DLOPEN removal
20:48.10brlcadstarseeker: if you haven't yet, I'd suggest looking briefly into both liboptical and librt, how they deal with extensible types
20:49.02brlcadnot what I'd suggest going with for gcv, but they are about as simple as it gets, scalable to hundreds of entities, and should be understood (how their types relate to the *API*)
20:59.36CIA-61BRL-CAD: 03erikgreenwald * r44808 10/brlcad/trunk/src/libbu/dlfcn.c: take a whack at porting these functions to windows
21:07.32CIA-61BRL-CAD: 03erikgreenwald * r44809 10/brlcad/trunk/include/bu.h: add dlfcn.h for RTLD_*
21:26.21starseekerhah, cool:  http://deviceguru.com/worlds-first-open-source-flashlight/
21:27.40kunigami_I'm getting compilation error for material.c -- ‘RTLD_NOW’ undeclared.
21:28.08kunigami_I'll check later, but that could have been introduced by r44806
21:28.18kunigami_I'm off by today
21:28.23``Erikwhich os?
21:28.28kunigami_mac os
21:28.53``Erikthat'd be the one fixed in 44809 :)
21:29.54kunigami_oops sorry. I did update from src/ dir
21:31.19*** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br)
21:52.11*** join/#brlcad crazy_imp (~mj@a89-182-166-16.net-htp.de)
21:52.46CIA-61BRL-CAD: 03erikgreenwald * r44810 10/brlcad/trunk/src/ (10 files in 5 dirs): Apple includes stdbool.h in dlfcn.h, so change our various typedefs of bool to their actual type.
22:47.11*** join/#brlcad DarkCalf (DC@173.231.40.98)
23:01.17``Erikaw man, I can't compete in the logo contest? shucks
23:12.13CIA-61BRL-CAD: 03erikgreenwald * r44811 10/brlcad/trunk/AUTHORS: Keith and Richard probably qualify as developers instead of contributors at this point.
23:30.52*** join/#brlcad piksi (piksi@pi-xi.net)
IRC log for #brlcad on 20110608

IRC log for #brlcad on 20110608

00:26.19*** join/#brlcad crazy_imp (~mj@a89-182-241-223.net-htp.de)
00:48.16louipcdo I count as a dev? could I compete in the contest? hehe
01:06.32CIA-61BRL-CAD: 03bhinesley * r44812 10/brlcad/trunk/src/tclscripts/man_browser.tcl:
01:06.32CIA-61BRL-CAD: Changed ManBrowser mega-widget to inherit from iwidgits::dialog. It now creates
01:06.32CIA-61BRL-CAD: the window properly, activates, loads the table of contents and
01:06.32CIA-61BRL-CAD: Introduction.html. Selection binding of the ToC is not working yet. Still some
01:06.33CIA-61BRL-CAD: cleanup to do.
02:11.29*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
02:11.39*** join/#brlcad yiyus (1242712427@je.je.je)
02:35.49brlcad``Erik: no complaints for those two as they're "close enough" but they were still under the measure I've used for others in the list, fwiw
02:39.26brlcadnot a hard steadfast rule of course since it's easily fudged, but a couple hundred "significant" commits on the core code for several months sustained is the general rule of thumb
02:40.31brlcadcourse, with those two in particular, if they were committing properly, they probably would have hit that metric by now
03:55.25``Erikboth are lean on frequency, but indianlarry has provided significant value, and the other needs help to grow beyond old waterfall
03:55.50brlcadcertainly
03:56.27``Erikif you wanna tweak, go for it, I just felt like those two deemed shift
03:56.40brlcadnah, like I said.. they're close enough to the metric I was using
03:57.27brlcadvalue isn't the metric, though .. a big honkin' awesome 100k patch that makes mged totally awesome would not make one a dev ;)
03:57.36``Erikaight, then shove your passive aggresiveness :D
03:57.39brlcadmore sustained value .. which he has cetainly demonstrated
03:57.53brlcadisn't being passive aggressive
03:58.35``Erikboth need to be more frequent in commits, and I will continue to harangue them
03:58.45brlcadmore cautious that we start adding borderline folks, shifting the gray area lower and lower instead of waiting until it's a "well duh they're a dev"
03:58.53brlcadyay
03:59.26``Erikso how's tesa? missing the idea of sleep yet? ;)
03:59.27brlcadhey even the latter did pretty well with that I noticed.. have a dozen or so major commits to review in my queue
04:00.02brlcadI haven't gotten this much sleep since .. high school
04:00.47``Erikmight wanna reconsider that answer, cuz I'll loan jill a kuhknifh to stab you with ;> *duck*
04:02.01brlcaddefinitely more interruptions, but nothing so drastic .. lots of drama queens and kings making a big deal out of nothing :)
04:02.25``Erikaaaanyhow, as youv'e stated, a commit is a statement that can be argued
04:02.50brlcadyeah, it's all good
04:02.56``Erikhalf surprised you haven't chimed in on my dlfcn.c tweak
04:03.12brlcadbigger issue is there are a few names on there now that probably don't belong but got grandfathered in
04:03.26brlcadat least with that same metric, but then different times too
04:03.38brlcaddlfcn looked cool, what of it?
04:05.14``Erikgiven your discussion with starseeker about dynamically loaded stuff at the time, I imagined... constertation. It's viable given the liboptical and librender dependancies, ... just imagined a bit of fireworks :)
04:05.15brlcadkinda lame failure case (i.e., print "boo hoo") but simple enough to be portable and useful
04:05.45brlcadI don't rant on everything you know :)
04:05.48brlcadsometimes it's all good
04:06.15brlcadso you can't unload a lib on windows?
04:06.35brlcadearly osx 10.0 had that same fail
04:06.37``Erikusually... figured this might stir ya up... no, could not find an unload on winderz
04:07.20brlcadit was a perfect refactor case to boot
04:07.23``Erikmsdn's "see also" had no unload stuff
04:07.33brlcadnon-portable code in two places, refactored to one and made portable
04:07.51``Erikmore than 2
04:07.59brlcadthree?
04:08.05brlcadliboptical, render, and ?
04:08.07``Erik4, I think
04:08.14``Erikoptical, render, fb, fbed
04:08.31brlcadah, wasn't aware of the latter to (and didn't notice in the commit)
04:08.36brlcad*two*
04:08.46brlcadthat's really stupid for fbed
04:09.09brlcadwtf is fbed dynamically loading?
04:09.21``Erikgrep it.
04:10.24``Erikor svn diff... you know what to do.
04:11.00brlcadI don't care that much
04:11.40brlcadI had a mail queue over 1000 to work through, if I spent that much time per issue, it'd take months
04:13.19brlcadso curiousity got me, see that it's linking -ldl, but no dl*() function being called .. just bool issue in your commit
04:14.14brlcader, I take it back, not linking -ldl
04:19.50brlcadmeh, doesn't look like it's dynamically loading to me, but no matter
04:40.34*** join/#brlcad ibot (~ibot@rikers.org)
04:40.35*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
05:33.38*** join/#brlcad ibot (~ibot@rikers.org)
05:33.39*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
07:05.43*** join/#brlcad Stattrav (~Stattrav@122.167.241.15)
07:05.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:23.26*** join/#brlcad Stattrav (~Stattrav@122.167.241.15)
07:23.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:49.11*** join/#brlcad piksi (piksi@pi-xi.net)
09:50.08*** join/#brlcad Stattrav (~Stattrav@122.167.241.15)
09:50.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:12.02*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:32.10``Erikbrlcad: liboptical and adrt/librender do dynamic loading, but the inclusion of dlfcn.h pulled in stdbool on osX, which caused fbed, fb, and a few others to flip out where we had our own bool defined, so the change cascaded. I'm half thinking of removing dlfcn.h from bu.h, defining our own RTLD_* variables and making a translation table in bu_dlopen(). :/
11:40.40``Erikvmath.h is a link dep? I thought it was purely macro and typedef O.o
11:44.54``Erikyeh, I see no function or global in vmath, it shouldn't be a lib dep
11:46.24``Erikah, bunk commit message, it's just more digits on the arse end of M_PI
11:58.07dlomanwoot!!! Powers back on :)
12:58.01CIA-61BRL-CAD: 03brlcad * r44817 10/brlcad/trunk/src/libged/combmem.c: HINIT_ZERO instead of VSETALLN() for simplicity
13:03.11CIA-61BRL-CAD: 03brlcad * r44818 10/brlcad/trunk/doc/deprecation.txt: annotate the recently obsolete items with their entity. time to consider the vmath length constants obsolete too.
13:04.22CIA-61BRL-CAD: 03brlcad * r44819 10/brlcad/trunk/include/vmath.h: remove ELEMENTS_PER_PT, HVECT_LEN, and HPT_LEN in favor of their more consistent replacements that were added deprecating these in 7.12
13:05.32CIA-61BRL-CAD: 03brlcad * r44820 10/brlcad/trunk/Makefile.am: one of the last times the trailing slash issue will make an appearance..
13:39.02CIA-61BRL-CAD: 03erikgreenwald * r44821 10/brlcad/trunk/TODO: multiple configuration cmake builds seem to be ok, so strike it. Add the OSX GL/X segfault to things to fix.
13:40.20CIA-61BRL-CAD: 03brlcad * r44822 10/brlcad/trunk/ (14 files in 6 dirs): remove template comments and unused doxygen file blocks
13:40.24CIA-61BRL-CAD: 03erikgreenwald * r44823 10/brlcad/trunk/NEWS: note that cmake files will now be included in dist.
13:41.06brlcad``Erik: yeah, i knew about the bools in fbed and elsewhere
13:41.29brlcadthey were on my hit list to eliminate next time stomping through those files
13:42.35brlcadwhen I said non-portable code in two places, I meant non-portable dynamic loading in two places, refactored to one
13:42.42brlcadthat was the awesome goodness
13:49.53``Erikaight, I don't have a test case to see if my bu_dl* winderz stuff works, do you?
17:08.34dlomanCommunity 'paintball episode' :  http://www.youtube.com/watch?v=ivLmfGK6pj4
17:08.54dlomanCommunity 'D&D Episode' : http://www.youtube.com/watch?v=cVanRXdlfLA
17:25.30``Erikringworld anim: http://www.youtube.com/watch?v=sR2296df-bc
17:48.22*** join/#brlcad Stattrav (~Stattrav@122.167.241.15)
17:48.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:45.17CIA-61BRL-CAD: 03bhinesley * r44824 10/brlcad/trunk/src/tclscripts/man_browser.tcl: Fixed ManBrowser mouse binding. The dialog itself is back to business as usual. Now, to fix internal ToC selection (ex: set archerMan [ManBrowser .archerMan]; archerMan configure -selection )...
18:46.01bhinesleybah... didn't escape \$cmdName
18:51.40CIA-61BRL-CAD: 03kunigami * r44825 10/brlcad/trunk/src/liboptical/ (osl-renderer.cpp osl-renderer.h sh_osl.c): Added support for OSL closure color query. It's crashing though. Maybe due to a memory leak
19:10.47CIA-61BRL-CAD: 03bhinesley * r44826 10/brlcad/trunk/src/tclscripts/man_browser.tcl: ManBrowser internal ToC selection is working, although a bit differently than originally planned: [ select ls].
19:11.03bhinesleysmacks head
19:11.51bhinesleyforgot to escape again
19:20.26brlcad``Erik: I do, but don't have a windows box to test it on ;)
20:21.02*** join/#brlcad mafm (~mafm@19.Red-83-40-127.dynamicIP.rima-tde.net)
20:51.39CIA-61BRL-CAD: 03kunigami * r44827 10/brlcad/trunk/misc/CMake/FindOSL.cmake: Just realized that I did not added OSL finder for cmake
21:03.11CIA-61BRL-CAD: 03erikgreenwald * r44828 10/brlcad/trunk/misc/Makefile.am: add FindOSL.cmake to the dist list
21:21.38brlcadkunigami_: vmath macros ftw
21:21.59brlcadyou used them in at least one place, but there looked like other places you can put them to use to reduce code
21:23.37kunigami_brlcad: ok. I was thinking to refactor the code after making it work
21:26.01CIA-61BRL-CAD: 03kunigami * r44829 10/brlcad/trunk/misc/CMake/ (FindOIIO.cmake FindOSL.cmake FindOpenEXR.cmake FindTBB.cmake): added three more cmake finders. Also edited Makefile.am this time
21:26.39CIA-61BRL-CAD: 03kunigami * r44830 10/brlcad/trunk/misc/Makefile.am: ... Also edited Makefile.am this time
21:28.42CIA-61BRL-CAD: 03kunigami * r44831 10/brlcad/trunk/misc/CMake/util_macros.cmake: This was borrowed from OSL build system. TODO: merge it with BRLCAD util
21:33.38brlcadnods
21:40.18CIA-61BRL-CAD: 03brlcad * r44832 10/brlcad/trunk/src/liboptical/ (osl-renderer.cpp osl-renderer.h): untested (don't have osl/oiio/boost installed), but should work just fine to use VMOVE for Vec3's too if [] is defined.
21:41.06brlcadthat should work, lemme know if it barks
21:42.31brlcadfew other code completeness issues, file formatting should match existing style and structure
21:43.35brlcadif you run sh/template.sh on all new files, it'll add the proper header and footer to those files
21:44.08brlcadafterwards, you should similarly be able to run sh/indent.sh and sh/ws.sh to clean up the style
21:45.45brlcadyou'll find me harping a lot about maintaining consistent style all the time ... codebases this size require it  ;)
21:48.15brlcadalso, looks like render_svc file(s) are missing
21:49.55CIA-61BRL-CAD: 03brlcad * r44833 10/brlcad/trunk/src/liboptical/Makefile.am:
21:49.56CIA-61BRL-CAD: any new files have to get added to both CMakeLists.txt and Makefile.am for the
21:49.56CIA-61BRL-CAD: time being while the build system is in transition. at a minimum, list files in
21:49.56CIA-61BRL-CAD: EXTRA_DIST in the Makefile.am and proper logic in the cmake build.
21:51.21CIA-61BRL-CAD: 03brlcad * r44834 10/brlcad/trunk/src/liboptical/CMakeLists.txt: render_svc.cpp apparently wasn't added, remove from compile rules
21:51.55brlcadbhinesley: question from one of the archer devs about closedb -- what happens after the db is closed?  is another temp db created?
21:52.34brlcadit's of his opinion that it should put archer back into a state like when it was first started with an empty unsaved db
21:52.48bhinesleythat's what happens
21:52.53bhinesleyI haven't commited that patch yet, though
21:52.56brlcadcool
21:53.06brlcadhe was just asking about it today
21:53.21brlcadhadn't looked at the patch yet
21:54.14bhinesleyI'm planning on re-reviewing them all and committing sometime this week, if that's alright
21:57.28brlcadsounds perfect
22:01.15brlcadkunigami: is there some technical reason that -Wno-error -no-pedantic were set on the the osl render files?
22:27.30*** join/#brlcad Stattrav (~Stattrav@117.192.155.178)
22:27.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:29.15CIA-61BRL-CAD: 03bhinesley * r44835 10/brlcad/trunk/src/tclscripts/ (archer/Archer.tcl man_browser.tcl): (log message trimmed)
22:29.15CIA-61BRL-CAD: ManBrowser is now ready to be used by Archer and MGED
22:29.15CIA-61BRL-CAD: Added -disabledPages and -enabledPages to give more control over which commands are displayed.
22:29.15CIA-61BRL-CAD: Configured constructor to call configbody's with blank args if user didn't configure public variables, in order to trigger defaults.
22:29.16CIA-61BRL-CAD: Removed \"get\" method, as it doesn't appear to be necessary the way things are done now.
22:29.16CIA-61BRL-CAD: Renamed cmd/commands etc. variable name components to page/pages, since they're not necessarily commands (ex: Introduction.html).
22:29.17CIA-61BRL-CAD: Changed regex uses to \[file\] commands.
22:32.37bhinesleyThere is an -enabledPages option for ManBrowser, which I'd like to populate with a list of commands that are actually available in Archer. Is there a preferred method of getting such a list?
22:33.05bhinesleyactually, while we're at it, I'd like to do the same thing for MGED
22:38.19brlcadthe best way to do that consistently / maintainably is via libged
22:39.07brlcadthere are ways to get the lists via tcl for both, but it's two different ways and would rather suck from an architecture standpoint
22:39.33brlcadlibged needs a way to keep a registry of all commands available
22:40.31brlcadhave each command register themselves, so when you query, you get the list
22:40.49brlcadwould also let you build up built-in commands like 'help' that need access to all commands
22:41.43bhinesleyhmm
22:43.13bhinesleyI'll look into this
22:44.01bhinesleyI was kinda hoping you were going to say "Yes! Here's a variable with the exact list you need!"
22:44.08bhinesley:-P
22:46.18brlcadhaha
22:47.14brlcadit's one of the design goals for libged anyways, so might as well work on it now where it's needed
22:47.52brlcadit's also critical for one of the most powerful features on our to-do list, search -exec
22:48.02brlcadmajor win
22:48.44bhinesleySounds great. I'm basically set for my first milestone, so I definitely have the time.
22:50.04brlcadif you're making progress on core dev issues like that one, then you're golden :)
22:50.53brlcadeven if you spent all summer "getting it perfect" and the milestones went out the window ;)
22:51.19bhinesleygood to know
22:51.36brlcadmore important that you're having fun and maintainable progress is being made
22:52.44brlcadI can work on stubbing out a basic plugin framework this week if that's next on your plate unless you have some ideas on an approach as well
22:54.26bhinesleyit is, and I don't
22:56.16brlcadthe design constraints are pretty simple, want to move towards libged being an event-driven modular plugin system, so you'd define a command (e.g., kill) that performs some action (e.g., validates and records delete events); that command is registered with the library (e.g., adds a callback struct to a command array)
22:59.10brlcadthe library can then call into any registered command, or iterate over all registered commands and get information (e.g., call a ged_short_help() callback for the 'help' command) and so on
23:00.58bhinesleymuch easier to keep track of
23:03.43bhinesley"search -exec", like unix "find -exec" I take it
23:03.55bhinesleyto run operations on the results
23:05.53CIA-61BRL-CAD: 03brlcad * r44836 10/brlcad/trunk/include/nmg.h: fill in the remaining available debug bits
23:05.54brlcadexactly
23:06.53CIA-61BRL-CAD: 03Quattvendypol 07http://compilefarm.org * r2911 10/wiki/Main_Page:
23:06.54brlcadthat will likely be one of the single most powerful geometry processing options to get added
23:07.44CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r2912 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Quattvendypol|Quattvendypol]] ([[User talk:Quattvendypol|Talk]]); changed back to last version by [[User:Erik|Erik]]
23:07.51CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Quattvendypol]] with an expiry time of infinite (account creation disabled): Inserting nonsense/gibberish into pages
23:08.30CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/protect: protected "[[Main Page]]": [edit=sysop:move=sysop]
23:08.53CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/protect: changed protection level for "[[Main Page]]": [edit=autoconfirmed:move=autoconfirmed]
23:09.22CIA-61BRL-CAD: 03Sean 07http://brlcad.org * r2915 10/wiki/Main_Page:
23:13.30CIA-61BRL-CAD: 03brlcad * r44837 10/brlcad/trunk/include/nmg.h: NMG_DANGLING isn't used, but doesn't need to be commented out
23:15.08*** join/#brlcad mafm_ (~mafm@19.Red-83-40-127.dynamicIP.rima-tde.net)
23:15.23CIA-61BRL-CAD: 03bhinesley * r44838 10/brlcad/trunk/src/tclscripts/man_browser.tcl: Added getBrowser proc to make ManBrowser do the footwork
23:16.50CIA-61BRL-CAD: 03brlcad * r44839 10/brlcad/trunk/src/burst/plot.c: would be nice to be able to toggle the plotting
23:18.11CIA-61BRL-CAD: 03bhinesley * r44840 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Removed buildarcherMan function and replaced it with the instantiation of a ManBrowser mega-widget. Removed ::man command logic that is now performed by ManBrowser.
23:21.54CIA-61BRL-CAD: 03brlcad * r44841 10/brlcad/trunk/include/nmg.h: er, conflicts with raytrace.h -- prefix with NMG_ which they should probably all do anyways
23:22.55CIA-61BRL-CAD: 03brlcad * r44842 10/brlcad/trunk/src/conv/asc/asc2g.c: dead code elimination. not likely support for these (old bspline geometry) will be implemented any time soon, so remove the unused code instead of exiting.
23:34.43CIA-61BRL-CAD: 03brlcad * r44843 10/brlcad/trunk/ (5 files in 2 dirs): remove cat-fb because it incurred a maintenance cost. phototypesetting went out of style 20 years ago, obsolete hardware.
23:36.34CIA-61BRL-CAD: 03brlcad * r44844 10/brlcad/trunk/misc/win32-msvc8/ (Makefile.am cat2fb/): remove the msvc8 build files too
23:36.49brlcadwould anyone object if I remove the msvc build files?
23:40.40*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
23:52.08starseekerwouldn't :-P
IRC log for #brlcad on 20110609

IRC log for #brlcad on 20110609

00:04.42CIA-61BRL-CAD: 03bhinesley * r44845 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Don't need to keep the window name around, since ManBrowser has getBrowser
00:14.22*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
00:22.30CIA-61BRL-CAD: 03bhinesley * r44846 10/brlcad/trunk/src/tclscripts/mged/man.tcl: Removed existing MGED man dialog code, inswitching to the ManBrowser mega-widget. Now MGED/Archer Manual page dialogs are identical, but ToC may vary depending on configuration.
00:24.50CIA-61BRL-CAD: 03bhinesley * r44847 10/brlcad/trunk/NEWS: The manual page browser behavior improvements applied to Archer are now found in MGED as well, since they both use the same ManBrowser mega-widget.
00:26.33*** join/#brlcad crazy_imp (~mj@a89-182-190-201.net-htp.de)
00:32.50CIA-61BRL-CAD: 03bhinesley * r44848 10/brlcad/trunk/NEWS: removed period from sentence fragment
00:56.33CIA-61BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2916 10/wiki/User:Bhinesley: /* Log */ Yesterday, today
01:22.10starseekerbhinesley: I can't run archer from build dir:
01:22.21starseeker<PROTECTED>
01:22.21starseekercan't find package ManBrowser 1.0
01:22.21starseekerERROR: Unable to load Archer
02:27.30*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
03:00.51bhinesleystarseeker:works for me
03:01.00bhinesleyanyone else confirm this?
03:01.22starseekerbhinesley: are you doing an out of source directory build?
03:01.28bhinesleyyeah
03:02.10bhinesleyyou mean running  archer from the bin directory under the svn trunk?
03:02.44starseekeryeah, uninstalled
03:03.14starseekernot from source dir, but from the build bin dir without anything in the final install location
03:03.18bhinesleyI've noticed that it will use the tclscripts that are in your install directory, rather than those in your source directory
03:03.45bhinesleybut that was true far before I made any changes
03:03.52starseekeryeah, that's not really avoidable
03:04.16starseekerlet me try flushing out my install dir...
03:04.20starseekerrebuilds
03:12.16bhinesleyI'm a bit confused though... how would it work uninstalled, since the tclscripts wouldn't be in the install location
03:15.39CIA-61BRL-CAD: 03starseeker * r44849 10/brlcad/trunk/src/tclscripts/CMakeLists.txt: Add man_browser.tcl to CMakeLists.txt
03:16.08starseekerbhinesley: the CMake build logic goes to some trouble to re-create (functionally, at least) the installed layout in the build dir
03:16.42starseekerincluding build and install versions of configuration files, if need be
03:17.57starseekerthat's what all the extra foo in the BRLCAD_ADDDATA macro is about
03:18.56bhinesleyokay... but you just removed man_browser.tcl from the list of tclscripts and added a second menu_override.tcl
03:19.05bhinesleystarseeker: what does that achieve?
03:19.21starseekerno - I added man_browser.tcl and re-aligned menu_override.tcl
03:19.36starseekerman_browser.tcl wasn't in that list previously
03:19.47bhinesleyoops, forgot to update
03:20.05bhinesleywell menu_override is in there twice
03:20.34starseekerah, whoops
03:21.00CIA-61BRL-CAD: 03starseeker * r44850 10/brlcad/trunk/src/tclscripts/CMakeLists.txt: only need menu_override.tcl once
03:21.14starseekerthere we go
03:21.33bhinesleydoes it work as expected now?
03:21.36starseekeryep
03:21.40starseekernice :-)
03:21.47bhinesleycool
03:21.53bhinesleyyou live you learn
03:22.25starseekerno problem - that's something of a custom feature of our build system, not a "normal" CMake setup
03:22.31starseekereasy fix
03:23.08starseekerreally needs to properly document this thing in a writeup...
03:23.24starseekerright after all my other problems go away (sigh)
03:23.28bhinesleyhaha
03:23.54bhinesleyso if I add a file, as far as building goes, is that the only place I need to add it?
03:24.06starseekerfor a tclscript? yeah.
03:24.19bhinesleyyes, that's all I meant
03:24.22starseekeror in the CMakeLists.txt file in the appropriate subdirectory
03:24.36bhinesleynods
03:25.05bhinesleywhat time is it for you?
03:25.07starseekertechnically we should probably add 'em to the Makefile.am lists, at least until we finally remove the old logic
03:25.15starseekerclosing in on 11pm
03:25.55starseekerI lied - closing in on 11:30pm
03:26.01bhinesleyah okay... I wasn't sure if you were a night owl or an early riser :)
03:26.21starseekernight owl by inclination - occasional early riser by necessity
03:26.45bhinesleyyeah, me too
03:27.48bhinesleybut not tonight ;-) see you later
03:29.05starseekerlater
03:38.51CIA-61BRL-CAD: 03brlcad * r44851 10/brlcad/trunk/src/mged/points/main.c: let both of them work together, wrap in COMPILE_STANDALONE instead of ambiguous if 0
03:39.46CIA-61BRL-CAD: 03brlcad * r44852 10/brlcad/trunk/src/mged/points/process.c: key off PRINT_DEBUG instead of 0
03:52.20brlcadbhinesley: er, and (for the time being) also add new files into the Makefile.am .. parallel build systems until deprecation process is completed
03:53.33brlcad(which you did, I believe)
03:56.44CIA-61BRL-CAD: 03brlcad * r44853 10/brlcad/trunk/src/mged/points/process.c: quell warning, PRINT_ARRAY, not PRINT_DEBUG
04:03.11CIA-61BRL-CAD: 03brlcad * r44854 10/brlcad/trunk/NEWS:
04:03.11CIA-61BRL-CAD: the commit message must be reiterated when lines are edited so that our
04:03.11CIA-61BRL-CAD: auto-processing of this file will pick up the right (last) comment in reports.
04:03.11CIA-61BRL-CAD: erik and I added a handful of new cmake build files that were missing from the
04:03.12CIA-61BRL-CAD: source dist.
04:07.56brlcadbhinesley: NICE
04:08.03brlcadthe browser looks fantastic
04:08.24brlcadlike the bindings
04:17.16*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
04:19.36brlcadstarseeker: am I correct recalling that the cmake build does not produce a unified brlcad lib (brlcad.dll, libbrlcad.so, etc)
04:19.59brlcadbecause everything would need to compile multiple times
04:49.23CIA-61BRL-CAD: 03brlcad * r44855 10/brlcad/trunk/ (91 files in 34 dirs):
04:49.24CIA-61BRL-CAD: A Big Code Deadness Elimination Fest, G. Huzzah... Remove code that is #if 0'd
04:49.24CIA-61BRL-CAD: out unless there's a comment or some other strong evidence that the code really
04:49.24CIA-61BRL-CAD: needs to hang around because it's useful, is part of a recent work in progress
04:49.24CIA-61BRL-CAD: (still should document why it's if 0'd), or is code that is clearly
04:49.24CIA-61BRL-CAD: demonstrating some useful purpose (beyond "this 'might' be useful some day").
04:49.25CIA-61BRL-CAD: Reduction of 2680 lines.
05:05.40CIA-61BRL-CAD: 03brlcad * r44856 10/brlcad/trunk/doc/deprecation.txt: changes to the spm interface in libbn (to include bn prefix) are minimally impacting changes)
05:08.44CIA-61BRL-CAD: 03brlcad * r44857 10/brlcad/trunk/doc/deprecation.txt: two more spm macro types getting updated
05:36.03CIA-61BRL-CAD: 03brlcad * r44858 10/brlcad/trunk/ (8 files in 6 dirs):
05:36.03CIA-61BRL-CAD: spm functions, types, and macro symbols get the bn prefix added. this makes the
05:36.03CIA-61BRL-CAD: bn api more self-consistent and easier to identify origination. fortunately,
05:36.03CIA-61BRL-CAD: minimally impacting too, so just update symbol names accordingly.
06:21.57*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:45.50*** join/#brlcad Stattrav (~Stattrav@122.167.241.15)
06:45.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:30.33*** join/#brlcad Stattrav (~Stattrav@122.167.241.15)
07:30.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:26.51*** join/#brlcad mafm_ (~mafm@155.Red-83-40-127.dynamicIP.rima-tde.net)
08:54.51CIA-61BRL-CAD: 03d_rossberg * r44859 10/brlcad/trunk/src/libbu/dlfcn.c: made it compile with MSVC
10:05.23starseekerbrlcad: correct
10:44.35kunigamibrlcad: they were there because I wanted to remove warning flags that were causing compilation errors due to osl headers. I'm now turning them off through cmake parameters. I'll remove them.
11:09.23*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
11:09.36*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:30.13CIA-61BRL-CAD: 03kunigami * r44860 10/brlcad/trunk/misc/CMake/FindOSL.cmake: Changed FindOSL so that it searches osl libraries from the OSLHOME environment variable (the path was hard-coded before)
11:33.44CIA-61BRL-CAD: 03kunigami * r44861 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt osl-renderer.cpp): removed unused cpp flags
11:34.35CIA-61BRL-CAD: 03davidloman * r44862 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Added some documentation and a try/catch to catch the thrown exceptions.
11:47.26brlcadkunigami: so warnings are disabled or enabled?  we should default to fully enabled and accommodate quelling the warnings if at all possible
11:47.47brlcadstrict compilation is the golden standard
11:48.49brlcadwith a couple auto-generated code (lex/yacc) exceptions where we can't fix them, the entire source code has been made compliant for improved portability, maintainability, security, consistency, etc
11:49.40brlcadalso, doesn't that memset() defeat the VMOVE's that immediately preceede it?
12:03.48CIA-61BRL-CAD: 03davidloman * r44863 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NetMsgChangeTracker.java: Implement a simple change tracker class with pooling.
12:05.07CIA-61BRL-CAD: 03davidloman * r44864 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferUtils.java: Move ByteBuffer resize functions into ByteBufferUtils
12:08.28CIA-61BRL-CAD: 03davidloman * r44865 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/utils/: Add a utils package
12:13.11CIA-61BRL-CAD: 03kunigami * r44866 10/brlcad/trunk/src/liboptical/ (render_svc.cpp render_svc.h): missing files for osl-renderer to compile
12:30.28kunigamibrlcad: I can't compile OSL code if I do not use -DBRLCAD-ENABLE_COMPILER_WARNINGS=OFF and -DBRLCAD-ENABLE_STRICT=OFF
12:30.41kunigamiI mean link
12:31.52CIA-61BRL-CAD: 03brlcad * r44867 10/brlcad/trunk/src/librt/ (librt_private.h primitives/ell/ell.c primitives/epa/epa.c): consolidate and move rt_ell_ang() from epa.c to ell.c since it's used by ehy, epa, and hyp. Add to librt_private.h since it's private reuse API.
12:31.56CIA-61BRL-CAD: 03kunigami * r44868 10/brlcad/trunk/misc/CMake/FindOSL.cmake: Modified FindOSL so that it can find the libraries on linux too
12:34.23CIA-61BRL-CAD: 03brlcad * r44869 10/brlcad/trunk/src/librt/primitives/ (ehy/ehy.c hyp/hyp.c): no longer need the forward decls for rt_ell_ang() since it's in librt_private.h
12:34.43kunigamibrlcad: thanks for spotting that! I'll fix it
12:35.07brlcadkunigami: sure, but what are the warnings
12:35.16brlcadit *should* stop the build
12:35.34brlcaduntil the source code issues get fixed or accommodated
12:35.43brlcadthat's part of the strictness
12:36.09brlcadso the question isn't whether it works or not, it's what's the warning?
12:36.50kunigamiok. I'll run it again to get these warnings
12:36.57brlcadif that can be dealt with (in any fashion) without disabling warnings, then we should if only so that we can compile OUR code with strict reporting
12:37.32brlcadi.e., the code in if_osl.c and osl_renderer.cpp should be strict compliant
12:37.57brlcadit's possible that the warnings can't be squashed, but we should try
12:39.56brlcadalso, if you're going to readd new files, make sure you update Makefile.am and CMakeLists.txt so the build isn't broken in the interim :)
12:40.25brlcadtrying not to call out too much at once, hopefully not overwhelming -- one bit at a time... :)
12:42.33kunigamiI always forget to update Makefile.am! On cmake files I'm trying to maintain them inside ENABLE_OSL code, so that normal builds will keep compiling
12:43.08CIA-61BRL-CAD: 03brlcad * r44870 10/brlcad/trunk/src/librt/ (5 files in 5 dirs): rename rt_ell_ang() to ell_angle(). it's not public librt API, so it shouldn't have the rt_ prefix. ell_ prefix is appropriate living in ell.c and given what it does.
12:43.58brlcadyeah, I saw that
12:44.14brlcadfor Makefile.am, you can keep it simple
12:44.50brlcadsince they have all those extra deps and build logic needed, your stuff can just get added to EXTRA_DIST so it's at least in the source tarball
12:45.18kunigamiok!
12:45.22brlcadwould be a waste of time to add duplicate build logic to both now that the autotools one is deprecated
12:46.24kunigamiwouldn't be better to add those files to Makefile.am only after they are functional?
12:49.07brlcadnope
12:49.35brlcadit will actually halt our ability to make a release
12:50.28brlcadthere's a validation check to make sure any file available on checkout is in a source tarball
12:50.52kunigamiok
12:50.53brlcadso all files have to get listed at least as EXTRA_DIST
12:51.08brlcadit won't attempt to compile them as EXTRA_DIST, just adds them to the source tarball
12:51.38brlcadthat was a source tarball can still be prepared with autotools, but you'd have to compile with cmake to get the osl shader
12:51.54brlcadwhich is all good, cmake will be prime within 3 months
12:52.12kunigamiperfect
12:55.29CIA-61BRL-CAD: 03kunigami * r44871 10/brlcad/trunk/src/liboptical/ (Makefile.am osl-renderer.cpp): including added files on EXTRA-DIST
12:55.30``Erik*readreadread* yeh, I was thinking EXTRA_DIST
12:55.41``Erikhopefully, cmake will be primary in 3 weeks.
12:58.14kunigamithe file in src/other/iwidgets/pkgIndex.tcl seems to be written on building and is versioned
12:59.52kunigamioh I'm confused. I'm able to compile even with strict flags on >.< I'll check if it was not a cache issue
13:01.31``Erikbrlcad: the compile fails he was getting were with the fruity osl headers, it's legit
13:02.05``Erik(or, the ones he reported a few days back were osl headers, ... I'll shut up and let it unfold here :) )
13:02.19kunigamihaha :)
13:04.08``Erikstarseeker: I'm getting bad memory assertions on winderz from btclsh... I'm not in today, but if you want to borrow my winderz pooter to look into it, be my guest. it's stopping the ampi stuff from doing it's thing. (and I have the spare key, had it on the dash of my truck when I turned around and went home this morning. if I don't see you tomorrow, I'll either leave it on my desk or stop by your place over the weekend)
13:04.35starseekercool, thanks
13:05.33starseekergrowl... Windows Strikes Again...
13:05.39``Erik(and one of these days, I'll take ya guys to dinner as a danke)
13:05.58starseeker``Erik: no worries - I owe Bob at least a steak...
13:06.37starseekerkunigami: you might try mentioning OSL header issues to the OSL devs
13:07.03``Erikyeah, I should probably give bob a bottle of 1800 or something for the tree
13:07.23``Erikget him spoiled on 'good' stuff :>
13:07.32starseekerheh
13:07.46kunigamistarseeker: ok
13:07.50``Erikmebbe cabo wabo
13:08.28brlcadI don't doubt they were legit, it's whether they can be squashed on our end or not, like we do for other headers that have issues
13:09.43kunigamiouch I just ran cmake inside brlcad source directory and made a mess. Any easier way to cleanup that instead of a clean checking out?
13:09.46``ErikI still need to look up details on the tnt/jama ... thing. external headers can be a bear :)
13:10.15``Erikrm -rf CMakeCache.txt CMakeFiles ; find . -name Makefile -or -name CMakeFiles | xargs rm -rf
13:10.23brlcadkunigami: if you ever want to verify the autotools build in addition to the cmake build, this should do it: sh autogen.sh && ./configure --enable-all --enable-warnings --without-ogl && make distcheck
13:10.26``ErikI think that'll clobber it well
13:10.55brlcadtnt/jama we can fix :)
13:11.28brlcadthey're warnings were trivial, but easy edits
13:11.41``Erik"best practice" is to build out of srcdir... mkdir -p build/auto build/cmake ; (cd build/cmake && cmake ../.. && make) ; sh autogen.sh && (cd build/auto && ../../configure && make)
13:12.12brlcadthough in-dir should work too .. just gets messy
13:13.15``Erikif ya make a mess using out of dir, rm -rf is an easy cleanup :) indir is the trivial case, so of course it should work
13:13.46kunigamiI always use a build directory with cmake ../brlcad but if I'm on blcar directory, ../brlcad goes to the source directory. Maybe I should change brlcad-build level :)
13:17.00``Erikbrlcad: what do you think of a toplevel "models" repo? is MoRe a flop? I think I've been volunteered for a small construction project and want to crank a model for verification and materials list... (toddler sandbox)
13:31.19*** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br)
13:31.56kunigami_Here's the error when compiling with strict: http://pastebin.mozilla.org/1246222
13:32.37kunigami_note that most of the errors come from two files I copied from OSL. There's one at oslclosure that is from the library itself
14:19.17brlcadlikes to use .build dirs, old gen.sh legacy
14:19.58brlcadmore consistent for NFS mounted filesystems too where you have multiple binary builds simultaneously
14:22.58brlcadkunigami: all except the one in oslclosure.h are fixable since they're in our source tree
14:23.09brlcadand since it's just an extraneous ';', it's worth an edit on oslclosure.h too so strict can remain enabled
14:24.37brlcadworth a patch to the osl dev, since it's probably just something overlooked
14:37.20CIA-61BRL-CAD: 03d_rossberg * r44872 10/brlcad/trunk/src/ (libbn/CMakeLists.txt libbu/CMakeLists.txt): removed a flag that is set in the BRLCAD_ADDLIB macro anyway
14:41.55CIA-61BRL-CAD: 03d_rossberg * r44873 10/brlcad/trunk/src/other/libz/CMakeLists.txt: now there will be build a static zlib library too if the BUILD_STATIC_LIBS flag is set
14:45.40kunigamibrlcad: ok!
14:50.00``Erikhuh, jra called
15:46.08*** join/#brlcad Stattrav (~Stattrav@117.192.136.249)
15:46.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:53.50dlomanjra?  Where is he now... Florida?
16:15.57*** join/#brlcad Stattrav (~Stattrav@117.192.143.183)
16:15.57*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:23.48CIA-61BRL-CAD: 03kunigami * r44874 10/brlcad/trunk/src/liboptical/CMakeLists.txt: Modified CMakeLists. Libraries paths are not hard-coded anymore
17:18.34``Erikhe's still local, he has grandkids in the area
17:18.52``Erikhe noted your abdication, dlo
18:24.21*** join/#brlcad mafm_ (~mafm@155.Red-83-40-127.dynamicIP.rima-tde.net)
18:34.00*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
21:43.25dlomanbrlcad:  was in your neighborhood today and saw this:  http://i56.tinypic.com/2e0iog0.png  and figured I'd let you know that a cop might stop you since the car seat isn't facing backwards.  Just a heads up.
21:44.41dloman=D
21:57.35CIA-61BRL-CAD: 03bhinesley * r44875 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: ManBrowser window naming collision is no longer a factor; renamed window.
23:26.14*** join/#brlcad mafm (~mafm@155.Red-83-40-127.dynamicIP.rima-tde.net)
IRC log for #brlcad on 20110610

IRC log for #brlcad on 20110610

00:26.47*** join/#brlcad crazy_imp (~mj@a89-182-155-87.net-htp.de)
01:27.36bhinesleyI'm getting a compile error with cmake: http://pastebin.mozilla.org/1246735
01:27.46bhinesleyglu.h doesn't exist
01:40.13bhinesleyI disabled GL, and was able to compile.
02:08.05bhinesleydisregard... I cleaned the build directory and it's working with GL enabled now, too.
02:17.02CIA-61BRL-CAD: 03bhinesley * r44876 10/brlcad/trunk/src/proc-db/sketch.c: Applied patch 3247828, submitted by myself. Fixed sketch usage statment so that it isn't always printed, and clarified the output when an argument is mistakenly provided
02:40.11brlcaddloman: hehe
02:40.16brlcadwhere'd that pic come from?
02:43.49CIA-61BRL-CAD: 03bhinesley * r44877 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl:
02:43.49CIA-61BRL-CAD: Applied patch 3309910, submitted by myself. It makes Archer's opendb command
02:43.49CIA-61BRL-CAD: behave like more mged when no arguments are supplied. It prints the database
02:43.49CIA-61BRL-CAD: name if it is in memory only, or it prints the path to and name of the database
02:43.49CIA-61BRL-CAD: if it is saved on disk.
02:50.03*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
02:50.09CIA-61BRL-CAD: 03bhinesley * r44878 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Applied patch 3309107, submitted by myself. It adds a closedb command to Archer, which simply loads an empty database in memory, like when Archer is first started.
02:57.57CIA-61BRL-CAD: 03bhinesley * r44879 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Applied patch 3267991, submitted by myself. The commands 'q' and 'exit' are already available in Archer; this adds the 'quit' synonym.
02:59.20CIA-61BRL-CAD: 03brlcad * r44880 10/brlcad/trunk/NEWS: bhinesley made Archer's opendb command behave like mged when no arguments are supplied. It prints the name if the database is in memory only, or it prints the absolute path if the database is saved on disk.
03:00.28CIA-61BRL-CAD: 03brlcad * r44881 10/brlcad/trunk/BUGS: opening a database with the same name as a command (in archer) reportedly (by bhinesley) doesn't work
03:01.33CIA-61BRL-CAD: 03brlcad * r44882 10/brlcad/trunk/NEWS: bhinesley added the missing closedb command to archer as well, calls Load '' which closes the current database and opens an empty one like when archer first starts up.
03:17.46CIA-61BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2917 10/wiki/User:Bhinesley: /* Log */ today, and plan tomorrow
03:33.51*** part/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
06:52.01*** join/#brlcad Stattrav (~Stattrav@122.167.241.15)
06:52.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:17.03*** join/#brlcad mafm (~mafm@183.Red-81-32-97.dynamicIP.rima-tde.net)
09:29.44*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
09:29.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:00.55*** join/#brlcad merzo (~merzo@193.254.217.44)
15:00.55*** join/#brlcad mafm (~mafm@183.Red-81-32-97.dynamicIP.rima-tde.net)
15:25.00*** join/#brlcad Stattrav (~Stattrav@122.172.247.68)
15:25.00*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:09.35brlcadmm, some nice features coming in the subversion 1.7 update
16:23.32CIA-61BRL-CAD: 03brlcad * r44883 10/brlcad/trunk/ (42 files in 25 dirs): convert about 180 calls to NEAR_ZERO() to NEAR_EQUAL() where the intent seems (via the a - b = 0 trick) to be comparing for equality. improves readability.
16:24.07starseekerbrlcad: are they close to releasing 1.7?
16:28.02CIA-61BRL-CAD: 03brlcad * r44884 10/brlcad/trunk/doc/deprecation.txt: BU_EXTERN and BU_ARGS are pre-c89 accommodations, no longer needed and minimally impacting to remove them
16:42.18CIA-61BRL-CAD: 03brlcad * r44885 10/brlcad/trunk/doc/deprecation.txt: BU_EXTERN() is a macro and a bit more tricky to isolate properly, but still minimally impacting.
16:48.39CIA-61BRL-CAD: 03starseeker * r44886 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Archer's use of the search command needed updating after the syntax change - fixed highlighting of related items in Archer.
16:51.35CIA-61BRL-CAD: 03starseeker * r44887 10/brlcad/trunk/NEWS:
16:51.36CIA-61BRL-CAD: Archer's tree widget can optionally highlight combinations that would be
16:51.36CIA-61BRL-CAD: impacted by the editing of the currently selected component - that feature
16:51.36CIA-61BRL-CAD: relied on search, and the syntax change threw it off. Fixed syntax, behavior
16:51.36CIA-61BRL-CAD: restored.
17:09.15CIA-61BRL-CAD: 03brlcad * r44888 10/brlcad/trunk/doc/deprecation.txt: have been using emacs syntax to date, but change over to perl syntax so we can easily show users how to apply a minimally impacting regex to their file(s)
17:15.27CIA-61BRL-CAD: 03brlcad * r44889 10/brlcad/trunk/doc/deprecation.txt: untested, but this should swap them from emacs regexp quoting to perl quoting
17:17.17CIA-61BRL-CAD: 03brlcad * r44890 10/brlcad/trunk/doc/deprecation.txt: meant slurp mode, not code 7
17:34.49*** join/#brlcad mafm (~mafm@193.153.199.74)
17:44.24bhinesleystarseeker: You said that it's possible to run Archer from the build directory uninstalled... but it's still using the installed tcl scripts for me. What's the trick?
17:45.04bhinesleyI did a cmake build out of the source directory
17:46.26bhinesley*outside of
17:50.36*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
17:50.36*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:15.58starseekerbhinesley: if you have an installed BRL-CAD in the same directory as your CMAKE_INSTALL_PREFIX, BRL-CAD will look there first for dat
18:16.01starseekerdata even
18:16.16bhinesleyoh, alright :)
18:16.37starseekeryou can either a) re-build BRL-CAD with CMAKE_INSTALL_PREFIX set to a directory where there is no BRL-CAD or b) remove the installed version
18:16.46starseekerI get bit by that once in a while too
18:17.18``Erikstarseeker: "Consider a Spherical Cow: A Course in Environmental Problem Solving" by John Harte ( http://en.wikipedia.org/wiki/Spherical_cow )
18:17.19bhinesleyanything to save time testing
18:17.20starseekerusually what I'll do is pass -DCMAKE_BUILD_TYPE=Debug - that sets the install directory to ../brlcad-install relative to the build directory (IIRC)
18:17.31starseeker``Erik: heh, yep :-)
18:18.00starseekerbhinesley: then, as long as you don't have the brlcad-install actually installed, you can run successfully from the build directory
18:18.13starseekeror brlcad-install actually populated rather
18:18.39bhinesleyalright, I'll give that a go
18:18.40``Erik"wanted dead or alive: schrödinger's cat"
18:19.00starseeker<snort> I think that's wanted dead AND alive :-O
18:19.12starseeker:-P
18:19.37``Erik"a seminar on time travel will be held two weeks ago"
18:19.45``Erikthere's pretty corny :D
18:20.04starseekersooo...  you found the bottom of the internet? :-P
18:20.20``Erikit's not as bad as /b/
18:23.11*** join/#brlcad athena0 (~ed@ppp-70-226-169-88.dsl.mdsnwi.ameritech.net)
18:26.48starseekerhmm - an auction company in Dallas, TX called Heritage Auctions is selling dinosaur skeletons
18:27.00starseekerjust the thing to put up in the living room :-P
18:27.29starseeker(talk about an efficient way to scare little kids...)
18:29.36bhinesleypsh... not my kids. They'd be all over it.
18:36.29athena0I'm having a brain-fart...  brlcad is complaining about a missing library before compile, and I can't seem to resolve it.
18:36.46athena0$ grep "Xi library" config.log
18:36.53athena0configure:28705: WARNING: X11 support is enabled but the Xi library was not found.
18:37.00bhinesleymesagl, I believe
18:37.09bhinesleyhold on
18:37.16athena0$ sudo aptitude search libxi | grep "X11 Input"
18:37.21athena0i   libxi-dev                       - X11 Input extension library (development h
18:37.30athena0i   libxi6                          - X11 Input extension library              
18:37.38athena0p   libxi6-dbg                      - X11 Input extension library (debug package
18:38.11athena0Have I forgotten something obvious here?
18:42.47*** join/#brlcad EricZZZ (~EricZZZ@ppp-70-226-169-88.dsl.mdsnwi.ameritech.net)
18:44.17bhinesleyathena0: I'm pretty sure there is a mesa library missing, but I'm having trouble proving that.
18:44.29bhinesleyI've had that warning before
18:46.22athena0I don't suppose there'd be any harm in just installing xlibmesa-gl and xlibmesa-gl-dev and giving it another shot
18:46.36bhinesleynods
18:46.39bhinesleysorry I can't say for sure
18:52.45*** part/#brlcad bhinesley (~bhinesley@99.144.90.118)
18:52.51*** join/#brlcad bhinesley (~bhinesley@99.144.90.118)
18:53.55athena0Arg.  No dice.  Still complaining about Xi library not found
18:54.12bhinesleyathena0: Yeah, I see it now. The message is coming from configure.ac:1220
18:54.18bhinesleylibxi, allegedly
18:55.00bhinesleyso maybe you need to do a "make clean" or something
18:56.10athena0Worth a shot.  ...
18:57.23athena0No, still complaining during ./configure  after a make clean
18:57.37bhinesley:-/
18:58.33athena0My system seems pretty convinced it's got the libxi packages.  Any chance it's just hid them away in some strange directory structure?  Maybe this could be solved with a well-placed "ln -s"
19:01.36bhinesleydo a `sudo updatdb && locate libXi.so`
19:01.45bhinesleymine are in /usr/lib and /usr/lib64
19:03.39CIA-61BRL-CAD: 03kunigami * r44891 10/brlcad/trunk/src/liboptical/ (5 files): Discovered that OSLRender only leaks memory if called by sh_osl. I've copied the osl raytracer into osl_rt in such a way that it calls OSLRender class. Valgrind did not identified the memory leaks present in the rt run
19:03.54athena0$ sudo updatedb && locate libXi.so
19:04.16athena0<PROTECTED>
19:04.21athena0<PROTECTED>
19:04.27athena0<PROTECTED>
19:13.14bhinesleyathena0: do you have libx11-dev installed?
19:16.07athena0Yep.  
19:16.08athena0$ sudo updatedb && locate libx11-dev
19:16.12athena0<PROTECTED>
19:16.49athena0(output truncated ...)
19:17.03bhinesleyyeah, I believe ya
19:19.41athena0Would it be possible for the .deb file available for download to work on my machine when the source doesn't look like it's going to compile?
19:20.08bhinesleyyeah
19:20.24athena0ah.  Then I'm gonna give that a shot.
19:21.01bhinesleygood idea :)
19:44.22CIA-61BRL-CAD: 03bhinesley * r44892 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl CombEditFrame.tcl):
19:44.22CIA-61BRL-CAD: Adding '-sorted' to lsearch's in few places where it's clear that the given list
19:44.22CIA-61BRL-CAD: was A) sorted '-increasing' B) sorted as ASCII text C) was not modified before
19:44.22CIA-61BRL-CAD: the search D) not sorted with any of '-all'/'-not'/'-glob'/'-regexp'. This
19:44.22CIA-61BRL-CAD: option results in increased performance, since it forces lsearch to do a binary
19:44.22CIA-61BRL-CAD: search, rather than the default linear search.
19:44.23CIA-61BRL-CAD: Of all 58 instances of lsort in BRL-CAD tcl scripts that were inspected, only 3 obvious cases of missing 'lsearch -sorted' options were found following them.
20:00.57*** join/#brlcad roberthl (~robert@v1.rhl.me.uk)
20:00.57*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
20:04.24athena0Seems to work!  
20:04.45athena0bhinesley: Thanks very much for your help.
20:05.14bhinesleyathena0: no problem, I wish could have helped more
20:10.40*** join/#brlcad Stattrav (~Stattrav@117.192.142.11)
20:10.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:21.58CIA-61BRL-CAD: 03bhinesley * r44893 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Realigned the definition of mArcherCoreCommands, which was getting a little out of hand
20:47.31CIA-61BRL-CAD: 03bhinesley * r44894 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Indented a multi-line string.
21:03.21CIA-61BRL-CAD: 03starseeker * r44895 10/brlcad/trunk/TODO: Archer search usage fixed, note problems being seen with rtwizard.
21:05.58starseekerI think with that can't find Xi libs thing you might to call out the x11 location using --with-x11 or some such... I ran into something similar once.
21:06.07starseekerwonder if CMake build would have worked
21:07.35starseekerreally needs to have another go at getting RamDebugger running and see if it would help the Tcl/Tk development process...
21:10.51bhinesleystarseeker: I had the problem once before too, but I can't remember what I did. I thought it was due it some package I installed, because once it was fixed it never came back.
21:12.50bhinesleyRamDebugger looks neat
21:17.51starseekerbhinesley: heh - don't be tempted to waste too much time on it though - I have a feeling getting it working with BRL-CAD could be a bit of a trick
21:18.30bhinesleyI'm sure
21:19.44starseekerI'd have to start by hooking it all into our CMake tclscripts logic, and then fixing whatever needs fixing
21:19.56starseekerand figure out which pieces (e.g. tkcvs) we could ditch
21:20.27bhinesleySpeaking of which, is there any chance of distcc working? I've tried, but it complained that it wasn't a valid compiler.
21:20.57bhinesleyit worked alright with automake
21:21.13starseekerurm
21:22.20bhinesleynot that it's a big deal :)
21:22.32starseekerlooking over CMake list archives...
21:22.57starseekerCC=distcc gcc" cmake ../brlcad ?
21:23.13bhinesleyyeah, it dies
21:23.25starseekerdies how?
21:23.54bhinesleysomething about distcc not passing compiler checks... I'll try it again in a bit and let you know. I'm doing another build right now.
21:24.06starseekerhuh.  k
21:24.50starseekerlooks like distcc has come up before:  http://www.cmake.org/pipermail/cmake/2008-January/019292.html
21:35.03bhinesleystarseeker: http://pastebin.mozilla.org/1247430
21:35.33starseekererm.  distcc works in isolation?
21:36.01bhinesleyit uses gcc/g++
21:36.19starseekerI mean if you run the line #
21:36.20starseekerI mean if you run the line /usr/bin/distcc gcc -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -c
21:36.23starseeker# /home/bhinesley/brlcad-trunk/build/cmake-withogl-distcc/CMakeFiles/CMakeTmp/testCCompiler.c
21:36.47starseekerand then linke it: #
21:36.47starseekerand then linke it: /usr/bin/distcc gcc CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o -o
21:36.50starseeker# cmTryCompileExec -rdynamic
21:36.54starseekerer link it even
21:38.00bhinesleyI'm not sure if the "gcc" is supposed to be there or not
21:38.49starseekerbhinesley: maybe not - I'd experiment with it "in isolation" to make sure you can get it to work, first
21:42.22bhinesleyoh, I see what you mean
21:44.41starseekerhrm... looks like tktreectrl would need a CMake build file...
21:44.47starseekerfights the temptation...
22:03.33bhinesleywhat does the debug flag do besides change the install directory?
22:50.27*** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net)
23:07.27starseekerbhinesley: adds -g flag, few other compiler flags
23:19.11*** join/#brlcad mafm (~mafm@95.Red-88-22-160.staticIP.rima-tde.net)
23:32.58CIA-61BRL-CAD: 03brlcad * r44896 10/brlcad/trunk/ (10 files in 6 dirs): stop using BU_ARGS, just list the arguments. c89/posix lets us move forward.
23:50.15*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
IRC log for #brlcad on 20110611

IRC log for #brlcad on 20110611

00:27.03*** join/#brlcad crazy_imp (~mj@a89-182-246-204.net-htp.de)
01:06.45CIA-61BRL-CAD: 03brlcad * r44897 10/brlcad/trunk/doc/deprecation.txt: space is optional
01:23.31CIA-61BRL-CAD: 03brlcad * r44898 10/brlcad/trunk/ (12 files in 4 dirs): remaining removal of BU_ARGS. poof.
01:33.37*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177726205.dsl.bell.ca)
03:54.16CIA-61BRL-CAD: 03brlcad * r44899 10/brlcad/trunk/include/bu.h: ws cleanup
04:40.00CIA-61BRL-CAD: 03brlcad * r44900 10/brlcad/trunk/ (18 files in 5 dirs): ws consistency cleanup of affected files
04:52.39CIA-61BRL-CAD: 03brlcad * r44901 10/brlcad/trunk/src/librt/db_open.c: revert back to r43023 .. unintentionally caught up in ws commit.
04:54.12CIA-61BRL-CAD: 03brlcad * r44902 10/brlcad/trunk/src/librt/db_open.c: ws cleanup
04:57.33CIA-61BRL-CAD: 03brlcad * r44903 10/brlcad/trunk/src/librt/db_open.c: document why dynamic memory is being allocated here. also, search the database dir before the current dir when looking for resources. less likely to pick up random unintentional files.
05:39.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:27.48*** join/#brlcad Stattrav (~Stattrav@117.192.140.12)
07:27.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:20.08*** join/#brlcad mafm (~mafm@26.Red-88-11-185.dynamicIP.rima-tde.net)
09:31.47*** join/#brlcad Stattrav (~Stattrav@117.192.140.12)
09:31.49*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:42.39*** join/#brlcad mafm_ (~mafm@26.Red-88-11-185.dynamicIP.rima-tde.net)
14:35.16*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:07.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:44.13*** join/#brlcad Stattrav (~Stattrav@117.192.157.26)
18:44.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:50.33*** join/#brlcad Stattrav (~Stattrav@117.192.157.26)
18:50.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:58.53*** join/#brlcad Stattrav (~Stattrav@117.192.157.26)
18:58.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:07.12*** join/#brlcad Stattrav (~Stattrav@117.192.157.26)
19:07.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:15.43*** join/#brlcad Stattrav (~Stattrav@117.192.157.26)
19:15.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:23.39*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:33.47*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
21:08.03*** join/#brlcad Stattrav (~Stattrav@117.192.157.26)
21:08.03*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
IRC log for #brlcad on 20110612

IRC log for #brlcad on 20110612

00:27.15*** join/#brlcad crazy_imp (~mj@a89-182-141-188.net-htp.de)
07:05.29*** join/#brlcad Stattrav (~Stattrav@117.192.137.146)
07:05.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:29.38*** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ)
07:33.42*** join/#brlcad roberthl_ (~robert@v1.rhl.me.uk)
07:43.01*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
07:43.22*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
07:43.32*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
07:43.51*** join/#brlcad crazy_imp (~mj@a89-182-141-188.net-htp.de)
07:43.51*** join/#brlcad vtts_ (~vytautas@diz.ktu.lt)
07:43.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:43.51*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
07:43.51*** join/#brlcad yiyus (1242712427@je.je.je)
07:44.15*** join/#brlcad mafm_ (~mafm@26.Red-88-11-185.dynamicIP.rima-tde.net)
07:44.15*** join/#brlcad bhinesley (~bhinesley@99.144.90.118)
07:44.15*** join/#brlcad piksi (piksi@pi-xi.net)
07:44.15*** join/#brlcad DarkCalf (DC@173.231.40.98)
07:44.30*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
07:44.30*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
07:44.30*** join/#brlcad dtidrow (~dtidrow@c-68-60-96-218.hsd1.mi.comcast.net)
07:49.42*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
07:49.54*** join/#brlcad crazy_imp (~mj@a89-182-141-188.net-htp.de)
07:57.30*** join/#brlcad roberthl (~robert@v1.rhl.me.uk)
07:57.30*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
08:04.20*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
08:07.46*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
14:22.55*** join/#brlcad Stattrav (~Stattrav@117.192.150.161)
14:22.55*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:04.12*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
17:43.40*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
18:16.01*** join/#brlcad Stattrav (~Stattrav@117.192.150.161)
18:16.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:43.48CIA-61BRL-CAD: 03bhinesley * r44904 10/brlcad/trunk/src/tclscripts/man_browser.tcl: There was a common variable for a listbox -listvariable; changed it to an array so that multiple instances could use it.
20:44.53CIA-61BRL-CAD: 03bhinesley * r44905 10/brlcad/trunk/src/tclscripts/ (archer/ArcherCore.tcl mged/man.tcl): Man commands for both MGED/Archer weren't correctly handling invalid command names.
21:30.00dlomanloving this and the sequel: http://www.youtube.com/watch?v=EwCOG-2ORrc&feature=related
22:01.47CIA-61BRL-CAD: 03bhinesley * r44906 10/brlcad/trunk/src/tclscripts/man_browser.tcl:
22:01.48CIA-61BRL-CAD: Fully documented the ManBrowser class. Made the order of method definitions
22:01.49CIA-61BRL-CAD: consistent with the order they were declared in the interface. Removed
22:01.49CIA-61BRL-CAD: getBrowser method and let the only caller (listbox selection binding) handle
22:01.49CIA-61BRL-CAD: that itself. Added a couple items to the to-do/ideas list. Removed all code that
22:01.50CIA-61BRL-CAD: was commented out.
IRC log for #brlcad on 20110613

IRC log for #brlcad on 20110613

00:16.09CIA-61BRL-CAD: 03bhinesley * r44907 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Some tests I was running regarding a bug in the ls command were accidently included in the last commit. Reverting
00:27.28*** join/#brlcad crazy_imp (~mj@89.182.141.229)
04:06.21*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
07:11.34*** join/#brlcad Stattrav (~Stattrav@122.172.247.68)
07:11.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:20.41*** join/#brlcad yiyus (1242712427@je.je.je)
09:03.02*** join/#brlcad CIA-12 (~CIA@cia.atheme.org)
09:37.53*** join/#brlcad CIA-49 (~CIA@cia.atheme.org)
10:55.26CIA-49BRL-CAD: 03Kunigami 07http://brlcad.org * r2918 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */
11:46.58CIA-49BRL-CAD: 03brlcad * r44908 10/brlcad/trunk/doc/deprecation.txt: little more aggressive multiline matching even though it still will skip function pointer arguments
12:18.04CIA-49BRL-CAD: 03brlcad * r44909 10/brlcad/trunk/ (65 files in 27 dirs): the days of supporting pre-ansi C compilers are long past. remove the BU_EXTERN() wrapper macro as a minimally impacting change. functions should be fully descriptive per ansi with type qualified parameter lists.
12:25.14brlcadhas wanted to do that for more than 10 years!
12:34.27CIA-49BRL-CAD: 03kunigami * r44910 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt osl_rt2.c): Added a simple c osl raytracer to call functions from osl_render. it does not leak memory
12:36.19CIA-49BRL-CAD: 03kunigami * r44911 10/brlcad/trunk/src/liboptical/osl_rt.cpp: Changed osl_rt (cpp version) to use the wrapper functions instead of the class methods directly. it does not leak memory
12:37.40CIA-49BRL-CAD: 03kunigami * r44912 10/brlcad/trunk/src/liboptical/sh_osl.c: Changed sh_osl so that the reference to OSLRenderer is stored in shader_specifics. It does leak memory :(
12:51.18CIA-49BRL-CAD: 03brlcad * r44913 10/brlcad/trunk/misc/batch-indent-region.el: don't mess with the backslashes
13:24.03CIA-49BRL-CAD: 03brlcad * r44914 10/brlcad/trunk/include/ (15 files): ws indent cleanup after BU_EXTERN removal
13:24.22CIA-49BRL-CAD: 03brlcad * r44915 10/brlcad/trunk/regress/testlib.c: ws indent cleanup
13:35.33kunigamiactually osl_rt2.c leaks memory too
13:53.34brlcaddo you know why? :)
13:55.51CIA-49BRL-CAD: 03brlcad * r44916 10/brlcad/trunk/include/tclcad.h: gah, remove the commas
14:57.01kunigamiI know "where" :) it's on an open image io function called "OpenImageIO::v0::ustring::make_unique". It's probably that the raytracer is not freeing it. Unfortunately it has a lot of calling in between, including some LLVM code
14:57.21kunigamiI'll have to dig further
15:06.06kunigamiouch, this leaking occurs also in osl code, namely the testshade application.
15:17.02starseekerkunigami: has the osl list been of any help with stuff like this?
15:41.38*** join/#brlcad Stattrav (~Stattrav@122.172.247.68)
15:41.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:43.21kunigamihmm, I've once asked by the usage and they did not answered me. But I didn't ask about the code. I'll check if is not a silly mistake and then send an email them.
15:47.03*** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net)
16:09.53kunigamiWhen I run with valgrind, rt finishes without crashing. This image: http://dl.dropbox.com/u/1399996/GSoC/WeirdRendering.png is a render of a scene where the floor has an osl yellow shader. Note the weird black strips on it
16:15.53starseekerkunigami: so does that image consitute the first ever BRL-CAD + OSL raytrace image?
16:16.02kunigamiyes :)
16:16.31starseekerthose black lines might be scan lines that never completed (if there were memory issues or something... you say it crashes without valgrind?)
16:17.34kunigamistarseeker: yup
16:18.04starseekerI'd work on the crash first
16:19.13kunigamihere is the gdb backtrace: http://pastebin.mozilla.org/1248665
16:28.03kunigamiCould that be an issue with multiple threads?
16:50.38*** join/#brlcad merzo (~merzo@50-140-132-95.pool.ukrtel.net)
16:54.37*** join/#brlcad Stattrav (~Stattrav@122.172.247.68)
16:54.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:59.14*** join/#brlcad merzo (~merzo@50-140-132-95.pool.ukrtel.net)
17:23.57brlcadwoot, another logo submission
17:25.24brlcadkunigami: fwiw, OSL is pretty much a one-man show
17:25.50brlcadunfortunately he's not particularly interested in providing support (help) unless you find a bug or write patches, but it's good that you've been talking on the list anyways
17:26.17kunigamiI had that impression too. Larry Gritz seems to be ahead of both OSL and OIIO
17:26.29brlcadnods
17:26.43brlcadnice guy, but not a lot of time
17:27.13brlcadkunigami: run rt -P1 and you won't get thread contention
17:27.23brlcadthat image is fantastic progress, though :)
17:27.32brlcadworth posting to your log
17:34.25bhinesleywhat does the debug flag do besides change the install directory?
17:34.28bhinesleyoops
17:34.41bhinesleyignore that... accidentally sent history
17:39.40bhinesleybrlcad: We talked about a libged command registry a few days ago. Did you have any particulars in mind with regard to how you'd like the registry to work?
17:45.30brlcaddefinitely, started working on the interface over the weekend
17:45.54bhinesleyoh, did you commit anything?
17:52.24kunigamirunning with rt -P1 stops the crashing! (actually I had tried with -P1 before, but I did "./rt example.g scene.c -P1" and just discovered that the order matters >.<)
17:52.34kunigamithe strips are still there though
18:31.16*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
18:50.22brlcadkunigami: so two separate issues -- the strips are probably not threading related then and the crashing may be
18:50.34brlcadP1 just means use one processor
18:51.42kunigamiyup. I'll check if it's not the case that the OSLRenderer is returning black pixels (I don't believe so)
18:51.49CIA-49BRL-CAD: 03brlcad * r44917 10/brlcad/trunk/include/fb.h: common comes before all system headers
18:51.59CIA-49BRL-CAD: 03brlcad * r44918 10/brlcad/trunk/include/ged.h: common comes before all system headers
18:56.27CIA-49BRL-CAD: 03brlcad * r44919 10/brlcad/trunk/src/rt/viewg3.c: comment ws indent style cleanup
18:59.00brlcadyeah, not likely
18:59.31brlcadosl wouldn't know about a scanline
18:59.45brlcadundoubtedly something in sh_osl.c
19:16.37kunigamiIt was actually OSLRenderer that was returning the black points :) The random erand48 depends on the y-coordinate :P
19:19.09kunigamiI'm not sure how we'll deal with the recursion.
19:19.57kunigamiOSLRenderer finds a multiplier, generates a new ray and recurse
19:20.12kunigamithe problems is that not all objects are using osl_shaders
19:21.02kunigamiOSLRender would have to return this multiplier back to brlcad system
19:27.15kunigamibut how to deal with reflection and refraction?
19:53.38kunigami-
19:54.15kunigamishould I use "struct bu_vls" instead of "char *"?
19:54.49brlcadthat's pretty interesting
19:56.54CIA-49BRL-CAD: 03r_weiss * r44920 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c:
19:56.54CIA-49BRL-CAD: Made additional corrections to logic in functions 'nmg_booltree_evaluate' and
19:56.54CIA-49BRL-CAD: 'nmg_boolean' within file 'nmg_bool.c'. This fix stops the error 'nmg_boolean()
19:56.54CIA-49BRL-CAD: result of nmg_booltree_evaluate() isn't tp' which occurs occasionally when
19:56.55CIA-49BRL-CAD: performing nmg boolean operations such as when using the mged 'facetize'
19:56.55CIA-49BRL-CAD: command. This change also allows boolean operations to return a null result
19:56.56CIA-49BRL-CAD: without failing.
19:57.06brlcadthose are (sometimes) shader properties, so it'd be the shader shooting any new rays needed (via librt) .. user might write some interesting osl shader that requires thousands of new rays to get generated for each pixel
19:57.57brlcadkunigami: vls vs char* => "it depends"
19:58.20brlcadif you need a dynamic string in C, vls is the way to go
19:58.26brlcadif you're in c++, just use a std::string
19:59.16brlcadif you're just storing a name or label and there's no need for the string to be variable in size, then a char[] might be appropriate
19:59.43brlcadwhen in doubt, vls
20:00.06kunigamiI'd like to add a parameter to sh_osl so that the user can specify which osl shader to use
20:00.16kunigamiI think vls is better then
20:04.14brlcadwhat about embedding an actual osl shader?
20:15.34kunigamido you mean independent from rt?
20:26.27*** join/#brlcad ibot (~ibot@rikers.org)
20:26.27*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
20:36.09*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
21:04.49brlcadkunigami: I mean embedding new shader descriptions, like this: https://github.com/fohr/openshadinglanguage/blob/testrender/src/shaders/matte.osl
21:05.42brlcadso you could define new shaders and new shader behavior at runtime or at least without recompiling brl-cad
21:05.52brlcad(or osl)
21:21.59CIA-49BRL-CAD: 03starseeker * r44921 10/brlcad/trunk/src/rt/viewg3.c: fix C comment formatting
21:24.32starseekerbhinesley: I'm getting a problem with Archer
21:24.46bhinesleywhat's that?
21:24.59starseekerbhinesley: when I launch archer and open a .g file with the File->Open menu option, I can't raytrace the result
21:25.29starseekerwhen I launch archer and supply the .g file name from the command line (e.g. ./bin/archer m35.g) I can raytrace it
21:25.46bhinesleyI'll take a look
21:25.57starseekerthanks
21:30.52starseekerI think it has to do with the path that is being passed to rt
21:31.56starseekerI'm seeing :
21:32.00starseekeropendb /home/user/brlcad/brlcad-build//home/user/brlcad/brlcad-build/share/brlcad/7.20.1/db/m35.g~
21:33.10starseekerwhen I specify from the command line I get:
21:33.13starseekeropendb /home/user/brlcad/brlcad-build/share/brlcad/7.20.1/db/m35.g~
21:41.54bhinesleyhm, I'm getting the same (wrong) result no matter how I open the .g file
21:43.48starseekerbhinesley: could that be a consequence of your recent changes?
21:44.03bhinesleyI'm not seeing how... they're minor/straightforward
21:49.18bhinesleyyeah, it's definitely not that
21:49.49starseekerhrm
21:54.45bhinesleyOkay, it runs for me when I am in the directory of the .g file. If I give it a full path it fails even from the command line.
22:12.24starseekerbhinesley: weird... this must be some kind of recent change, it worked just a little while ago...
22:13.12bhinesleystarseeker: yeah, I've looked through recent svn logs on related files but haven't found anything interesting yet
22:42.42starseekerbhinesley: yeah, me either
22:53.34bhinesleystarseeker: well, you're right about it being a recent change. I updated to r44873, which was 4 days ago, and it works fine.
IRC log for #brlcad on 20110614

IRC log for #brlcad on 20110614

00:09.03*** join/#brlcad vtts (~vytautas@diz.ktu.lt)
00:11.28CIA-49BRL-CAD: 03bhinesley * r44922 10/brlcad/trunk/src/librt/db_open.c: Reverted code changes introduced by r44903. It introduced a bug, where raytracing .g files outside of the CWD would fail due to an invalid path.
00:11.44bhinesleystarseeker: ^^^
00:27.46*** join/#brlcad crazy_imp (~mj@a89-182-248-44.net-htp.de)
00:28.12starseekerbhinesley++
00:28.13starseekernice find
00:28.59bhinesleyshoulda found it earlier, but I didn't realize that the sf commit archives show OLDEST commits on top
00:29.20bhinesleydb_open, duh
00:30.35starseekergood job - I shoulda checked that first, but since it was archer-only behavior on my machine the first thing that lept to mind was tcl/tk changes
00:31.01starseekerobviously not :-O
01:03.34brlcadhm, that implies some other bug because those are supposed to be search paths
01:22.25bhinesleyAh okay. I'll take another look tomorrow.
04:06.32*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
04:23.47CIA-49BRL-CAD: 03brlcad * r44923 10/brlcad/trunk/TODO: eliminate dbi_filepath. shouldn't need to search for resources. the user specified where the database is at, paths are merely relative to our pwd at the time the db was opened or absolute.
04:30.21CIA-49BRL-CAD: 03brlcad * r44924 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c:
04:30.22CIA-49BRL-CAD: rename RT_CK_DISKMAGIC to NMG_CK_DISKMAGIC since it's not librt api and is
04:30.22CIA-49BRL-CAD: internal to just nmg.c; probably doesn't even warrant NMG_ prefix, but might
04:30.22CIA-49BRL-CAD: need to get moved to nmg.h when separated out in a diff lib so leave it be for
04:30.22CIA-49BRL-CAD: now.
04:40.27CIA-49BRL-CAD: 03brlcad * r44925 10/brlcad/trunk/src/librt/ (8 files in 7 dirs): some ws indent changes in here got skipped. commit.
04:42.06CIA-49BRL-CAD: 03brlcad * r44926 10/brlcad/trunk/src/librt/db_open.c: premature, dbip ftw
04:43.38CIA-49BRL-CAD: 03brlcad * r44927 10/brlcad/trunk/include/raytrace.h: dbi_filename paths are not const if we have to free them!
05:00.14CIA-49BRL-CAD: 03brlcad * r44928 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: rename rt_nmg_reindex() to just reindex() since it's not librt public api. looks like it's even private nmg api so we can drop the nmg_ prefix.
05:03.23CIA-49BRL-CAD: 03brlcad * r44929 10/brlcad/trunk/src/ (15 files in 12 dirs): ws indent cleanup after BU_EXTERN removal
05:13.09CIA-49BRL-CAD: 03brlcad * r44930 10/brlcad/trunk/src/librt/librt.3: document the LIBRT_BOT_MINTIE option in the librt manual page, just so it's written down somewhere user-visible.
06:37.15*** join/#brlcad merzo (~merzo@193.254.217.44)
09:31.13*** join/#brlcad Stattrav (~Stattrav@122.172.247.68)
09:31.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:16.36*** join/#brlcad dtidrow (~dtidrow@c-68-60-53-123.hsd1.mi.comcast.net)
10:46.02kunigamibrlcad: the way I was thinking (string identifying shader), you could define a new shader "foo.osl", compile it to "foo.oso" and them load it passing as parameter to sh_osl "foo"
10:46.56kunigamitoday, what we have is that I have a hard-coded osl shader name "yellow", but "yellow.oso" was compiled independently of brlcad or osl
10:48.16kunigami"what we have is that I have" ... lol
10:55.00dlomanyawns
10:55.51dlomanmernin all!
11:00.29kunigamimorning :)
11:02.49dlomanhows gsoc goin for ya?
11:27.23*** join/#brlcad crazy_imp (~mj@a89-182-248-44.net-htp.de)
12:15.58CIA-49BRL-CAD: 03brlcad * r44931 10/brlcad/trunk/ (9 files in 8 dirs):
12:15.58CIA-49BRL-CAD: make bu_vls use size_t/off_t internally for tracking the buffer size.
12:15.58CIA-49BRL-CAD: accordingly, make bu_vls_setlen() and bu_vls_strlen() take a size_t parameter
12:15.58CIA-49BRL-CAD: and propagate changes down to callers as well so we don't have signed/unsigned
12:15.59CIA-49BRL-CAD: mismatching.
12:19.54CIA-49BRL-CAD: 03davidloman * r44932 10/geomcore/trunk/src/GS/FileDataSource.cxx: Comments fix. No longer use BRLCAD::MinimalObject. Uses ExtObjects instead.
12:21.46CIA-49BRL-CAD: 03davidloman * r44933 10/geomcore/trunk/src/clients/ (. java/): Add a dir for client work. Need to reduce confusion by separating the 'interface' work from the 'clients' that use said interface.
12:25.53CIA-49BRL-CAD: 03davidloman * r44934 10/geomcore/trunk/src/clients/java/ (src/ test/): Add /src and /test to client dirs for GS Java Client project setup.
12:29.26CIA-49BRL-CAD: 03davidloman * r44935 10/geomcore/trunk/src/clients/java/: More Project setup. Ignore .* files from eclipse.
12:32.18CIA-49BRL-CAD: 03davidloman * r44936 10/geomcore/trunk/src/clients/java/src/org/ (4 files in 4 dirs): Add initial source package tree to client /src for GS Java Client project setup.
12:34.09CIA-49BRL-CAD: 03davidloman * r44937 10/geomcore/trunk/src/ (19 files in 4 dirs): Move client files from interface project to client project
12:35.00CIA-49BRL-CAD: 03davidloman * r44938 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/minimalclient/: Drop client dirs from interface project
12:53.51CIA-49BRL-CAD: 03brlcad * r44939 10/brlcad/trunk/ (include/bu.h src/libbu/vls.c): vls_offset isn't supposed to go negative since it's a positive index from the front, so make it a size_t too. remove unnecessary casts now that internal bu_vls members are size_t.
13:15.19CIA-49BRL-CAD: 03brlcad * r44940 10/brlcad/trunk/src/mged/animedit.c: linux size_t quellage
13:24.56CIA-49BRL-CAD: 03brlcad * r44941 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: got some unreliable asc2g crashes with the new tclcad handling. thrown in some asserts where unexpected NULLs were showing up in gdb.
13:37.10CIA-49BRL-CAD: 03brlcad * r44942 10/brlcad/trunk/src/conv/iges/ (convtree.c iges_struct.h): MEMCHECK is only used in convtree.c so move from iges_struct.h; also simplify conditional so we can require a semicolon on use so formatting stays sane. cleanup.
14:01.35CIA-49BRL-CAD: 03Waters 07http://brlcad.org * r2919 10/wiki/User:Waters: New page: [http://www.speedmycomputer.net/ how can i speed up my computer]
14:23.50CIA-49BRL-CAD: 03brlcad * r44943 10/brlcad/trunk/include/raytrace.h:
14:23.50CIA-49BRL-CAD: add a new RT_INIT_COMB_INTERNAL initialization macro for initializing
14:23.50CIA-49BRL-CAD: rt_comb_internal structs. add a corresponding RT_FREE_COMB_INTERNAL() macro
14:23.50CIA-49BRL-CAD: since we do initialize the vls strings potentially allocating memory (might want
14:23.50CIA-49BRL-CAD: a bu_vls_init_empty() or vls INIT macro).
14:24.37CIA-49BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Waters]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
14:24.57CIA-49BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:Waters]]": content was: '[http://www.....net/ how can i speed up my computer]' (and the only contributor was '[[Special:Contributions/Waters|Waters]]')
14:27.57CIA-49BRL-CAD: 03brlcad * r44944 10/brlcad/trunk/src/ (12 files in 4 dirs): use the new RT_INIT_COMB_INTERNAL macro allowing us to make comb initialization consistent and consolidated into one place.
14:30.33brlcadbhinesley: any luck with the dbi_filepath issue?  I'm actually not seeing how that even comes into play during database open (supposed to be used to find resources like height field files, bitmaps, shader files, etc)
14:37.54CIA-49BRL-CAD: 03brlcad * r44945 10/brlcad/trunk/misc/Makefile.am: sort & sync. remove FindCocoa.cmake and FindCorbon.cmake, add util_macros.cmake.
14:59.32CIA-49BRL-CAD: 03davidloman * r44946 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/ (CmdConsolePanel.java JTextFieldWithHistory.java): Break out JTextField into custom subclass. Add cmd history.
15:10.34CIA-49BRL-CAD: 03starseeker * r44947 10/brlcad/trunk/src/other/iwidgets/generic/ (panedwindow.itk tclIndex): Stick in iwidgets panedwindow method and option that seem to be needed for RamDebugger...
15:11.24CIA-49BRL-CAD: 03davidloman * r44948 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (GSConnection.java msg/AbstractNetMsg.java): Make the java implementation AbstractNetMsg.java match NetMsg.cxx
15:11.47*** join/#brlcad Stattrav (~Stattrav@122.167.214.98)
15:11.47*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:15.08CIA-49BRL-CAD: 03davidloman * r44949 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NetMsgTypes.java: Update NetMsgTypes from C++ code.
15:42.02CIA-49BRL-CAD: 03davidloman * r44950 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/RemoteNodeNameSetMsg.java: Comment cleanup
15:42.38CIA-49BRL-CAD: 03davidloman * r44951 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (5 files): Implement a few more NetMsg types in java. More on the way.
15:47.09CIA-49BRL-CAD: 03starseeker * r44952 10/brlcad/trunk/src/other/tktreectrl/ (246 files in 21 dirs):
15:47.10CIA-49BRL-CAD: Early cut at a CMakeified tktreectrl widget. This and the next few commits are
15:47.11CIA-49BRL-CAD: only for the purposes of 'checkpointing' what I have managed to get working as
15:47.12CIA-49BRL-CAD: far as RamDebugger goes - not really functional as yet (the basic RamDebugger
15:47.17CIA-49BRL-CAD: window comes up, but that's about it), so I'll promptly remove it again - the
15:47.17CIA-49BRL-CAD: goal is to have what I did get in svn history if I can devote more resources to
15:47.17CIA-49BRL-CAD: it later.
15:53.12kunigamidloman: going well. By now I'm studying how to deal with recursive rays (reflection and refraction/transmission). will make some experiments here
16:02.33CIA-49BRL-CAD: 03starseeker * r44953 10/brlcad/trunk/src/other/ (672 files in 38 dirs):
16:02.33CIA-49BRL-CAD: Tweaked version of RamDebugger - diff with vanilla version 7.8 to see
16:02.33CIA-49BRL-CAD: differences. Removed a few extensions and there is more to remove, if this were
16:02.33CIA-49BRL-CAD: ever to be properly set up for what BRL-CAD needs - many features like cvs
16:02.33CIA-49BRL-CAD: aren't particularly important to us, for example... Changes here were done
16:02.34CIA-49BRL-CAD: using the enable-all-local-libs build options.
16:04.19kunigamiby the way, is there any variable that stores how many times a given ray hit an object (or its depth)?
16:04.31CIA-49BRL-CAD: 03starseeker * r44954 10/brlcad/trunk/src/other/ (CMakeLists.txt RamDebugger/ tktreectrl/): Checkpoint complete, restore previous src/other CMakeLists.txt logic and remove RamDebugger related directories.
16:05.36brlcadkunigami: you set up callbacks when you fire a ray for hit/miss that can perform that book-keeping, or you can make sure a_onehit is unset and you'll get back a partition list of all objects along that ray
16:08.45brlcadkunigami: http://brlcad.org/wiki/Example_Application shows the latter where it iterates over the partition list
16:12.51CIA-49BRL-CAD: 03davidloman * r44955 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (GeometryChunkMsg.java GeometryManifestMsg.java): Add GeometryManifest and GeometryChunk msgs to java
16:13.13CIA-49BRL-CAD: 03davidloman * r44956 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (PingMsg.java PongMsg.java): Add Ping and Pong to java
16:16.11CIA-49BRL-CAD: 03davidloman * r44957 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/ (DirListReqMsg.java DirListResMsg.java): Add DirectoryList request and response NetMsgs to java.
16:16.49CIA-49BRL-CAD: 03davidloman * r44958 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java: Update NetMsgfactory with all the recently implemented NetMsg subclasses.
16:17.11*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
16:18.11kunigamibrlcad: thanks! this example also shows how to setup the callback
16:20.03CIA-49BRL-CAD: 03bob1961 * r44959 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added the ability to create instances of ArcherCore with/without the treeview or the toolbar.
16:20.50CIA-49BRL-CAD: 03davidloman * r44960 10/geomcore/trunk/src/libNet/netMsg/NewNodeOnNetMsg.cxx: Update NetMsg type to correct one for this class.
16:21.47kunigamiif I understood it right, whenever it hits an object that function will be called. If, for example, a ray first hits an object A, the callback will be called with only object A. If this ray further hits an object B, them both A and B will be in that partition list?
16:21.51CIA-49BRL-CAD: 03davidloman * r44961 10/geomcore/trunk/src/utility/StringUtils.cxx: Fix incorrect type and cast.
16:26.03brlcadkunigami: it depends if onehit is set, but if unset then yes
16:26.32yukonbobhello, #brlcad
16:26.41brlcadhowdy yukonbob
16:26.53yukonbobhow're things?
16:28.46CIA-49BRL-CAD: 03bob1961 * r44962 10/brlcad/trunk/src/tclscripts/rtwizard/ (RaytraceWizard.tcl lib/MGEDpage.itk): Updates to use ArcherCore instead of Mged which has been deprecated.
16:29.20brlcadbusy
16:29.34brlcaddloman: how was the type incorrect?
16:29.36yukonbobexcellent!
16:29.57yukonbobhits website to see if there're published stories about recent(ish) goings-on...
16:30.39brlcadmaybe a complaint that bu_free() wasn't being passed a genptr_t (i.e., a void*), but making it const isn't technically correct
16:32.32brlcadstarseeker: hmmm
16:32.46brlcadadding RamDebugger is akin to adding gdb ... kinda odd
16:33.11brlcadmaybe a separate branch for 3rd party tools?
16:36.37yukonbobwhat's the RamDebugger for ?
16:41.00brlcadpresumably debugging tcl code
16:41.10brlcadit's a gui ide for tcl debugging
16:43.14starseekerbrlcad: I removed it - just wanted to stash it in history somewhere
16:43.47brlcadheh, okay
16:44.33starseekerbrlcad: ultimately it might be interesting to be able to debug tcl scripts "in MGED" or some such, but for the moment I can't even get the darn thing to debug ANYTHING
16:46.04starseekerI'm sure it'll do something once I finish widing through the "oh, this doesn't work either with this version" fun but even then I'm not sure how well it would do with incrTcl/iwidgets
16:46.46starseekermy annoyance threshold with debugging Tcl/Tk just hit a momentary peak - it'll fade back to normal background annoyance levels soon :-P
16:46.55yukonbobnotes theres also -DTCL_MEM_DEBUG, and the [mem] commands it presents...
16:47.57yukonbobstarseeker: Tcl loves you :)
16:48.34starseekeryukonbob: what I miss most is the ability to step through a tcl file line by line in an editor DDD style, examining variables and such and easily seeing which Tcl line ultimately triggered the latest framebuffer/display manager problem
16:49.25starseekerfeeding bwish into gdb does OK if the problem is in our C libraries, but if it's actually in the Tcl code...
16:49.31dlomanbrlcad: was supposed to be const char* instead of just char*
16:49.32yukonbobnods... a bit more involved than just memory consumption, ckalloc() guarding...
16:49.41dlomanbrlcad: and i missed a cast to void*
16:49.54yukonbobTclPro has what you're looking for, I think, but I haven't played w/ that part of Tcl dev...
16:50.02yukonbobis sure starseeker is on the case, though.
16:50.30starseeker<snort> the problem is Tcl/Tk problems of that nature are just rare enough that we can usually ignore them or have bob1961 track 'em down
16:51.04starseekerTclPro... isn't that the commerical one?  Or wasn't there some free version that hasn't been updated in a long long time?
16:54.55brlcaddloman: it's not supposed to be const char
16:55.08brlcadat least not if you're going to bu_free it (which the signature requires)
16:55.33dlomanokie
16:56.02brlcadthe cast to void* (i.e., genptr_t) is the only thing that might have provoked a warning, but the types should have been golden
16:57.03brlcadthe constness is broken by casting to void* anyways
16:57.49starseekerhah, cool:  http://labs.qt.nokia.com/2011/06/03/threaded-opengl-in-4-8/
16:58.27bhinesleybrlcad: not yet, I'm just starting for today. To answer your question: I don't think that it has anything to do with opening the database. It has to do with the CWD, which is apparently being used somewhere.
16:58.27bhinesleyWhen attempting to raytrace, we see the path "/CWD//full_path_to_.g/" being used (two absolute paths concatenated).
17:00.17brlcadyeah, i get the end-effect, and that the full-path cwd is presumably coming from dbi_fullpath .. but not how the order of search dirs [0] vs [1] would result in that
17:00.40bhinesleythat, I will have to figure out
17:01.01bhinesleygets to work
17:01.05brlcadI did a full search for dbi_fullpath and ... if it's the cause, I haven't quite seen how yet :)
17:01.29CIA-49BRL-CAD: 03davidloman * r44963 10/geomcore/trunk/src/utility/StringUtils.cxx: Cast the data from bu_basename to (char*) rather than passing around a (const char*)
17:02.25brlcadhmmm
17:02.41brlcadI think your header files are out of date, don't need a cast either :)
17:02.46brlcad(dloman)
17:03.15brlcadthat's probably the original problem
17:03.26dlomankk
17:04.07dlomanupdates
17:11.00starseekerO.o another one:  https://github.com/advancingu/Cutexture
17:12.55brlcadhttp://www.youtube.com/watch?v=b_3xfFuwGOQ
17:14.45starseekerbrlcad: yeah, saw that - quite promising
17:14.57starseekerthat's the experimental Qt5 apparently
17:15.12brlcadsame problem from a couple years ago though
17:15.17brlcadstill seems "backwards"
17:15.57starseekeryou mean ogre-in-Qt not Qt-in-Ogre?
17:16.05brlcadyeah
17:16.20brlcador both really since you still want qt widgets in the ogre context too
17:16.38brlcadbut that your main window is a qt window, not something ogre establishes
17:16.58starseekermaybe cutexture is set up more along those lines - I'll have to check
17:17.17starseekerusually the problem I have testing these suckers is getting Ogre working on my home box...
17:34.07yukonbobTrolltech ogre? Isn't there a rule against cross-fairytale creature misappropriation?
17:38.22bhinesleybrlcad: which argument is used for what seems to be explicit: if (argv[1][0] != '/')
17:39.19bhinesleyit tests to see if the second argument is an absolute path, but not the first
17:39.39bhinesleysorry, this is in db_open.c
17:53.32CIA-49BRL-CAD: 03starseeker * r44964 10/brlcad/trunk/ (5 files in 4 dirs): Downcase the openNURBS directory to just opennurbs - 'cause macros are easier when you don't have mixed case in the way.
17:55.39brlcadah, heh .. I was hunting down dbi_fullpath in other files and it hadn't even gotten out of db_open()!  I see now, it's trying to expand the full path for dbi_filename()
17:55.51brlcadwill rewrite that function, no worries -- thanks!
17:56.07bhinesleyoh alright! no problem.
17:56.40brlcadit was actually next in my queue to add a cwd routine to libbu anyways
18:02.40bhinesleybrlcad: should I keep working on migrating commands and fixing bugs for now, or should I start on the libged command registry? I'm not really sure where to start on the registry, so we might need to talk about it for a bit before I do.
18:03.13bhinesleyeither is fine for me
18:11.16*** join/#brlcad bhinesley_ (~bhinesley@99.144.90.118)
18:11.43bhinesley_brlcad: my machine locked up, so if you said anything i missed it
18:17.26starseekerbhinesley: he didn't yet
18:17.39bhinesleythanks :)
18:24.07brlcadbhinesley: I'd keep with the original plan for now, command migration, refactoring, and fixing
18:24.25bhinesleyok
18:25.30brlcadI've got something started for the registry, but am just a bit overtasked at the moment to dive down that path just yet
18:26.11brlcadnothing fancy to say the least, but the command work will be more immediately useful anyways
18:26.23bhinesleyOh, don't worry about it, I know you have a lot on your plate.
18:31.31CIA-49BRL-CAD: 03davidloman * r44965 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Comment clean up. Also added two methods that will need to be rolled into jBRLCAD's GemetryService Interface
18:32.48CIA-49BRL-CAD: 03davidloman * r44966 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSStatics.java: Remove libPKG remnants
18:33.43CIA-49BRL-CAD: 03brlcad * r44967 10/brlcad/trunk/ (TODO src/libged/typein.c): we allocate the idb_ptr so we know the vls is not initialized. call bu_vls_init() instead of bu_vls_init_if_uninit(). still warrants a quick test before the next release, though.
18:34.15CIA-49BRL-CAD: 03davidloman * r44968 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/AbstractNetMsg.java: Was incorrectly serializing using the old GSNetProto header. Removed the two MAGIC values and fixed the msgLen calculation.
18:35.36CIA-49BRL-CAD: 03brlcad * r44969 10/brlcad/trunk/src/ (conv/dxf/dxf-g.c mged/vrlink.c): make the vls a pointer so it can sometimes be NULL and we can test that for determining whether to initialize or not. call bu_vls_init() instead of the unreliable bu_vls_init_if_uninit().
18:36.21CIA-49BRL-CAD: 03brlcad * r44970 10/brlcad/trunk/src/mged/utility1.c: the tmp_vls isn't used outside the nested scope so pull it down to where it's used. there we know it's not initialized, so we can just call bu_vls_init().
18:37.15CIA-49BRL-CAD: 03brlcad * r44971 10/brlcad/trunk/src/ (libbu/parse.c librt/parse.c): if they're not initialized, it's an error in the caller's code. don't try to accommodate the error by initializing.
18:41.51CIA-49BRL-CAD: 03brlcad * r44972 10/brlcad/trunk/ (doc/deprecation.txt include/bu.h src/libbu/vls.c):
18:41.52CIA-49BRL-CAD: and with that, mark the silly inconsistent error-prone unreliable
18:41.52CIA-49BRL-CAD: bu_vls_init_if_uninit() function as deprecated. there needs to be an INIT macro
18:41.52CIA-49BRL-CAD: for bu_vls structs but bu_vls_init() is the better way to go. the problem stems
18:41.52CIA-49BRL-CAD: from memory not getting consistently initialized and/or reset to zero so that
18:41.52CIA-49BRL-CAD: the magic check would actually work. using a NULL pointer or caller-based init
18:41.53CIA-49BRL-CAD: flag are safer methods.
18:42.04CIA-49BRL-CAD: 03davidloman * r44973 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java:
18:42.04CIA-49BRL-CAD: Added a thread sleep in the GSConnection run loop to keep from hogging a CPU.
18:42.04CIA-49BRL-CAD: Fixed buffer size checking in tryMakeNetMsg(), it was incorrectly thinking there
18:42.04CIA-49BRL-CAD: was insufficient data to deserialize and bailing out. Also fixed waitForMsg()
18:42.05CIA-49BRL-CAD: as the totalRead parameter was not being reset after the loop was finished.
18:46.10CIA-49BRL-CAD: 03davidloman * r44974 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/CmdConsolePanel.java: Removed unused var from doCmd(). Was leftover from debugging.
18:47.00CIA-49BRL-CAD: 03davidloman * r44975 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java: Print the remote nodename to the GUI console upon successful connection.
18:51.05CIA-49BRL-CAD: 03davidloman * r44976 10/geomcore/trunk/ (include/PortalManager.h src/libNet/PortalManager.cxx): Make a difference between 'LocalNodeName' and the PortalManager object's name. LocalNodeName is the name of this PortalManager on the network while the other is simply the object's name used in Logging.
18:54.19CIA-49BRL-CAD: 03davidloman * r44977 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Eliminate duplicate fn.
19:04.07CIA-49BRL-CAD: 03starseeker * r44978 10/brlcad/trunk/src/other/opennurbs/CMakeLists.txt: bye bye mixed case
19:07.12CIA-49BRL-CAD: 03davidloman * r44979 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSNetMsgFutureResponse.java: Add a response handler for NetMsg that should envoke a response from server.
19:08.53brlcadstarseeker: if I recall correctly, mixed case on the product is what was in their original build files, so there is some value in preserving that trait
19:10.35brlcadfurther deviation from their source (with any benefit?) making it more complicated to swap in a system opennurbs down the road
19:12.34brlcadthe dir name is irrelevant, but the product name does have meaning (e.g., mixed case is highly indicative of C++ libs vs C libs .. a quick scan of any lib dir and the C++ ones are generally (conventionally) the ones with upper-case)
19:19.04CIA-49BRL-CAD: 0399.144.90.118 07http://brlcad.org * r2920 10/wiki/User:Bhinesley: /* Log */ Friday - Monday, plan today
19:24.36CIA-49BRL-CAD: 03brlcad * r44980 10/brlcad/trunk/include/bu.h:
19:24.36CIA-49BRL-CAD: implement BU_INIT_VLS() and BU_INIT_VLB() macros to initialize a vls/vlb struct
19:24.36CIA-49BRL-CAD: without allocating any memory. also, similar to the convention in vmath,
19:24.36CIA-49BRL-CAD: provide BU_VLS_INIT_ZERO/BU_VLB_INIT_ZERO macros suitable for declaration
19:24.36CIA-49BRL-CAD: statement initialization.
19:25.45brlcadbhinesley: tell me about ls
19:41.21*** join/#brlcad yiyus (2383vince@je.je.je)
19:55.11CIA-49BRL-CAD: 03davidloman * r44981 10/geomcore/trunk/src/libNet/ (Portal.cxx PortalManager.cxx): Make Portal/PortalManager respond to a RemNodeNameSet message rather than automatically sending its localNodeName.
19:55.28CIA-49BRL-CAD: 03brlcad * r44982 10/brlcad/trunk/include/bu.h: add BU_LIST_INIT_ZERO, BU_BITV_INIT_ZERO, and BU_INIT_BITV macros for api consistency (lots more to go)
19:55.51bhinesleybrlcad: I noticed that when you enter "ls not-an-obj" it would print "not-an-obj", which is misleading. I checked ArcherCore.tcl, and saw that it simply does "return \$expandedArgs" if you don't pass any options.
19:55.51bhinesleyI was trying to get the behavior that MGED has: if you do an 'ls is-an-obj not-an-obj', it returns something like "is-an-obj (\n ...) not-an-obj doesn't exist". This doesn't seem possible the way it works now, since we're not letting libged's ls command print it's error directly to the command line. If we want ::ls to print the error, it has to be all or nothing (failure or success), since a partial match in libged's ls simply returns GED_OK.
19:56.23CIA-49BRL-CAD: 03brlcad * r44983 10/brlcad/trunk/src/libbu/ (list.c malloc.c mappedfile.c temp.c): no longer need to manually init the bu_list or ignore init, call BU_LIST_INIT_ZERO instead.
19:57.11bhinesleyhopefully that made sense
20:08.43CIA-49BRL-CAD: 03brlcad * r44984 10/brlcad/trunk/include/bu.h: fix BU_INIT_BITV(). we need pointers to pass to BU_INIT_LIST(). group the bu_list init macros together better and add BU_INIT_LIST (which calls the existing BU__LIST_INIT that will soon go away).
20:09.00CIA-49BRL-CAD: 03brlcad * r44985 10/brlcad/trunk/src/libbu/bitv.c: initialize the BU_BITV properly instead of setting the magic manually.
20:41.42brlcadbhinesley: yes, that does make sense
20:42.18brlcadthat actually sounds like a prime example for consolidation so that they are identical
20:43.09brlcadso there's no expansion in mged or archer, that ged_ls() does all the work with the necessary information returned in the struct ged in some form that both can display suitably
20:44.06brlcadand of course sorting out what it means to have a partial failure from an api perspective
20:44.48brlcadI'd think partial failure is still a failure, not GED_OK for starters
20:44.53bhinesleyagreed
20:47.05brlcadthe issue then just becomes how to have ged_ls() add listings and failures to the results
20:47.33brlcadcould be time to sort out a proper result set instead of the dumb ged_result_str
20:48.21kunigamican I set the hit callback on the shader setup?
20:50.07brlcade.g., an array of types and values so that "ls valid invalid valid2" might return the set { {GED_OBJECT, "valid"}, {GED_ERROR, "ls: invalid: No such object"}, {GED_OBJECT, "valid2"} }
20:50.35brlcadkunigami: you can set the hit callback any time before rt_shootray() is called
20:51.56brlcadif you're in the shader, though, then that probably implies that a ray was already fired, hit callback was made, determined ther shader, and shader callback was made .. so you'd be firing another ray you set up
20:54.58kunigamitrue
20:55.24bhinesleybrlcad: does ::ls even need to know that much? Couldn't just the results be passed back from ged_ls?
20:55.47kunigamiit seems that the variable 'a_level' from application struct counts the depth of recursion. let me give it a try
20:57.43bhinesleyand by that, I mean one long string that is printed
20:58.25bhinesleyn/m... then we'd lose the ability to identify which part of it is an error
20:58.35bhinesleyfor logging and whatnot
20:58.36brlcadbhinesley: bingo
20:58.44brlcadI mean for now, that'd be an improvement
20:59.16brlcadbut the goal is to make the return from the ged_*() functions be programmatic
21:00.12brlcadso I could write a program that uses ged_ls() to lookup objects, iterate over them and call other functions etc
21:00.57brlcador in the case of mged/arhcer, maybe I want to return the list of objects as a proper list and print the error (interleaved and color-coded) to stderr
21:02.42bhinesleyI understand; I was thinking about it from the perspective of tcl code duplication. It'd be nice if there was a mechanism for using the same call to ged_ls for both programs... like how I kinda forced that with ManBrowser.
21:02.54bhinesleythat would prevent problems like this from occurring in the first place
21:04.25CIA-49BRL-CAD: 03brlcad * r44986 10/brlcad/trunk/ (21 files in 12 dirs):
21:04.25CIA-49BRL-CAD: replace BU_LIST_UNINITIALIZED() with !BU_LIST_IS_INITIALIZED() as a minimally
21:04.25CIA-49BRL-CAD: impacting API change. BU_LIST_UNINITIALIZED() is unnecessary with the other and
21:04.26CIA-49BRL-CAD: inconsistent with the API (the only *_uninitialized macro of its kind). reduce,
21:04.26CIA-49BRL-CAD: reuse.
21:05.07bhinesleyshrugs
21:21.06starseekerbrlcad: uh... we're writing our own build logic for opennurbs anyway...
21:22.33starseekerbrlcad: at this point I'm very doubtful we'll ever be able to use a system opennurbs
21:23.01*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593767.dsl.bell.ca)
21:23.19starseekerI'll revert it if you want and try to find another way to do what I had in mind...
21:27.08CIA-49BRL-CAD: 03bhinesley * r44987 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Temporary fix for ::ls to stop echoing nonexistant objects.
21:29.23brlcadstarseeker: it should probably still be our goal, not intentionally move away with a fork
21:29.32brlcadif only to minimize differences the next time we sync
21:29.56brlcadthat one in particular, though, gets at the convention issue and the "name" of the library
21:31.28starseekerbrlcad: I'm not sure I agree about forking, but I'll revert the name downcasing (working on it now)
21:33.50*** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593767.dsl.bell.ca)
21:35.16*** join/#brlcad bhinesley_ (~bhinesley@99.144.90.118)
21:35.43*** join/#brlcad bhinesley_ (~bhinesley@99.144.90.118)
21:36.31CIA-49BRL-CAD: 03starseeker * r44988 10/brlcad/trunk/ (501 files in 11 dirs): Revert r44964
21:46.50brlcadstarseeker: I still think it's entirely possible to get a pristine openNURBS working, to move back towards the original goal of having a proper layer on *top* of opennurbs for our added functionality
21:47.09brlcadmaybe that overlay is your libnurbs project
21:47.44brlcadanything else is going to have an ongoing maintenance cost that, well, will suck more and more over time
21:48.47brlcadcurious though -- what prompted that onto your radar to change it?
21:49.16starseekerI'm playing games with CMake macros to get the distcheck filelists out of src/other/CMakeLists.txt
21:49.51starseekerI was using some toupper and tolower logic in macros - it may not be strictly necessary though, so I'm going to revisit those macros
IRC log for #brlcad on 20110615

IRC log for #brlcad on 20110615

00:27.56*** join/#brlcad crazy_imp (~mj@a89-182-252-199.net-htp.de)
02:24.16CIA-49BRL-CAD: 03brlcad * r44989 10/brlcad/trunk/src/libbu/vls.c: make sure the string actually has allocated memory befor trying to set a sanity char
02:40.45CIA-49BRL-CAD: 03brlcad * r44990 10/brlcad/trunk/include/bu.h: the func is bu_vls_init(), the macro is BU_INIT_VLS()
02:43.21CIA-49BRL-CAD: 03brlcad * r44991 10/brlcad/trunk/include/raytrace.h: call BU_INIT_VLS() instead of bu_vls_init() here so we can avoid memory allocation
03:51.34CIA-49BRL-CAD: 03brlcad * r44992 10/brlcad/trunk/include/raytrace.h: better comment wording. the struct itself isn't freed so don't say memory is released. callers still need to call bu_free().
03:54.25*** join/#brlcad CIA-49 (~CIA@cia.atheme.org)
04:11.53*** join/#brlcad CIA-68 (~CIA@cia.atheme.org)
04:14.27CIA-68BRL-CAD: 03brlcad * r44995 10/brlcad/trunk/include/bu.h: not necessarily deprecated just yet. we may want to use RT_type_INIT() instead of RT_INIT_type
04:14.27CIA-68BRL-CAD: 03brlcad * r44994 10/brlcad/trunk/src/mged/utility1.c: vls overkill, just interpret the help command directly
04:14.27CIA-68BRL-CAD: 03brlcad * r44993 10/brlcad/trunk/src/librt/comb/db_comb.c: simplify. call RT_FREE_COMB_INTERNAL() instead of manually managing the struct members.
07:01.47*** join/#brlcad merzo (~merzo@193.254.217.44)
11:33.57CIA-68BRL-CAD: 03davidloman * r44996 10/geomcore/trunk/ (include/Session.h src/GS/Session.cxx): Make Session::generateSessionInfoMsg() take an optional 'reply' message as an arg. This allows for proper RegardingUUID setting in generated msg.
11:34.57CIA-68BRL-CAD: 03davidloman * r44997 10/geomcore/trunk/src/GS/SessionManager.cxx: Pass the NewSessionRequestMsg as an arg to the SessionInfoMsg construction in Session::generateSessionInfoMsg()
12:27.11CIA-68BRL-CAD: 03brlcad * r44998 10/brlcad/trunk/ (include/bu.h src/libbu/bitv.c):
12:27.11CIA-68BRL-CAD: continue moving towards API consistency and completeness. start making sure all
12:27.11CIA-68BRL-CAD: structs have a common set of macros: BU_[type]_INIT(), BU_[type]_INIT_ZERO,
12:27.11CIA-68BRL-CAD: BU_[type]_NULL, along with a few others. ensure there's a NULL and typedef as
12:27.11CIA-68BRL-CAD: well (even though those may be eliminated down the road). expand doxygen docs
12:27.12CIA-68BRL-CAD: while we're at it finishing up bu_list, bu_bitv, and bu_hist for starters.
12:36.00CIA-68BRL-CAD: 03brlcad * r44999 10/brlcad/trunk/include/bu.h: fill out bu_ptbl macros and typedef
12:42.39CIA-68BRL-CAD: 03brlcad * r45000 10/brlcad/trunk/include/bu.h: fill out bu_mapped_file macros and typedef, fix ptbl typedef typo
12:48.08CIA-68BRL-CAD: 03davidloman * r45001 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/ (GSJavaInterface.java net/GSConnection.java): Rework error handling on connectToHost() fns. Had to create a custom class to handle all the possible return values. (This is where callbacks or pointers would have been nice to have!)
12:50.28CIA-68BRL-CAD: 03davidloman * r45002 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (4 files in 2 dirs): Clean up Exception printing. Helps in tracking down bugs. Lots of future clean up here!
12:50.47CIA-68BRL-CAD: 03brlcad * r45003 10/brlcad/trunk/src/libbu/ (globals.c hook.c): just use NULL instead of BU_HOOK_NULL
12:51.02CIA-68BRL-CAD: 03brlcad * r45004 10/brlcad/trunk/include/bu.h: expand bu_hook_list macros, remove BU_HOOK_NULL
12:51.51CIA-68BRL-CAD: 03davidloman * r45005 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/cmd/LoginCmd.java: Cascading changes from connectToHost(). It no longer returns a simple boolean. Instead it returns an int with informational error/return codes.
12:53.46CIA-68BRL-CAD: 03davidloman * r45006 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/cmd/ (CmdManager.java ListCmd.java LogoutCmd.java): Implement ListCmd and LogoutCmd
12:56.00CIA-68BRL-CAD: 03davidloman * r45007 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/CmdConsolePanel.java: More exception cleanup.
12:56.59CIA-68BRL-CAD: 03davidloman * r45008 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Forgot to remove a debugging statement
12:57.20CIA-68BRL-CAD: 03davidloman * r45009 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Import cleanup
13:03.51CIA-68BRL-CAD: 03brlcad * r45010 10/brlcad/trunk/include/bu.h: include some clarity that all of the structs that include list elements are still expected to have a list head node, which should have a magic type of BU_LIST_HEAD_MAGIC.
13:11.25CIA-68BRL-CAD: 03brlcad * r45011 10/brlcad/trunk/include/bu.h: add avs macros and typedef
13:16.04CIA-68BRL-CAD: 03brlcad * r45012 10/brlcad/trunk/include/bu.h: api is starting to stabilize, convention is now BU_[type]_INIT() so change BU_INIT_VLS() to BU_VLS_INIT().
13:18.40CIA-68BRL-CAD: 03brlcad * r45013 10/brlcad/trunk/include/raytrace.h: update the one place where BU_INIT_VLS() was being called too.
13:18.50CIA-68BRL-CAD: 03brlcad * r45014 10/brlcad/trunk/include/bu.h: update vlb the same
13:31.09kunigamiI'll take the rest of the week studying the feasibility of using a brl-cad shader as an interface to osl system. The example @brlcad  showed me made me think that implementing a stand-alone application for osl would be feasible.
13:33.32CIA-68BRL-CAD: 03brlcad * r45015 10/brlcad/trunk/include/bu.h:
13:33.33CIA-68BRL-CAD: expand bu_structparse macros and typedef. since this struct has no magic,
13:33.33CIA-68BRL-CAD: BU_STRUCTPARSE_IS_INITIALIZED() can only check whether the pointer is non-null.
13:33.33CIA-68BRL-CAD: that's a reminder to make sure all the others are non-null before we dereference
13:33.33CIA-68BRL-CAD: too.
13:45.25CIA-68BRL-CAD: 03brlcad * r45016 10/brlcad/trunk/include/bu.h: can't just check the pointer for truthfulness since static variables will always return true. fake out the compiler via a pointer cast and comparison to NULL.
14:00.44brlcadaaand we pause there since bu_external is a bit of a doosie
15:09.48dloman``Erik: you around?
15:10.29dloman``Erik: Well, whenever you are, check this out.  kinda neat: http://www.dennisantinori.com/Resources/Ringworld/
15:44.16dlomanwow, there's a Lego CAD app:  http://www.ldraw.org
15:44.18dlomanawesome
16:19.27CIA-68BRL-CAD: 03brlcad * r45017 10/brlcad/trunk/src/libbu/CMakeLists.txt: sync. add basenametester compilation.
16:32.05CIA-68BRL-CAD: 03starseeker * r45018 10/brlcad/trunk/ (6 files in 4 dirs): This is an intermediate phase and I doubt it's working, but I need to checkpoint - reworking distcheck logic to be cleaner, more robust, etc.
16:40.17*** join/#brlcad bhinesley (~bhinesley@99.144.90.118)
16:48.54brlcadstarseeker: what's the equivalent of noinst_BINARIES ?
16:51.38CIA-68BRL-CAD: 03brlcad * r45019 10/brlcad/trunk/NEWS: past tense rewrite. cliff fixed a bug in archer's tree view widget to highlight related objects.
16:59.59*** join/#brlcad bhinesley (~bhinesley@99.144.90.118)
17:01.21CIA-68BRL-CAD: 03brlcad * r45020 10/brlcad/trunk/NEWS: brandon improved the ls command error reporting in archer where before it wouldn't report an error for partial failures if you 'ls valid invalid'. now it at least displays the lookup failure.
17:06.07bhinesleybrlcad: actually, it doesn't display an error in Archer, it just doesn't echo invalid names anymore. The problem with returning the error in the struct ged's return string, is that mged would display the error, too... so it would break any scripted uses of ls.
17:07.18bhinesleyplus, I'd have to to a quiet db_lookup, so that mged didn't show two error messages.
17:07.29bhinesley*to do
17:10.53*** join/#brlcad Stattrav (~Stattrav@122.167.214.98)
17:10.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:19.43CIA-68BRL-CAD: 03davidloman * r45021 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ByteBufferReader.java: Make the ByteBuffer copy in the ByteBufferReader cstr optional. Reduces the amount of mallocs significantly.
17:21.05brlcadbhinesley: ah, okay -- misunderstood your commit message
17:21.43brlcadfortunately the news line itself is vague enough that it still applies
17:21.48bhinesleynods
17:21.55brlcadit's improved, just not the way the comment says ;)
17:32.47CIA-68BRL-CAD: 03brlcad * r45022 10/brlcad/trunk/doc/deprecation.txt:
17:32.47CIA-68BRL-CAD: unlike the other lists, finding the latest minimally impacting change needs to
17:32.47CIA-68BRL-CAD: be deterministic. so list them in chronological order so the most recent are at
17:32.47CIA-68BRL-CAD: the end of the file. the same doesn't hold true for the incompatible changes so
17:32.47CIA-68BRL-CAD: leave them in reverse chrono order.
17:38.05CIA-68BRL-CAD: 03brlcad * r45023 10/brlcad/trunk/doc/deprecation.txt: with the list now in chrono order, go ahead and add the massive 6.0 release API overhaul (sed script lines)
17:39.14CIA-68BRL-CAD: 03brlcad * r45024 10/brlcad/trunk/include/ (Makefile.am sed4): the old sed4 script is no more. see doc/deprecation for the goods and additional API changes.
17:53.55CIA-68BRL-CAD: 03brlcad * r45025 10/brlcad/trunk/doc/deprecation.txt:
17:53.55CIA-68BRL-CAD: BU_INIT_EXTERNAL() to be renamed to BU_EXTERNAL_INIT() so the API is consistent.
17:53.55CIA-68BRL-CAD: same for RT_INIT_DB_INTERNAL. both have been around for a long while, so some
17:53.55CIA-68BRL-CAD: external code updates shold be expected. alas, they are still minimally
17:53.55CIA-68BRL-CAD: impacting API changes.
17:56.50CIA-68BRL-CAD: 03davidloman * r45026 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/NetMsgFactory.java: Remove try/catch block from NetMsgFactory.makeMsg() We want any exceptions to be thrown to the caller of NetMsgFactory.makeMsg() so they can deal with it appropriately.
17:59.44CIA-68BRL-CAD: 03Sean 07http://brlcad.org * r2921 10/wiki/Community_Publication_Portal: as more API changes are made, we'll need to talk about the deprecation process
18:00.53CIA-68BRL-CAD: 03brlcad * r45027 10/brlcad/trunk/ (25 files in 13 dirs):
18:00.53CIA-68BRL-CAD: rename BU_INIT_EXTERNAL() to BU_EXTERNAL_INIT() so that the API is consistent.
18:00.53CIA-68BRL-CAD: as this symbol is so frequently used, it's likely to affect external codes but
18:00.53CIA-68BRL-CAD: the change is still minimally impacting and trivial to accommodate.
18:09.20CIA-68BRL-CAD: 03starseeker * r45028 10/brlcad/trunk/src/other/dlists/ (19 files): Whoops - helps to commit everything.
18:09.42starseekerbrlcad: erm.  what did noinst_BINARIES do?
18:10.47starseekerif you want to build a binary that you're not wanting to install, just do add_executable followed by target_link_libraries
18:11.33starseekertake a look at htester and timetester in libbu
18:14.07CIA-68BRL-CAD: 03brlcad * r45029 10/brlcad/trunk/ (5 files in 4 dirs): rename RT_CK_DBTR and RT_DBTR_MAGIC to RT_CK_DB_TRAVERSE and RT_DB_TRAVERSE_INIT for api consistency.
18:19.32CIA-68BRL-CAD: 03brlcad * r45030 10/brlcad/trunk/doc/deprecation.txt: last jump, renaming all of the RT_INIT_[type] macros to RT_[type]_INIT for API consistency. this unfortunately affects a LOT of code (including 3rd party) but it's minimally impacting and improves the API.
18:21.25*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
18:24.10CIA-68BRL-CAD: 03brlcad * r45031 10/brlcad/trunk/doc/deprecation.txt: RT_INIT_DB_INTERNAL is included in the more general case so remove it
18:27.41CIA-68BRL-CAD: 03brlcad * r45032 10/brlcad/trunk/ (93 files in 32 dirs): API consistency overhaul. all struct INIT routines are now all RT_[type]_INIT() instead of being a mix of INIT before and after the type. 's/RT_INIT_([A-Z_]*)/RT_\1_INIT/g'
18:28.20CIA-68BRL-CAD: 03brlcad * r45033 10/geomcore/trunk/ (5 files in 3 dirs): update to the API changes on trunk for libbu and libbn. INIT now trails the type. you'll have to update your installed brlcad headers for this one.
18:30.56CIA-68BRL-CAD: 03davidloman * r45034 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/msg/NetMsgChangeTracker.java: Loosen restrictions on NetMsgChangeTracker. Make it a simple data container. Shift from using byte to int for change value. No need to optimize memory useage quite yet.
18:31.03CIA-68BRL-CAD: 03brlcad * r45035 10/brlcad/trunk/misc/Doxyfile: BU_EXTERN is no more
18:31.40CIA-68BRL-CAD: 03brlcad * r45036 10/geomcore/trunk/doc/doxygen/Doxyfile.in: BU_EXTERN is no more
18:32.57brlcadstarseeker: it does exactly what you described, builds but doesn't install -- so then what do I add to install it in addition to add_exec and target_link_.. ?
18:35.15brlcadmmmmee no likie the .dist files .. that's even more error prone than how we do it for autotools...
18:36.21brlcadshould at least be localized to each dir's CMakeLists.txt file akin to EXTRA_DIST, not in some remote dir (out of sight, out of mind)
18:36.50brlcadbetter would be to pull the svn manifest
18:37.09starseekerI'm trying to set this up so we don't have to put anything extra in the src/other directory in cases where the src/other directory has its own CMakeLists.txt file
18:38.06starseekerpreviously everything was in src/other/CMakeLists.txt, which was really messing with the readibility of that file
18:38.15brlcadis the problem because there's just one CMakeLists.txt file for all of the src/other targets?
18:38.46starseekerno - the problem is we can't count on src/other CMake logic to give us what we need for distcheck
18:39.58starseekerI have been working very hard with the src/other design to get as close as I possibly can to being able to just "drop in" a CMakeified src/other library and have it "just work"
18:40.17brlcadthe problem is the separation of the file list from the actual files .. instantly out of sync and the dev can't really be faulted for missing it
18:40.46starseekermake distcheck will show it instantly (first thing checked, in fact)
18:41.07brlcadwhat about at least making the files more visible?
18:41.20starseekerhow-so?  store them toplevel in src/other?
18:41.22brlcadmv dlists/*.dist .
18:41.28starseekerI did that initially, but it seemed messy
18:41.28brlcadmake the file name match the dir name
18:41.46brlcadit is messy, but less error prone
18:41.53starseekershrugs - sure, not a problem
18:42.02brlcadhopefully reminded every time you cd into a dir to add/update a file that there is a dist list that probably needs updating
18:42.14starseekernods
18:44.12brlcaddoes distcheck look at the svn manifest to compare then?
18:44.56starseekernot in that stage
18:45.06starseekerit's using the CMake build logic itself
18:45.14brlcadhow does it know when something is missing?
18:46.20starseekerthere's an error routine that reports when you try to ignore something that isn't present, and CMake itself wipes out if you try to call out a file in the build logic that isn't there
18:46.45brlcadunrelated, was the 7.20.0 windows release made with cmake or the msvc files?  someone asking if step-g is included
18:46.49starseekerI was assuming we wanted it to function without svn...
18:47.23starseekerCMake, but step-g doesn't build on Windows right now
18:47.30starseeker(that depends on the flex/byacc stuff)
18:47.56starseekerThat's high on my todo list, once I get my current mess cleaned up
18:48.57starseekerbrlcad: I'm in-process on reworking the distcheck logic - I didn't really want to commit yet, but it was getting too complex to keep going without some sort of checkpoint - I'll give a shout-out when it looks ready for testing
18:50.24brlcaddefinitely should work if SVN isn't available, but doesn't mean it can't leverage when it clearly is available too
18:51.10brlcadthat's what autotools distcheck does now (see dist-hook: in top-level Makefile.am, first line)
18:51.46CIA-68BRL-CAD: 03starseeker * r45037 10/brlcad/trunk/ (40 files in 4 dirs): move the dist lists to src/other toplevel.
18:51.57brlcadbasically, for any entries files it finds (i.e., manifest files), make sure the files listed are in the dist
18:51.59starseekerbrlcad: I've got two separate checks - one to see if the build logic covers the files, and then (if svn is available) to see if svn status reports anything
18:52.22brlcadsvn status?
18:52.32starseekerchecks for un-committed changes
18:52.37brlcadhm, ok
18:52.39starseekeror files svn doesn't know about
18:52.54brlcadI always have dozens or hundreds of those, works in progress
18:53.28starseekerthe assumption is that for a tarball build a clean checkout will be used - CPack grabs everything not on it's exclude list
18:53.59brlcadthat'll take some getting used to
18:54.53starseeker's take on it was that it's way simpler to do a clean checkout and use that than to try and maintain all the logic to sort out what should and shouldn't be included from a working tree
18:55.26brlcadsimpler, sure .. but much more time consuming :)
18:55.45starseekerreally?  for me a clean tree checkout is a drob in the bucket compared to the rest of the checklist
18:56.19starseekerI usually do it anyway just to try and make sure I haven't messed up getting something in to svn
18:57.12brlcadwell that's why it's also important to make the dist, then do distchecks on the dist tarball since that's what's actually uploaded
18:57.25brlcadthat's my "clean checkout" there
18:57.52brlcadno extra download, I should test the final build regardless
19:00.32brlcadno matter, the bigger issue is that we make sure all files that are in a checkout are in the dist (including simple doc/text files that aren't listed in build rules) -- however that happens
19:01.00starseekernods - let me finish ironing out the bugs of this rework and I'll volunteer it for a stress test
19:02.09brlcadpulling the manifest is the easiest (only?) way to ensure files get included
19:02.14brlcadnods
19:09.43CIA-68BRL-CAD: 03starseeker * r45038 10/brlcad/trunk/src/other/dlists/: remove dlists dir
19:10.55brlcadstarseeker: new files missing from src/other/Makefile.am  :)  ... have to maintain both just a while longer
19:12.09CIA-68BRL-CAD: 03starseeker * r45039 10/brlcad/trunk/src/other/togl/demo/CMakeLists.txt: rather than turning this off completely, disable it on WIN32 for now. Should eventually fix this
19:13.24starseekerbrlcad: yeah, I know - figured I'd update those when the dust settles
19:16.24brlcadonly mentioning it because it'll halt my build testing in the meantime -- I have a continuous distcheck build loop going for all of the API changes I've been making
19:16.40brlcadlots more to go, so it helps make sure I don't accidentally break the build for more than a few minutes
19:18.26starseekerwinces - sorry
19:20.55*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
19:25.12dlomanoh dayum: http://www.youtube.com/watch?v=PNFAsKwCCHw&feature=feedrec_grec_index
19:40.48brlcadbhinesley: if you're looking for a refactoring, merging erase and erase_all into one command would be a good one
19:41.28brlcadthe latter as an option to the prior, unify syntax
19:42.08bhinesleyalright, that sounds good. I'm trying to see what migrating oed is going to take right now.
19:42.39starseekerbhinesley: heh - watch out for that one
19:42.48bhinesleyer rather, oed-related translations, since we want it stateless
19:43.41bhinesleystarseeker: yeah, I'm starting to wonder what I got myself into  :)
19:43.56starseekerbrlcad: hrm.  how did you want to see oed translated into Archer, now that I think about it?
19:44.28brlcadkunigami: how's it going?  progress on the crashes?
19:45.25brlcadfwiw, memory leaks don't generally lead to crashes -- overrunning bounds and resource contention do, though
19:46.21brlcadstarseeker: oed becomes a standard set of options for the translate, rotate, and scale commands
19:46.34brlcadso oed itself doesn't migrate, but what it does .. does
19:46.44brlcadi.e., sets up a selection and a keypoint
19:47.32CIA-68BRL-CAD: 03starseeker * r45040 10/brlcad/trunk/ (8 files in 8 dirs): Hmm. OK, that's promising - distcheck called out some files that, upon examination, make sense. This might do it, but needs a LOT more checking/hammering.
19:48.00brlcadoed itself might just turn into a simple keypoint option
19:51.43kunigamibrlcad: I kinda ignored the crashes by now, since it seems to be a multi-thread issue. I've been using P=1 and no problems happened until now
19:57.42CIA-68BRL-CAD: 03starseeker * r45041 10/brlcad/trunk/src/other/ (URToolkit.dist step.dist): couple dist additions that got swatted in the move.
19:57.44brlcadignoring syntax and whatever the current code does, you basically have:  {translate|rotate|scale} [--keypoint {bb_corner|bb_center}:{object_name} | {3d position}] [--relative xdist [ydist [zdist]] | --absolute xpos [ypos [zpos]]] [object(s)]
19:58.45brlcadnot exact, of course, since rotate is relative or absolute angles or ypr or aet and scale is relative or aboslute scale factors
19:59.19brlcadbut oed is basically that --keypoint option
20:00.12brlcadspecifically one subset where it's bb_default which is usually the bottom left corner of the object
20:00.49brlcador some other "natural" origin
20:01.42brlcadkunigami: ah, okay .. so then if you got a disk shaded using your yellow osl shader, what happens if you set it to one of the other default osl shaders?
20:02.22kunigamiI tried using the mirror shader, but I renders to black, but I'm not doing recursion right
20:02.45brlcadouch
20:02.48brlcadwouldn't start with mirror :)
20:02.51brlcadtry something diffuse :)
20:03.26brlcadthey have a phong or gouraud shader?
20:04.00kunigamithe yellow shader was a (perfect) diffuse one
20:04.32kunigaminow, I don't have such shader, but I can research about
20:05.22brlcadbasically implemented a flat shader, not really diffuse
20:05.45brlcadif it were a curved surface, you should get highlight and shadow with diffuse
20:06.19brlcadI wouldn't spend time implementing shaders .. iirc, they had five or six example shaders
20:07.17kunigamithe yellow shader is the same from the sphere of this image: http://kuniga.files.wordpress.com/2021/05/image.png
20:07.39kunigamimaybe I'm not setting up the global parameters (normal, incident ray) correctly
20:07.51kunigamiI'll  try assigning it to a sphere
20:09.17CIA-68BRL-CAD: 03brlcad * r45042 10/brlcad/trunk/include/raytrace.h: DBTR got expanded to DB_INTERNAL, no good. expand to DB_TRAVERSE.
20:11.47brlcadlooks like some sort of path trace
20:12.26brlcadwe have a cornell box in the db directory iirc, so you can play with similar scenes
20:12.42brlcadif not, it's trivial to set one up
20:13.07CIA-68BRL-CAD: 03starseeker * r45043 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: Remove debug messages
20:15.30kunigamiyeah, I added a sphere to the scene, but it was rendered as a yellow circle >.<
20:16.19kunigamigotta take a look at the parameters. just for clarification: u and v and their dP/du and dP/dv are only useful if we're going to do some kind of mapping, right?
20:16.53brlcadyes for u/v .. what's the dP/du you're referring to?
20:17.37brlcadthe normal isn't necessarily calculated by default -- you'll probably need that to calculate a diffuse falloff
20:17.38kunigamias far as I understood P is the hit point and dP/du are the derivatives regarding u and v directions
20:18.05kunigamihmm, I was setting the normal from  swp->sw_hit.hit_normal
20:19.00brlcadI'd make sure that value has been calculated, you may need to call RT_HIT_NORMAL()
20:20.06kunigamiI added MFI_NORMAL on mfuncs, but I'll double check
20:20.32brlcadah, and for the other, yes -- those are all curvature related values, for texture/image mapping
20:20.41brlcadah, okay
20:24.26starseekerbrlcad: ERROR: bad pointer 0xd7fc488: s/b bu_vls(x89333bbb), was Zero_Magic_Number(x0), file src/libbu/vls.c, line 301
20:24.41starseekershaders regression test
20:26.55brlcadbacktrace?  there was a couple places in the code that were calling BU_VLS_INIT_IF_UNINIT() unreliably, may need an explicit BU_VLS_INIT() now
20:27.13starseekerlet me see if I can generate one, hang on...
20:27.21brlcadit should have auto-dumped one
20:27.25brlcadbomb.log
20:29.41starseekerhmm - don't see it
20:29.44starseekerone sec...
20:30.31CIA-68BRL-CAD: 03brlcad * r45044 10/brlcad/trunk/TODO: merge erase/erase_all and notes on oed migration
20:30.35brlcad*-bomb.log
20:31.40brlcadkunigami: you may also need an osl light source for proper calcs, don't know
20:31.48brlcadI do recall an emitter shader for lights
20:38.25starseekerdoesn't seem to be dropping a bomb log
20:38.29brlcadk
20:46.07*** join/#brlcad CIA-62 (~CIA@cia.atheme.org)
20:49.33starseekerfeeding anything at all after the <<EOF seems to trigger the crash - not specific to any one command
20:49.50starseeker(in shaders.rt)
20:50.00*** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net)
20:51.58starseekerah hah
20:51.58CIA-62BRL-CAD: 03brlcad * r45045 10/brlcad/trunk/src/libdm/dm-ogl.c: GL/gl.h needs the same protection as glx.h did. encountered y1 shadow warnings on mac 10.5, gcc4.0.1
20:52.42CIA-62BRL-CAD: 03brlcad * r45046 10/brlcad/trunk/src/mged/dm-ogl.c: GL headers need the same protections used in libdm's dm-ogl.c file so we don't get shadow warnings and compilation failure.
20:55.10starseekerbrlcad: here we go:  http://pastebin.mozilla.org/1250287
20:56.00CIA-62BRL-CAD: 03brlcad * r45047 10/brlcad/trunk/src/libdm/focus.c:
20:56.00CIA-62BRL-CAD: may need revisiting, but unsetting and resetting __GNUC_MINOR__ (gcc 4.0.1, mac
20:56.00CIA-62BRL-CAD: 10.5) leaves the compiler in some odd state where subsequent header inclusion
20:56.00CIA-62BRL-CAD: still think it is undefined (even though #ifdef before their inclusion shows it
20:56.00CIA-62BRL-CAD: is!). removing the protections makes things work again so will have to
20:56.00CIA-62BRL-CAD: rediscover a different fix for whatever environment was failing if it still
20:56.01CIA-62BRL-CAD: fails.
21:28.11*** join/#brlcad merzo (~merzo@48-55-133-95.pool.ukrtel.net)
21:29.51kunigamibrlcad: the parameters seems right. the problem, I think, comes from the fact that I'm not considering recursion. The osl-system returns only the color of the sphere, but I think the attenuation will depend on the ray going out towards the light and the sphere normal
21:54.42*** join/#brlcad crazy_imp (~mj@a89-182-252-199.net-htp.de)
22:33.51CIA-62BRL-CAD: 03brlcad * r45048 10/brlcad/trunk/src/libbu/brlcad_path.c: can't bu_free() a static buffer. supposed to be tmp_basename from bu_basename().
22:59.32*** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862)
23:01.25CIA-62BRL-CAD: 03brlcad * r45049 10/brlcad/trunk/src/libbu/basenametester.c: quell warning, call bu_fgets() instead of calling fgets() directly.
23:08.38CIA-62BRL-CAD: 03bhinesley * r45050 10/brlcad/trunk/ (13 files in 8 dirs):
23:08.39CIA-62BRL-CAD: Removed all occurences of erase_all command and the dall alias. The same
23:08.39CIA-62BRL-CAD: operation is now performed by "erase -r". Usage statement corrected to no longer
23:08.39CIA-62BRL-CAD: print first arg instead of cmd name. Fixed ArcherCore::erase that was using
23:08.39CIA-62BRL-CAD: lappend without initialization. Updated NEWS.
23:09.35bhinesleyhm. it says that the commit failed
23:23.53bhinesleygood god sf, it's one line, commit already
23:26.47CIA-62BRL-CAD: 03bhinesley * r45051 10/brlcad/trunk/src/libged/erase.c: Revised usage statement to make it clear that if -r is specified, all other options are ignored.
23:27.50bhinesleyputs away the plunger
23:42.14*** join/#brlcad piksi_ (piksi@pi-xi.net)
23:42.18*** join/#brlcad dloman_ (~claymore@BZ.BZFLAG.BZ)
23:43.08CIA-62BRL-CAD: 03brlcad * r45052 10/brlcad/trunk/regress/shaders.sh: document in detail why shaders must run single-threaded (it's because of the random transparency shader). also pass extra parameters normally -- no need for them to be in the rt script file.
23:44.51CIA-62BRL-CAD: 03brlcad * r45053 10/brlcad/trunk/src/liboptical/sh_prj.c:
23:44.52CIA-62BRL-CAD: fix the uninitialized vls bug reported by starseeker. indeed, the source name
23:44.52CIA-62BRL-CAD: of the shader was not being initialized properly before bu_structparse expands a
23:44.52CIA-62BRL-CAD: %V table entry and calls bu_vls_strcpy(). instead of just initializing the vls,
23:44.52CIA-62BRL-CAD: though, go ahead and initialize the entire img_specific struct just because it's
23:44.53CIA-62BRL-CAD: the awesome thing to do. profile showed performance unaffected by the setup
23:44.54CIA-62BRL-CAD: memcpy().
23:52.13*** part/#brlcad bhinesley (~bhinesley@99.144.90.118)
23:52.20*** join/#brlcad bhinesley (~bhinesley@99.144.90.118)
23:59.59*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
23:59.59*** join/#brlcad dtidrow (~dtidrow@c-68-60-53-123.hsd1.mi.comcast.net)
IRC log for #brlcad on 20110616

IRC log for #brlcad on 20110616

00:24.28*** join/#brlcad Stattrav (~Stattrav@117.192.129.172)
00:24.32*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
00:28.53*** join/#brlcad crazy_imp (~mj@89.182.175.97)
00:49.32*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
03:45.01CIA-62BRL-CAD: 03brlcad * r45054 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am brlcad_path.c progname.c):
03:45.01CIA-62BRL-CAD: move bu_argv0_full_path(), bu_argv0(), bu_getprogname(), bu_setprogname() and
03:45.01CIA-62BRL-CAD: their helper functions (_bu_ipwd() and _bu_argv0()) from brlcad_path.c to
03:45.01CIA-62BRL-CAD: progname.c since they have nothing to do with our intrinsic search data/root
03:45.01CIA-62BRL-CAD: search logic.
03:51.18CIA-62BRL-CAD: 03brlcad * r45055 10/brlcad/trunk/src/libbu/ (brlcad_path.c progname.c): sys/param.h provides MAXPATHLEN, document it for posterity
05:30.43CIA-62BRL-CAD: 03brlcad * r45056 10/brlcad/trunk/src/libged/erase.c: quell warning due to bad pointer dereference juju. argv[0] was the intended target.
05:58.29*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
06:35.46CIA-62BRL-CAD: 03brlcad * r45057 10/brlcad/trunk/src/libbu/progname.c: no need for buffer to be static. just makes for multithreading nasty.
06:40.09CIA-62BRL-CAD: 03brlcad * r45058 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am getcwd.c):
06:40.09CIA-62BRL-CAD: stub in an initial bu_getcwd() implementation that uses getcwd() and getenv(PWD)
06:40.09CIA-62BRL-CAD: for determining the current working directory. untested on win32 (try _getcwd()
06:40.09CIA-62BRL-CAD: and _fullpath()) too, but it's the start of a replacement for _bu_ipwd().
06:40.42CIA-62BRL-CAD: 03brlcad * r45059 10/brlcad/trunk/ (CMakeLists.txt configure.ac): need to test for getcwd for libbu's bu_getcwd() function.
06:44.50CIA-62BRL-CAD: 03brlcad * r45060 10/brlcad/trunk/include/bu.h: finish up the bu_external init macros and typedef
06:45.54brlcadpauses
06:59.02*** join/#brlcad DarkCalf (DC@173.231.40.98)
08:18.28*** join/#brlcad merzo (~merzo@193.254.217.44)
08:31.17*** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net)
10:15.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:38.30dloman_sheesh!  0245!  Littlefoot helping you stay up and code? :)
11:45.09dloman_oh wow, lol: http://www.youtube.com/watch?v=CFuyE_VBeO8&feature=player_embedded#at=338
12:53.22brlcadhehehe
12:53.29brlcadthat's pretty good
12:57.39CIA-62BRL-CAD: 03brlcad * r45061 10/brlcad/trunk/src/libbu/basenametester.c: add header
13:01.54dloman_had trouble not envisioning snakes on a plane :)
13:03.38CIA-62BRL-CAD: 03brlcad * r45062 10/brlcad/trunk/src/libbu/basenametester.c: protect the header inclusion, sys headers before brl-cad headers
13:17.46CIA-62BRL-CAD: 03brlcad * r45063 10/brlcad/trunk/src/libbu/basenametester.c: fingers have a mind of thier own. libgen not libged
13:27.10CIA-62BRL-CAD: 03brlcad * r45064 10/brlcad/trunk/src/libbu/progname.c: prevent a crash inside setprogname if we're passed a NULL argv0.
13:46.28*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:04.43CIA-62BRL-CAD: 03brlcad * r45065 10/brlcad/trunk/src/libbu/progname.c: the _bu_ipwd() calls are temporary, denote that
14:09.42CIA-62BRL-CAD: 03brlcad * r45066 10/brlcad/trunk/include/bu.h: bu_argv0_full_path() wasn't a very good idea either. declare bu_getcwd() as the new coke.
14:21.02*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
14:24.23CIA-62BRL-CAD: 03d_rossberg * r45067 10/brlcad/trunk/include/raytrace.h: quell warnings (and probable misinterpretation) in MSVC
14:34.36CIA-62BRL-CAD: 03brlcad * r45068 10/brlcad/trunk/src/libbu/progname.c:
14:34.36CIA-62BRL-CAD: simplify bu_getprogname(). forget about trying to cash the progname result and
14:34.36CIA-62BRL-CAD: just re-evaluate the name again. this is necessary anyways in case the caller
14:34.36CIA-62BRL-CAD: repeatedly calls bu_setprogname() with different values. also add protection
14:34.36CIA-62BRL-CAD: from bu_basename() which will return '.' or '/' for some strings and that's not
14:34.37CIA-62BRL-CAD: very useful.
14:36.32CIA-62BRL-CAD: 03d_rossberg * r45069 10/brlcad/trunk/ (7 files in 7 dirs):
14:36.32CIA-62BRL-CAD: enabled the build of static libs for MSVC
14:36.32CIA-62BRL-CAD: Static libs shouldn't export symbols like the DLLs because they are linked
14:36.32CIA-62BRL-CAD: directly. Thats why the BRLCAD_DLL flag will be set for DLLs only. The
14:36.32CIA-62BRL-CAD: BRLCAD_ADDLIB and BRLCAD_ADDEXEC macros are setting this flag automatically. If
14:36.33CIA-62BRL-CAD: they are not used the BRLCAD_DLL flag has to be set manually if needed.
14:39.33CIA-62BRL-CAD: 03d_rossberg * r45070 10/brlcad/trunk/src/librt/CMakeLists.txt: enabled export of TIE (Triangle Index Table) symbols for MSVC
14:45.46CIA-62BRL-CAD: 03brlcad * r45071 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am prognametester.c): add a new unit test for bu_getprogname/bu_setprogname. already helped uncover and fix three bugs.
14:51.38CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2922 10/wiki/Community_Publications_Portal: redirect plural
15:05.42*** join/#brlcad piksi_ (piksi@pi-xi.net)
15:09.18starseekerhmm:  http://code.google.com/p/thrust/
15:12.44dloman_neato!
16:24.56kunigamidoes the ray direction ever changes in rt? I'm printing application->a_ray.r_dir and it is always the same
17:22.27bhinesleybrlcad: Did you want to migrate MGED to the new oed translations, or just Archer?
17:54.59*** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net)
18:16.21*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:46.57brlcadkunigami: shaders can change the ray direction, refraction on phong for example
18:47.40brlcadbhinesley: for oed, both and neither
18:48.24brlcadlibged really, so mged will get access to the newer stateless version, but oed doesn't have to go away from mged nor get ported to archer (as a new command) .. it's functionality is just added to libged and accessible to both
18:48.58brlcadno command logic should really be going into archer or mged at this point -- it should be a trivial wrapper on both sides that just calls through to libged
18:51.27bhinesleyso the current oed translations are going away in favor of the one migrated into libged
18:51.56bhinesleyI just wasn't sure if we wanted to change the way mged oed currently works
18:54.46bhinesleyokay, what I said may be misinterpreted... so I'll just say that I realize that the new command belongs in libged :)
18:55.37CIA-62BRL-CAD: 03starseeker * r45072 10/brlcad/trunk/CMakeLists.txt: Flag CMAKE_SYSTEM_IGNORE_PATH as advanced
18:56.14CIA-62BRL-CAD: 03brlcad * r45073 10/brlcad/trunk/include/bu.h: add missing macros and typedef for bu_color struct.
18:57.44CIA-62BRL-CAD: 03starseeker * r45074 10/brlcad/trunk/src/other/CMakeLists.txt: Get another stray variable marked as advanced.
19:07.16kunigami<PROTECTED>
19:39.35CIA-62BRL-CAD: 03brlcad * r45075 10/brlcad/trunk/ (17 files in 5 dirs): consistency, rename the bu_rb_tree struct typedef to bu_rb_tree_t and make bu_rb_tree be the name of the struct like the other bu structs.
20:07.04brlcadbhinesley: yeah, the current system in mged is very modal
20:07.14brlcadyou enter an edit mode, then perform edit operations
20:07.33brlcadthe goal is towards being completely modeless, so you just perform operations
20:07.52brlcadoed's entire purpose is to enter a mode, set up a selection, and set up a keypoint
20:07.55brlcadthe mode isn't necessary
20:08.24brlcadthe selection is simple object names on other commands (translate/rotate/scale)
20:08.44brlcadthe keypoint becomes the main feature that needs to migrate as an option with reasonable defaults
20:09.27brlcadkunigami: that would be perspective mode (-p##)
20:09.40brlcaddefault rendering is orthogonal rays
20:10.22brlcadrt supports both, naturally
20:12.37CIA-62BRL-CAD: 03starseeker * r45076 10/brlcad/trunk/CMakeLists.txt: We require cmake 2.8, and 2.6 and later treat CPACK_STRIP_FILES as a boolean variable - no reason for this logic anymore (which may not have been correct to start with)
20:16.48kunigamihmm I think I was not clear. In this image: http://www.devmaster.net/articles/raytracing_series/part1.2.jpg there are several rays going out from the camera, each of them have a particular direction
20:17.33kunigamiI made a test and printed the direction of all rays sent to shootray, but all of them were the same
20:17.43kunigami(sent by rt application)
20:21.19kunigamithe point is: how come can rays hit different objects if they seem to have the same direction? I'm studying how the hit detector works, but it probably uses another information that I'm missing...
20:25.12CIA-62BRL-CAD: 03bob1961 * r45077 10/brlcad/trunk/src/libbu/basenametester.c: Call basename if HAVE_BASENAME.
20:27.06CIA-62BRL-CAD: 03starseeker * r45078 10/brlcad/trunk/include/gcv.h: add a couple of gcv functions to gcv.h (need at lest gcv_bottess_region_end for windows...)
21:01.53CIA-62BRL-CAD: 03bob1961 * r45079 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Make it so that a canvas located toolbar or menu is allowed only if mViewOnly is true.
21:41.00CIA-62BRL-CAD: 03bhinesley * r45080 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: ls can just use gedWrapper
23:04.35CIA-62BRL-CAD: 03bhinesley * r45081 10/brlcad/trunk/ (10 files in 6 dirs): In the process of adding the translate command to libged. In MGED, it is under translate2 for now. Archer throws a segmentation fault when I try to run it.
23:05.46bhinesleycould someone take a look at this ^ for me? "Archer> translate" causes archer to throw a segfault.
23:05.59bhinesleynot sure what I'm missing
23:08.53``Erikgdb bin/bwish
23:08.57``Erikrun bin/archer
23:09.03``Erikthen, when it crashes, do a backtrace?
23:11.17bhinesleyhey, thanks, that's a start
23:11.36``Eriknp, good luck tracking it
23:11.56``Erikplenty of crash tutorials on using gdb can be found on the web :)
23:37.13*** join/#brlcad Stattrav (~Stattrav@122.167.214.98)
23:37.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
23:54.05CIA-62BRL-CAD: 03bhinesley * r45082 10/brlcad/trunk/src/ (libtclcad/tclcad_obj.c tclscripts/archer/ArcherCore.tcl): Fixed Archer translate command segfault from r45081. Function callback was GED_FUNC_PTR_NULL rather than ged_translate.
23:56.11bhinesley``Erik: that helped quite a bit, thanks again
IRC log for #brlcad on 20110617

IRC log for #brlcad on 20110617

00:20.05dloman_hey ``Erik 's alive!
00:28.14*** join/#brlcad crazy_imp (~mj@a89-182-140-122.net-htp.de)
00:47.39CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2923 10/wiki/User:Bhinesley: /* Log */ Tuesday, yesterday, today, plan tomorrow
02:04.07CIA-62BRL-CAD: 03starseeker * r45083 10/brlcad/trunk/src/other/ (140 files in 10 dirs): Put m4 and byacc back in. Hold off on flex until it's closer to actually building.
03:07.15CIA-62BRL-CAD: 03bhinesley * r45084 10/brlcad/trunk/src/libged/translate.c: Started argument handling on translate cmd (nonfunctioning)
03:23.26CIA-62BRL-CAD: 03bhinesley * r45085 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Disable translate's gedWrapper flags for now
06:42.04*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:47.52*** join/#brlcad merzo (~merzo@193.254.217.44)
06:58.10CIA-62BRL-CAD: 03d_rossberg * r45086 10/brlcad/trunk/ (4 files in 4 dirs):
06:58.10CIA-62BRL-CAD: included the brlcad.dll build into the overall CMake build
06:58.10CIA-62BRL-CAD: it is switched off by default and can be enabled by setting the (advanced) option BRLCAD-ENABLE_BRLCAD_LIBRARY
07:00.34*** part/#brlcad vtts (~vytautas@diz.ktu.lt)
07:02.28CIA-62BRL-CAD: 03d_rossberg * r45087 10/brlcad/trunk/src/other/openNURBS/CMakeLists.txt: under some conditions - most important one is BRLCAD-ENABLE_BRLCAD_LIBRARY - link with the static version of zlib
07:57.06*** join/#brlcad DarkCalf (DC@173.231.40.98)
08:25.59*** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net)
08:25.59*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
08:25.59*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
08:34.48*** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net)
08:34.48*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
08:34.48*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
10:08.46*** join/#brlcad Stattrav (~Stattrav@122.167.214.98)
10:08.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:38.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:48.22dloman_yawns
11:51.31brlcadyawns
11:54.58brlcadbhinesley: learning the basics of using gdb (or any debugger really) is one of the best tools you can learn
11:55.21brlcadgraduating from printing statements to being able to step through code with a debugger is pretty big :)
11:56.15brlcadsetting breakpoints, inspecting memory, walking up and down the stack, stepping through functions, ...
11:56.18brlcadgood stuff :)
11:57.16brlcadkunigami: so that picture is exactly a diagram of perspective rays -- looks like approximately -p45
11:59.45brlcadinstead of divergent rays, the default raytrace uses *parallel* rays, so they're all in the same direction but with different start points
12:00.12kunigamibrlcad: ahh I imagined that! thanks for the clarification
12:10.18brlcadif you take a perspective camera and move it backwards while simultaneously zooming the lens
12:10.28brlcadthe rays will diverge less and less
12:11.04brlcadtake that to the limit, with the camera at an infinite distance away and infinitely zoomed in on the view plane, and the rays become parallel
12:11.37brlcadit's called an orthogonal camera
12:12.39brlcadpretty much the default in all CAD systems and is the style of view that gives you perfect top-down views, side views, etc that you might see on a blueprint diagram
12:32.53CIA-62BRL-CAD: 03brlcad * r45088 10/brlcad/trunk/include/bu.h: add macros for bu_rb_tree. bit more complicated struct to initialize and these macros aren't yet tested, so might need some tweaking.
12:37.22kunigamihmm interesting. and for zooming, instead of moving the camera nearer/farther from the projection plane you instead select a larger/smaller rectangle in this plane?
12:48.50CIA-62BRL-CAD: 03brlcad * r45089 10/brlcad/trunk/include/bu.h: fix BU_VLB_INIT() and add macros/typedef for bu_observer. it's apparently not using the magic number, so pretend the magic is zero for now.
12:49.23CIA-62BRL-CAD: 03davidloman * r45090 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/ (GSConnection.java NetMsgFactory.java): Move all the ByteBuffer parsing fns over to NetMsgFactory where the rightly belong. Change functions to take pre-init-ed lists as args to minimize on the mallocs/frees.
13:06.52CIA-62BRL-CAD: 03brlcad * r45091 10/brlcad/trunk/include/bu.h: add all of the macros and typedefs for the three bu hash structs: bu_hash_entry, bu_hash_tbl, bu_hash_record. untested macros. mm. bu_hash should probably get used a lot more throughout the code...
13:12.46CIA-62BRL-CAD: 03brlcad * r45092 10/brlcad/trunk/include/bu.h: add macros and typedef for bu_image_file
13:49.39brlcadkunigami: not really, you basically just treat it like a completely different camera with parallel rays originating from the image plane in a grid
13:49.47brlcadit actually simplifies things
13:50.27brlcadrays still behave the same as they do in perspective mode, they're just originating from different points all going in the same direction
13:50.47brlcadwoo hoo, that's all of the libbu structs!
13:53.20dloman_yay
13:53.22dloman_!
13:57.08``Erikdloman_: yup, alive, just got back from ocean city... ya doing a going away lunch or get-together?
13:57.18dloman_did yesterday :(
13:57.32``Erikdoh!
13:57.38dloman_but i have to come back in on the 23rd for a appt at Kirk Med Center, so we can do lunch then.
14:00.48``Erikokie, cool beans
14:01.00``Eriknext thursday
14:06.29CIA-62BRL-CAD: 03davidloman * r45093 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/net/GSConnection.java: Add back in the NULL test. Accidentally got deleted!
14:07.01CIA-62BRL-CAD: 03davidloman * r45094 10/geomcore/trunk/src/interfaces/java/src/org/brlcad/geometryservice/GSJavaInterface.java: Implement getList()
14:08.22CIA-62BRL-CAD: 03davidloman * r45095 10/geomcore/trunk/src/clients/java/src/org/brlcad/geometryservice/minimalclient/cmd/ListCmd.java: Implement ListCmd
15:03.54*** join/#brlcad Stattrav (~Stattrav@117.202.22.140)
15:03.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:18.15CIA-62BRL-CAD: 03brlcad * r45096 10/brlcad/trunk/ (configure.ac misc/Makefile.am misc/win32-msvc8/): the old msvc8 build system is no longer relevant. cmake is the new cake.
16:24.20*** join/#brlcad Stattrav (~Stattrav@117.202.22.140)
16:24.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:08.19*** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net)
17:08.19*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
17:08.19*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
17:16.08*** join/#brlcad dli (~dli@dsl-67-55-7-45.acanac.net)
17:16.08*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
17:16.08*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
17:22.25*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
17:48.10``Erikneat, my home box hit 400 days uptime
17:48.29``Erik<PROTECTED>
17:50.49``Erikneat, bz is at 501 days
17:57.18CIA-62BRL-CAD: 03bob1961 * r45097 10/brlcad/trunk/src/ (libtclcad/tclcad_obj.c tclscripts/lib/Ged.tcl): A few more modes to accommodate windows.
18:06.52*** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net)
18:58.56*** join/#brlcad merzo (~merzo@177-195-133-95.pool.ukrtel.net)
19:28.34CIA-62BRL-CAD: 03bhinesley * r45098 10/brlcad/trunk/src/libged/translate.c: Basic short argument handling implemented for ged_translate
19:56.45CIA-62BRL-CAD: 03starseeker * r45099 10/brlcad/trunk/src/other/ (51 files in 2 dirs): Add subset of flex and what build logic exists thus far - still have quite a few tests to add, but it does build and process the '%%' minimal file. Doubtful it really works as yet.
20:05.34CIA-62BRL-CAD: 03bhinesley * r45100 10/brlcad/trunk/src/libged/translate.c: fix usage formatting
20:28.00CIA-62BRL-CAD: 03starseeker * r45101 10/brlcad/trunk/ (CMakeLists.txt src/other/CMakeLists.txt): Remove the obsolete DISTCHECK_DIRS global property, more comments on flex.
20:38.34*** join/#brlcad mac- (mac@mac.banda.pl)
20:38.37mac-hi
20:55.16brlcadhello
20:55.38brlcad``Erik: sounds like time to take it down then!
20:55.47brlcadthat's what I was waiting for ....
21:02.00*** join/#brlcad merzo (~merzo@177-195-133-95.pool.ukrtel.net)
21:47.02dloman_``Erik: change of plans man.  I found someone at Kirk to get me thru today, rather than thursday.  Looks like I won't be in MD next week! :/
22:07.07CIA-62BRL-CAD: 03bhinesley * r45102 10/brlcad/trunk/src/libged/translate.c: More complete 'translate' argument handling
IRC log for #brlcad on 20110618

IRC log for #brlcad on 20110618

00:28.29*** join/#brlcad crazy_imp (~mj@a89-182-172-216.net-htp.de)
06:42.54*** join/#brlcad Stattrav (~Stattrav@122.167.214.98)
06:42.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:19.24*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
10:07.41*** join/#brlcad mafm (~mafm@237.Red-83-45-72.dynamicIP.rima-tde.net)
13:11.19CIA-62BRL-CAD: 03kunigami * r45103 10/brlcad/trunk/src/liboptical/ (5 files): (log message trimmed)
13:11.20CIA-62BRL-CAD: the osl-renderer now works with multiple osl shaders. Made several design
13:11.20CIA-62BRL-CAD: changes to allow recursive rays... it now returns in the renderinfo struct
13:11.20CIA-62BRL-CAD: information about the new ray that must be cast. the caller of the system must
13:11.20CIA-62BRL-CAD: shoot the new ray. this is good because I imagine brl-cad shaders and osl
13:11.20CIA-62BRL-CAD: shaders could be mixed. I've not tested this system with sh_osl, but rather
13:11.20CIA-62BRL-CAD: osl_rt. on the other hand, I imagine the calling interface is essentially the
15:31.28CIA-62BRL-CAD: 03brlcad * r45104 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: @Compare and @check are not valid doxygen. change to @brief ...
15:39.32CIA-62BRL-CAD: 03brlcad * r45105 10/brlcad/trunk/include/raytrace.h: quell doxygen warning, 'command inside argument documentation'
15:44.03CIA-62BRL-CAD: 03brlcad * r45106 10/brlcad/trunk/include/bu.h: clarify which file since there are multiple files named the same being processed by doxygen.
15:45.37CIA-62BRL-CAD: 03brlcad * r45107 10/brlcad/trunk/src/adrt/isst_tcltk.c: file is not main.c
15:45.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:05.45*** join/#brlcad Stattrav_ (~Stattrav@117.202.21.118)
17:33.58*** join/#brlcad crazy_imp (~mj@a89-182-196-105.net-htp.de)
18:01.37*** join/#brlcad Stattrav (~Stattrav@117.192.143.94)
18:01.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:41.31*** join/#brlcad Stattrav_ (~Stattrav@117.192.136.225)
18:43.07*** join/#brlcad Stattrav1 (~Stattrav@117.192.136.225)
18:48.37*** join/#brlcad Stattrav (~Stattrav@117.192.136.225)
18:48.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:36.06*** join/#brlcad Stattrav (~Stattrav@117.192.136.225)
19:36.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:39.34*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
23:27.15*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20110619

IRC log for #brlcad on 20110619

06:08.59*** join/#brlcad Stattrav (~Stattrav@117.202.16.74)
06:08.59*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:42.47*** join/#brlcad Stattrav (~Stattrav@117.192.143.117)
06:42.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:51.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:59.30*** join/#brlcad juan_man (~quassel@201.255.49.161)
06:59.38*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
07:19.20*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
10:09.52*** join/#brlcad crazy_imp (~mj@a89-182-196-105.net-htp.de)
10:37.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:10.27*** join/#brlcad Stattrav (~Stattrav@117.202.24.155)
11:10.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:18.11*** join/#brlcad Stattrav (~Stattrav@117.202.24.155)
11:18.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:24.29*** join/#brlcad Stattrav (~Stattrav@117.202.24.155)
11:24.35*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:14.41CIA-62BRL-CAD: 03brlcad * r45108 10/brlcad/trunk/src/libbu/ (getcwd.c globals.c): be specific about which file's we're referring to for doxygen
17:30.52*** join/#brlcad crazy_im1 (~mj@a89-182-181-206.net-htp.de)
17:57.44*** join/#brlcad kunigami_ (~kunigami@201.53.197.251)
19:17.31*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
23:00.10*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
23:05.57*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
IRC log for #brlcad on 20110620

IRC log for #brlcad on 20110620

01:20.46CIA-62BRL-CAD: 03brlcad * r45109 10/brlcad/trunk/include/bu.h: prefix all doxygen file markers with the library they belong to in order to avoid conflicts with same-named files in other directories being processed simultaneously.
02:10.22CIA-62BRL-CAD: 03brlcad * r45110 10/brlcad/trunk/include/bu.h: this file isn't in the libbu dir
02:11.22CIA-62BRL-CAD: 03brlcad * r45111 10/brlcad/trunk/src/libbn/ (22 files): prefix all of the doxygen file commands with libbn so we don't conflict with same-named files in other directories
02:22.22CIA-62BRL-CAD: 03brlcad * r45112 10/brlcad/trunk/src/ (425 files in 15 dirs): prefix all of the library @file doxygen commands with the library dir/name in order to avoid conflicts with same-named files in other directories. was causing processing woes.
02:26.07CIA-62BRL-CAD: 03brlcad * r45113 10/brlcad/trunk/src/ (168 files in 5 dirs): more @file prefixing in order to deconfuse doxygen bulk processing where file names are non-unique.
02:40.31CIA-62BRL-CAD: 03brlcad * r45114 10/brlcad/trunk/src/ (469 files in 10 dirs): more @file directive clarification for doxygen to avoid naming conflicts with other same-named files in other directories.
02:43.38CIA-62BRL-CAD: 03brlcad * r45115 10/brlcad/trunk/src/ (59 files in 3 dirs): few more @file doxygen conflict cases
02:44.14CIA-62BRL-CAD: 03brlcad * r45116 10/brlcad/trunk/src/proc-db/brep_cube.cpp: proper header
03:13.07CIA-62BRL-CAD: 03brlcad * r45117 10/brlcad/trunk/src/proc-db/ (brep_cube.cpp brep_simple.cpp csgbrep.cpp): header cleanup, refer to the proper filename
03:17.22CIA-62BRL-CAD: 03brlcad * r45118 10/brlcad/trunk/src/vfont/vfont.h: filename is vfont
03:21.09CIA-62BRL-CAD: 03brlcad * r45119 10/brlcad/trunk/include/vector_fpu.h: add missing common.h include for UNUSED() definition.
03:25.55*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
07:02.21*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:16.14*** join/#brlcad merzo (~merzo@193.254.217.44)
09:05.10*** join/#brlcad Stattrav (~Stattrav@122.167.214.98)
09:05.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:56.20CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2924 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */
10:57.57CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2925 10/wiki/User:Kunigami/GSoc2011/Proposal: /* Timeline */ updated timeline
14:28.53*** join/#brlcad merzo (~merzo@193.254.217.44)
14:37.35*** join/#brlcad Stattrav (~Stattrav@117.192.151.196)
14:37.35*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:50.11CIA-62BRL-CAD: 03erikgreenwald * r45120 10/brlcad/trunk/include/raytrace.h: Some parsers freak out when they see */*stp*/, thinking it's an end of comment. Adding a space seems to make them happy.
15:11.48brlcadwb
15:12.31``Erikyargh
15:12.43``Erikvacations never last long enough. :/
15:22.20CIA-62BRL-CAD: 03brlcad * r45121 10/brlcad/trunk/src/ (52 files in 7 dirs): (log message trimmed)
15:22.20CIA-62BRL-CAD: remove the SCLLOG/SCLBOOL wrappers on the SCL Boolean and Logical enums. they
15:22.20CIA-62BRL-CAD: were being conditionally put into a namespace in order to be protected in case
15:22.20CIA-62BRL-CAD: they're used within a 3rd party context (like CORBA) that might also define
15:22.20CIA-62BRL-CAD: same-named enums, but the macrofied protection just adds complexity. iff a
15:22.21CIA-62BRL-CAD: conflict is encountered, the types can be put into an SCL or P23 or SDAI
15:22.22CIA-62BRL-CAD: namespace. 'Boolean' would be prime for outright removal/replacement with
15:22.36brlcadkunigami: make sure all files you add have a proper header and footer, e.g.: sh/header.sh lgpl src/liboptical/osl-renderer.cpp
15:23.30brlcadsh/header.sh, sh/footer.sh, or sh/template.sh (to apply both header and footer)
15:23.58brlcadsh/ws.sh and sh/indent.sh will clean up the formatting so it's consistent with the rest of the source code
15:24.50brlcadjust make sure any cleanup commits aren't mixed with actual code/logic changes
15:40.15CIA-62BRL-CAD: 03kunigami * r45122 10/brlcad/trunk/src/liboptical/osl-renderer.cpp: Cleaning up formatting of osl-renderer.cpp
15:50.21CIA-62BRL-CAD: 03erikgreenwald * r45123 10/brlcad/trunk/src/other/m4/lib/ohash.h: include sys/types.h for u_int32_t
16:28.43CIA-62BRL-CAD: 03starseeker * r45124 10/brlcad/trunk/src/other/m4/ (eval.c gnum4.c main.c misc.c): Try the BRL-CAD wrapper for unistd.h here...
16:31.10kunigamiwhen I run indent with osl-renderer.h it changes spacing to 2 while in osl-renderer.cpp it keeps 4. it that the default?
16:34.11kunigamihmm, actually I'd rather ask why footer.sh does not add "c-basic-offset: 4" line?
16:48.32CIA-62BRL-CAD: 03starseeker * r45125 10/brlcad/trunk/src/other/m4/lib/libyywrap.c: Hmm - MSVC doesn't like __P for some reason.
16:49.32CIA-62BRL-CAD: 03kunigami * r45126 10/brlcad/trunk/src/liboptical/ (osl-renderer.cpp osl-renderer.h osl_rt.cpp osl_rt2.c): formatting changes for several files
16:50.21CIA-62BRL-CAD: 03starseeker * r45127 10/brlcad/trunk/src/other/m4/generated/tokenizer.c: one more unistd.h case
16:52.44CIA-62BRL-CAD: 03kunigami * r45128 10/brlcad/trunk/src/liboptical/osl-renderer.cpp: typo on osl-renderer.cpp local variables
16:53.23brlcadstarseeker: egads man
16:53.56brlcadif you had to paste it just twice .. should've been a hint to refactor :)
16:54.21brlcadput that mess into a header and just #include it...
16:57.27brlcadI know you're just trying to "get it to work" .. but egads .. that's passing the buck and really making more work for later
16:59.35CIA-62BRL-CAD: 03starseeker * r45129 10/brlcad/trunk/src/other/m4/ (eval.c extern.h gnum4.c main.c mdef.h): Remove the doesyscmd option from the m4 logic. May have to revisit this if it turns out later we need it, but this will be problematic on Win32.
17:00.45brlcadalso, fwiw, __P is undoubtedly defined like BU_ARGS() used to be .. it makes the parameter list conditional
17:01.17brlcadthe __P protection belongs where it's defined, not where it was used in libyywrap.c
17:04.43CIA-62BRL-CAD: 03starseeker * r45130 10/brlcad/trunk/src/other/m4/ (14 files in 2 dirs):
17:04.43CIA-62BRL-CAD: Hack, slash and burn approach to MSVC building - this has lots of unresolved
17:04.43CIA-62BRL-CAD: external symbols and may not function at all anywhere, but it should indicate
17:04.43CIA-62BRL-CAD: what further changes are needed. Will also need regex linked in, need to take
17:04.43CIA-62BRL-CAD: care of that.
17:05.02brlcadkunigami: c-file-style: "Stroustrup" sets 4-char indents
17:06.27starseekerbrlcad: oh, I know - I've got a lot of refactoring to do - I'm just trying to get a feel for the scope of what's needed
17:06.37kunigamithat's strange. even with that line indent.sh used 2 spaces. When I added c-basic-offset:4 it correclty used 4
17:07.00starseekerbrlcad: it wasn't immediately clear how deep into "unixy" coding this m4 was
17:10.02CIA-62BRL-CAD: 03brlcad * r45131 10/brlcad/trunk/src/liboptical/osl-renderer.h: restructure around a WITH_OSL keyword instead of __cplusplus since it should always be possible to compile the sh_osl C interface.
17:11.07brlcadstarseeker: http://gnuwin32.sourceforge.net/packages/m4.htm
17:11.50brlcadenough to warrant someone making a fork instead of trying to make it portable
17:11.57brlcadbut then that could have just been laziness or simplicity
17:12.14starseekernods - yeah, saw that - but this isn't GNU m4
17:12.25starseekerit's the netbsd port of the openbsd m4
17:12.41starseekerwas going for the smallest m4 that looked like it might have a hope of working with flex
17:12.55starseekerboth for build simplicity/porting simplicity and to keep the size of src/other smaller :-P
17:13.25starseekerso far this feels a lot like working with the find code for the search command
17:13.54kunigamibrlcad: I didn't understand your changes to osl-renderer.h. It was already possible to compile with sh_osl C interface.
17:14.34brlcadif we really wanted simplicity and a small src/other, we'd just generate the files, add them to svn, and compile those on windows :)
17:14.39CIA-62BRL-CAD: 03starseeker * r45132 10/brlcad/trunk/src/other/m4/lib/libyywrap.c: Ah, that's why cdefs was included here. Win32 doesn't have cdefs, so be more direct...
17:15.02brlcadway more simple than these 3-4 new dependencies, build system mods, maintenance woes
17:15.20*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
17:15.21kunigamithe reason for __cplusplus was that C++ code would see a different interface than C code
17:16.31brlcadkunigami: which C++ code?
17:16.56kunigamibrlcad: osl-renderer.cpp which is an interface to osl system
17:17.25kunigamiboth osl-renderer.cpp and sh_osl.c share the interface osl-renderer.h
17:18.05brlcadiirc, technically doesn' sh_osl.c only "share" the inteface via the C callbacks declared at the bottom of osl-renderer.h?
17:18.26*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
17:18.26brlcadit's "declare class" or "declare typedefs and C funcs"
17:18.31yukonbobhello, #brlcad
17:18.41brlcadrather, it was
17:18.46brlcadhello yukonbob
17:19.26brlcadkunigami: something to consider, sh_osl doesn't have to be C -- it can be a C++ file
17:19.55brlcadso you can call right into osl-renderer.h classes
17:20.17brlcadthe only protection really necessary is whether we have OSL or not
17:21.18brlcadthat was the motivation, move towards blocking based on the build feature, since the compilation of the interface file is already built-in
17:22.35kunigamiI'm not sure if I understood what you meant, but when OSL is not enabled, osl-renderer.h is not even compiled.
17:23.42brlcadright, it's either on and OSL is available or it's off
17:23.51brlcadsh_osl.c doesn't get compiled if it's off, right?
17:23.56kunigamiyup
17:24.10kunigamiI added a conditional on CMakeLists.txt
17:24.28brlcadso then if it's only on when osl is compiled, and osl is c++, then sh_osl can be c++
17:24.41brlcadand the c wrapping isn't needed
17:25.07brlcadjust adds complexity and code that won't ever get executed/used
17:25.22brlcadmake sense?
17:25.32kunigamibrlcad: right. I didn't know that sh_osl could be c++.
17:26.01brlcadyep, you could svn mv sh_osl.c sh_osl.cpp if you really wanted
17:26.18brlcadthe only important part is that C++ types aren't publicly exposed by liboptical
17:26.56brlcadso if you find yourself needing to add a C++ class / typedef into a header file in the top-level include/ directory, then it might be an issue and require some rethought
17:27.24kunigamibut if sh_osl is C++ then I'll have to export functions using "extern C" anyway, because AFAIK C++ exports mangled functions names
17:27.52brlcadsure, if you call C functions
17:28.11brlcadand call them outside that compilation unit
17:28.43brlcadthe c functions you had looked like logic that wouldn't need to live in osl-renderer, they'd just be part of the logic in sh_osl.c
17:28.47brlcader sh_osl.cpp
17:29.24brlcadi.e., you don't need wrappers, you'd just create OSL_Renderer objects and use them
17:29.44kunigamiperfect
17:29.50kunigamiI'll give it a try
17:30.32brlcadat most, you'd maybe have to stash an OSL_Renderer* object into a struct so you could pass it around as a void* through the various liboptical callback functions
17:30.42brlcad(the 'dpp' parameter)
17:30.56brlcadthat's a user data pointer
17:31.22brlcadand that's only because c++ forbids casting objects through void*, have to stash in struct and cast the struct through void*
17:32.00brlcadmake sure you quell all warnings ;)
17:32.44kunigamiright
17:34.35brlcadstarseeker: those big repeated code blocks are more a mentality issue, not letting yourself create extra work in the first place
17:35.14*** join/#brlcad crazy_imp (~mj@a89-182-170-199.net-htp.de)
17:35.56brlcadplus, i've heard you say something to the effect of "I've got a lot of refactoring to do"
17:35.59brlcadwith plans to clean some bit of code up "later" on at least three other occasions now :D
17:36.24brlcadand that "later" never manifested itself
17:36.54brlcadcode complete, deep not wide
17:45.04brlcadkunigami: not sure about the 2 vs 4 indents -- maybe something in your .emacs file?  if I move mine out of the way, I get 4char indents
17:45.10CIA-62BRL-CAD: 03starseeker * r45133 10/brlcad/trunk/src/other/m4/ (common.h eval.c gnum4.c main.c misc.c pstdint.h): move unistd.h wrapper to common file, add portability guarantee with pstdint.h
17:52.33CIA-62BRL-CAD: 03starseeker * r45134 10/brlcad/trunk/src/other/m4/ (expr.c look.c trace.c): Replace a few direct calls to stdint.h
17:53.40CIA-62BRL-CAD: 03brlcad * r45135 10/brlcad/trunk/src/other/m4/lib/libyywrap.c: even simpler, it's a preansiism
17:59.14CIA-62BRL-CAD: 03starseeker * r45136 10/brlcad/trunk/src/other/m4/ (generated/tokenizer.c parser.y tokenizer.l): Ah, hiding in the tokenizer. Should get us down to the regex header.
18:00.44CIA-62BRL-CAD: 03starseeker * r45137 10/brlcad/trunk/src/other/m4/lib/ohash_int.h: Nope, one more - ohash
18:05.46CIA-62BRL-CAD: 03erikgreenwald * r45138 10/brlcad/trunk/src/other/m4/generated/parser.c: remove stdint.h in favor of common.h/pstdint.h
18:06.49*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
18:09.59CIA-62BRL-CAD: 03starseeker * r45139 10/brlcad/trunk/src/other/m4/ (CMake/ CMake/FindREGEX.cmake CMakeLists.txt): Add logic to locate and link in regex library.
18:14.20brlcadstarseeker: so how's the prognosis looking ... have a thought that might make the effort somewhat moot
18:14.32starseekerbrlcad: not bad, actually
18:14.36starseekerat least, not so far
18:14.41starseekerwhat's the though?
18:15.10brlcadditch lex/yacc for antlr
18:15.10CIA-62BRL-CAD: 03starseeker * r45140 10/brlcad/trunk/src/other/m4/CMakeLists.txt: Dur - try linking the library, not compiling it.
18:15.26brlcadit's half the code side and supports windows
18:15.42starseekerhuh, never heard of it before
18:15.43brlcadbut would require rewriting our few existing lex/yacc files in their syntax (which is nearly identical)
18:15.50starseekerreads...
18:17.03starseekerbrlcad: it's java based?
18:18.24starseekeror are you looking at the C runtime distributions?
18:19.01brlcadhttp://www.antlr.org/wiki/display/ANTLR3/Five+minute+introduction+to+ANTLR+3
18:23.03brlcadanother tutorial: http://supportweb.cs.bham.ac.uk/docs/tutorials/docsystem/build/tutorials/antlr/antlr.html
18:23.53starseekerdon't we need java to run antlr and generate the code though?
18:26.13brlcadeither hook in the java binary (which we could probably bundle precompiled if it's small enough), or compile them via the C runtime (which is about 25k lines of code, about the size of flex)
18:27.03brlcadif I'm understanding their setup correctly, that would even be more ideal than the lex/yacc approach for things like libgcv where we just want the parsing functions, not a main()
18:28.06brlcadof course, the java app may still be required to compile the functions and then the C runtime to use them, not 100% sure on that detail
18:28.13starseekerI'm trying to figure out if the runtime can eat the grammer and execute code, or if you still need the java tools to generate the code
18:28.17starseekerer, yeah :-)
18:29.51starseekerI'm thinking you need java to compile the grammar - I just built libantlr3c and there's no tool I can see to generate C code...
18:30.34starseekerI did a survey a while back looking for lex/yacc alternatives that were in C and I remember coming up rather short...
18:33.12starseekerhmm...
18:33.26starseekerbrlcad: maybe http://www.hwaci.com/sw/lemon/ ?
18:35.06starseekerif we're willing to rewrite our definitions, that might be a way to go
18:35.54*** join/#brlcad crazy_imp (~mj@a89-182-141-171.net-htp.de)
18:36.25kunigamiI didn't know in C it's allowed to set a function like "void foo(int x)" to a function pointer "void (*fp)()". In C++ it seems it is not allowed. Any suggestions?
18:36.55brlcadstarseeker: it'd be worth giving it a try, maybe start with the simple parser in src/mged/points
18:37.42brlcadthat's a prime simple test case for conversion, if it works, that'd probably be good enough proof of concept to run forward with it
18:39.09brlcadnot nearly as complicated as the others
18:39.23starseekernods - sounds good
18:39.24brlcadkunigami: I'm working on fixing that right now
18:39.39brlcadkunigami: that's an old carry-over from k&r days of C
18:39.57kunigamibrlcad: ok, thanks!
18:42.11brlcadc++ has the same behavior as the concept of "calling a function" in either is as simple as jumping to a pointer address
18:42.39brlcadit just adds type safety during compilation so it can enforce only jumping to a "compatible" address
18:44.07yukonbobstarseeker: what are you looking for lex/yacc alternatives for?
18:44.34brlcadC will happily jump to whatever you ask, compiler won't even warn by default unless you ask it to
18:44.47kunigamihmm interesting
18:45.08starseekeryukonbob: we need to be able to handle a (potentially large) number of grammar definitions for geometry format conversion (and other uses, like MGED's point abilities)
18:45.35starseekerwe also need to be portable, and (right now) recent flex versions aren't working on Windows
18:45.46yukonbobstarseeker: and lex/yacc are unsuitable for some reason?
18:45.48starseekerwe also need something that's LGPL-or-freer
18:45.51yukonbobah
18:46.07yukonbobchecks.
18:46.14starseekerThe best combination I had come up with so far was the netbsd m4 + byacc + flex
18:46.21brlcadlicense compatible and portable to windows .. good luck ;)
18:46.21starseekerbut that'll have to be ported to Windows
18:46.47yukonbobheh -- that's what I was just looking  up.
18:47.04yukonbobNetBSD runs everything, even if it's not.
18:47.13yukonbob;)
18:47.29starseekerthe commits you saw earlier were me and ``Erik getting NetBSD's m4 compiling on MSVC
18:47.59starseekeras long as we don't have to run system commands, it doesn't look too bad - mostly just need to swat all the uses of err, warnx, etc.
18:48.45starseekerflex will be a bit trickier, since it wants to run m4 from within it's own source code (ick)
18:49.09yukonbobstarseeker: like exec("m4"...");?
18:49.10starseekerfortunately we just need to run 'em during build, and don't have to install them
18:49.23starseekerpretty much
18:49.27yukonbobsweet.
18:50.38starseekerbyacc I'm more hopeful about - the dev was very helpful and added a couple Bison features to get our libobj examples working
18:50.55starseekerbut of course that too is untried on Windows
18:51.16starseekeryukonbob: if you know of something less gnarly we'd LOVE to hear about it :-P
18:51.16yukonbobstarseeker: I haven't worked w/ flex/yacc in ages, but aren't their artifacts just .c and .h? Considered just generating those on a *nix and shipping those artifacts as part of the repo?
18:51.47starseekeryukonbob: the problem with that is the grammar definitions are what you edit during the development process
18:52.17starseekerwe want potential developers to edit the source, type "make" (or do the MSVC thing on Windows) and have it Just Work
18:52.50yukonbobya -- my suggestion is certainly non-elegant in that regard.
18:52.51starseekerthe temptation when you have generated source files is to tweak those files and not the original grammar definitions, which very quickly divorces the code (and fixes) from what should be the canonical source code
18:53.28yukonbobinlucde a comment "Edit this code under threat of death as punishment"...
18:53.34starseekera geometry conversion library may potentially grow to have dozens of grammars that need to be handled, and that will be quite a job even if we AREN'T having to worry about syncing back and forth
18:53.46starseekerheh
18:54.10starseekerthat's a great way to encourage contributions :-P
18:54.35yukonbobstarseeker: anybody who's able to contribute to a lexer/parser will know what it means.
18:55.12yukonbobbut meh... best case is a truly portable lex/yacc
18:55.25starseekeryukonbob: if we're building just the sources though, new devs may head straight for the sources to fix a problem
18:55.37starseekerwould probably do that, without knowing better
18:55.56starseekerand would probably run screaming :-P
18:57.45yukonbobstarseeker: is your list of candidates posted anywhere?|
18:57.49starseekerbecause the lex/yacc or whatever files are the "user editable" form of the logic, we also want to make sure they continue to work and don't "bit rot" - if the C files work, but no one has done the generation in a few years, who knows what may have gone wrong next time we NEED to do the generation?
18:57.59starseekeryukonbob: uh - src/other? :-P
18:58.12starseekerwill make a wiki page quick...
19:05.59yukonbobstarseeker: re: bit rot -- build is automated for producing various binaries, no?
19:07.22starseekerer, huh?
19:07.56yukonbobon major releases, you have a system that generates binaries, no?
19:08.15starseekerOh, you mean binary releases?  yeah
19:09.21yukonbobso for case of ppl tweaking lex/yacc artifacts and not being able to actually produce them canonically, that'd be tested periodically w/ testing for formal releases...
19:09.58yukonbobshould stop worrying about project-wide builds and see if his NetBSD build still stands up to latests sources...
19:10.01starseekeryukonbob: but if it's not integrated into our build, it becomes an extra overhead/step that consumes developer time (a lot of it, over the long pull)
19:18.34yukonbob! -- this has bumped 2 minor versions since I last checked...
19:21.07CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r2926 10/wiki/Lexer_Parser: Stub in a page for discussing lexers/parsers
19:21.48CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r2927 10/wiki/Lexer_Parser:
19:26.08starseekerhmm - re2c actually might be interesting
19:28.20starseekerhttp://lekernel.net/blog/2009/02/re2c-and-lemon-an-elegant-alternative-to-flex-and-bison/
19:31.20starseekerO.o  apparently someone is building re2c on MSVC?
19:31.52yukonbobfamiliar w/ lemon, but not re2c
19:32.11starseekeryukonbob: what do you think of lemon?
19:35.16yukonboblikes things that come from drh
19:35.24starseekeryukonbob: know anything about styx?  http://speculate.de/
19:35.58yukonboblike I said, I haven't played in that domain for a while, but conceptually, lemon is nice, and is thoroughly tested via sqlite
19:36.20starseekerhuh - styx has Express (from STEP) as an example grammar
19:36.26yukonboblikes this "non statement" in the re2c:
19:36.33yukonbob"...equal to hand-written code in terms of size, speed and quality."
19:36.43yukonbob*re2c site..
19:37.25yukonbobmy understanding w/ parser code is that rolling your own is often error-prone, difficult, often inefficient, etc., etc.
19:38.09starseekerheh - if I read that right, it dates back to when people were hand-tuning code due to machine speed constraints
19:38.35yukonbobya -- /me just getting into site, so may be pulling out of context, but still made me chuckle.
19:39.24CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r2928 10/wiki/Lexer_Parser: Add a few more notes
19:39.37yukonbobheh -- oh, and holding up PHP as a flagship project...
19:42.50starseekerstill - if it doesn't need m4 and already builds on Windows...
19:46.07*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
19:46.44CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r2929 10/wiki/Lexer_Parser: not links
19:53.59CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r2930 10/wiki/Lexer_Parser: Few more comments on re2c, link to example using lemon
20:30.13CIA-62BRL-CAD: 03erikgreenwald * r45141 10/brlcad/trunk/src/other/m4/ (14 files in 3 dirs): rename common.h to commonm4.h, as our regex.h requires include/common.h
20:30.30starseekernods - good catch
20:38.08CIA-62BRL-CAD: 03erikgreenwald * r45142 10/brlcad/trunk/src/other/m4/ (gnum4.c main.c misc.c): errx->m4errx
20:40.06CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r2931 10/wiki/Lexer_Parser: Add notes on Antlr
20:48.17CIA-62BRL-CAD: 03erikgreenwald * r45143 10/brlcad/trunk/src/other/m4/misc.c: add some windows portability functions. Includes getopt from libbu, LGPL pollution.
20:51.09CIA-62BRL-CAD: 03starseeker * r45144 10/brlcad/trunk/src/other/byacc/main.c: Looks like this is the only use byacc makes of unistd, so just wrap it here.
20:51.32kunigamiWhen I finish porting sh_osl.c to sh_osl.cpp, OSLRenderer object will need to be declared at a global scope. In which place do you think it's better to keep it? I though of putting it on "struct application", but this struct is not passed as parameter to osl_setup.
20:59.49kunigamihmm the problem of letting OSLRenderer global is that we will need a opaque pointer because it will be visible for C code.
21:01.22kunigamiIs it possible to declare it in such a way that it is visible to all sh_osl instances as a global object, while not exposing it to C code?
21:02.54brlcadyou mean like static? :)
21:06.52kunigamiprobably is that what I want
21:08.31brlcaddefinitely don't want something globally visible
21:09.09brlcada static global will limit scope to that file, a static variable inside a callback will limit scope even further to callers of an accessor function
21:09.32CIA-62BRL-CAD: 03starseeker * r45145 10/brlcad/trunk/src/other/flex/ (CMake/ CMake/FindREGEX.cmake CMakeLists.txt): flex will need the regex lib too (and a good deal more, but start with this.)
21:09.49brlcadwhat else does flex need?
21:10.03starseekerer, sorry - phrased that wrong
21:10.16starseekerneeds tests (limit.h, sys/wait.h, etc.)
21:10.24brlcadah
21:16.48kunigamiI was thinking about a possible problem: I only managed to make OSLRenderer work when I grouped all osl shaders in a single class (I've tried using a OSLRenderer for each osl shader, but it didn't work). It's probably the case that some information must be stored in a global context and shared among the shaders. If this is true, it won't be possible to mix brl-cad and osl shaders :( I've to investigate it further...
21:26.51CIA-62BRL-CAD: 03starseeker * r45146 10/brlcad/trunk/src/other/flex/CMakeLists.txt: No doubt a fair number of these tests need to be more sophisticated, but this gives us a first cut at supporting most of conf.in's variables.
21:57.29CIA-62BRL-CAD: 03starseeker * r45147 10/brlcad/trunk/src/other/flex/CMakeLists.txt: Whoops - add in the REGEX include dir too.
21:58.57*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
22:01.02CIA-62BRL-CAD: 03brlcad * r45148 10/brlcad/trunk/include/optical.h: document optical_shader_init()
22:04.54CIA-62BRL-CAD: 03starseeker * r45149 10/brlcad/trunk/src/other/flex/scan.c: wrap unistd.h in scan.c - will need to fix the generation in some fashion for this, probably add the wrapper to the skeleton...
22:07.35CIA-62BRL-CAD: 03starseeker * r45150 10/brlcad/trunk/src/other/flex/scan.c: Hmm... need something a bit different here, apparently... - try going minimal...
22:07.37*** join/#brlcad dtidrow (~dtidrow@c-68-60-53-123.hsd1.mi.comcast.net)
22:10.12CIA-62BRL-CAD: 03starseeker * r45151 10/brlcad/trunk/src/other/flex/parse.c: Hmm. Possibly a stray semicolon, could also be an error in the if/else logic...
23:06.52brlcadkunigami: if it's hooked through our shader system, there really is no limitation on mixing shader types because the mixing is per-pixel and happening on our end
23:07.19brlcadyou might not be able to get neat blending effects, like a caustic on a non-osl shader, but that's okay
23:07.58*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
23:08.39brlcadit's really a question of whether osl can shade a single pixel without shooting the ray itself -- if it can, then it should be entirely possible
23:09.06brlcadfinally finishes an exhaustive day refactoring liboptical .. now to make sure it still works!
23:09.15*** part/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
23:35.52CIA-62BRL-CAD: 03bhinesley * r45152 10/brlcad/trunk/src/libged/translate.c: adding 'f_tr_obj' functionality to 'translate'
IRC log for #brlcad on 20110621

IRC log for #brlcad on 20110621

00:31.27brlcadbhinesley: rough going? :)
00:37.13bhinesleybrlcad: yeah...
00:37.30bhinesleyreading through code and trying to figure things out
02:39.23brlcadbhinesley: have you read through the oed tutorial?  if not, I would recommend it as it explains a lot of 'why' oed behaves the way it does, which mostly relates to implementation detail
02:40.05brlcadlike how a keypoint is specified (it's the right-hand side, first natural coordinate)
03:21.34*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
03:36.43CIA-62BRL-CAD: 03brlcad * r45153 10/brlcad/trunk/bench/run.sh:
03:36.43CIA-62BRL-CAD: fix off-by-one bug where TIMEFRAME=0 was causing all testing to get skipped. it
03:36.43CIA-62BRL-CAD: should at least run all tests once. also fixed a bug where it was reporting
03:36.43CIA-62BRL-CAD: success if previous pix files were still in the run directory, even if rt
03:36.43CIA-62BRL-CAD: failed. now handles negative time values too (by clamping to min).
03:45.01*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
03:53.01CIA-62BRL-CAD: 03brlcad * r45154 10/brlcad/trunk/ (38 files in 3 dirs): (log message trimmed)
03:53.01CIA-62BRL-CAD: major refactoring of the liboptical callback api to expand the function
03:53.01CIA-62BRL-CAD: callbacks with their respective parameters. in doing so, the headp mfuncs list
03:53.01CIA-62BRL-CAD: parameter was removed (only used by stack and text shaders) in favor of just
03:53.01CIA-62BRL-CAD: generating a new headp via optical_shader_init(). also ended up propagating a
03:53.02CIA-62BRL-CAD: slew of genptr_t's instead of char* and some basic constness. the stronger ansi
03:53.03CIA-62BRL-CAD: type checking revealed several inconsistencies that got caught up in the cleanup
04:12.56CIA-62BRL-CAD: 03brlcad * r45155 10/brlcad/trunk/src/ (16 files in 8 dirs): remove the antiquated msvc build files from long ago. no longer relevant with the new cmake build.
04:22.44*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565141.dsl.bell.ca)
04:30.32CIA-62BRL-CAD: 03brlcad * r45156 10/brlcad/trunk/src/liboptical/ (material.c sh_stack.c shade.c): add some sanity checks. make sure the callbacks aren't null before we call them. make sure other related struct dereferences aren't null as well otherwise do something else to avoid crashing.
04:30.54*** part/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565141.dsl.bell.ca)
04:36.26CIA-62BRL-CAD: 03brlcad * r45157 10/brlcad/trunk/src/liboptical/sh_wood.c: remove the unnecessary wood_init() routine and respective eRT dead code sections. can init to null on decl and avoid the book-keeping and function call altogether.
04:41.13bhinesleybrlcad: yes, I've read the oed tutorial.
04:43.11bhinesleyI haven't really done anything that involves directly manipulating graphics objects, until now. It's taking a lot to understand how that works.
04:44.39bhinesley(for me) :)
04:45.47CIA-62BRL-CAD: 03brlcad * r45158 10/brlcad/trunk/src/burst/Hm.h: comment cleanup and s/<control>/CONTROL/
04:48.09CIA-62BRL-CAD: 03bhinesley * r45159 10/brlcad/trunk/src/libged/translate.c: use struct db_full_path, not char[]
04:55.09CIA-62BRL-CAD: 03brlcad * r45160 10/brlcad/trunk/src/conv/ (g-xxx.c walk_example.c): don't declare UNUSED params to doxygen, just bitches about them. if you list some params, though, you should list all of them (except UNUSED ones).
04:56.07CIA-62BRL-CAD: 03brlcad * r45161 10/brlcad/trunk/src/libbn/axis.c: add param docs missing from a couple funcs
04:59.08CIA-62BRL-CAD: 03bhinesley * r45162 10/brlcad/trunk/src/libged/translate.c: fix whitespace (ws.sh)
05:52.11*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
06:43.22*** join/#brlcad Stattrav (~Stattrav@122.167.214.98)
06:43.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:20.02*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
07:32.29*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
07:32.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:23.39*** join/#brlcad merzo (~merzo@193.254.217.44)
08:57.51*** join/#brlcad Stattrav (~Stattrav@122.167.214.98)
08:57.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:17.30*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
09:17.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:03.41*** join/#brlcad merzo (~merzo@193.254.217.44)
10:32.18CIA-62BRL-CAD: 03brlcad * r45163 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: wrap diagrams in @code/@endcode
10:38.43CIA-62BRL-CAD: 03brlcad * r45164 10/brlcad/trunk/src/rt/do.c: remove appearance of tags for parsing
10:41.58CIA-62BRL-CAD: 03brlcad * r45165 10/brlcad/trunk/src/shapes/fence.h: doxygenify comments
10:45.37CIA-62BRL-CAD: 03brlcad * r45166 10/brlcad/trunk/src/util/pixfade.c: remove tag appearance
10:45.54CIA-62BRL-CAD: 03brlcad * r45167 10/brlcad/trunk/src/vdeck/vdeck.c: wrap table in @code/@endcode
10:59.02CIA-62BRL-CAD: 03kunigami * r45168 10/brlcad/trunk/src/liboptical/ (6 files): moving sh_osl.c to sh_osl.cpp
11:00.16CIA-62BRL-CAD: 03brlcad * r45169 10/brlcad/trunk/include/bu.h: match @param variable names with the function so it knows which is which. clean up formatting on the @code/@endcode sections
11:00.38CIA-62BRL-CAD: 03brlcad * r45170 10/brlcad/trunk/include/wdb.h: if you're going to annotate one of the parameters, they all have to be annotated.
11:01.05CIA-62BRL-CAD: 03brlcad * r45171 10/brlcad/trunk/src/librt/vlist.c: document the other param
11:03.04CIA-62BRL-CAD: 03brlcad * r45172 10/brlcad/trunk/src/libwdb/reg.c: if you document one of them, document all of them
11:07.46CIA-62BRL-CAD: 03brlcad * r45173 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: function sig consistency
11:14.21CIA-62BRL-CAD: 03brlcad * r45174 10/brlcad/trunk/include/rtgeom.h: comment cleanup. put latex equation into a code block.
12:25.22CIA-62BRL-CAD: 03kunigami * r45175 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt init.c osl_rt.cpp): implemented a simple mirror shader on osl_rt to make sure we can combine osl shaders with other shaders. it worked\!
12:26.59kunigamibrlcad: any news on the "struct mfuncs" support to C++?
12:30.42CIA-62BRL-CAD: 03starseeker * r45176 10/brlcad/trunk/src/other/CMakeLists.txt: Reorder things a bit.
12:31.09CIA-62BRL-CAD: 03starseeker * r45177 10/brlcad/trunk/src/ (8 files in 8 dirs): dsp files are no more, so we don't need to ignore them.
14:41.43*** join/#brlcad crazy_imp (~mj@a89-182-132-98.net-htp.de)
14:42.18brlcadkunigami: I just checked in all of the changes this morning
14:42.52brlcader, last night even .. r45154
14:43.50brlcadso now they're properly expanded global function callbacks
14:44.54brlcadyou'll still want extern "C" linkage, but should be able to hook in your callbacks from the C++ side warning-free
15:01.30*** join/#brlcad _psilva (~silvap@static-96-255-52-7.washdc.fios.verizon.net)
15:46.34brlcadkunigami: you may have noticed, but larry just added a slew of comments to the testshader example, explaining everything in more detail
15:46.38brlcadhttps://github.com/lgritz/OpenShadingLanguage/blob/e7673afe1c1c9467eba48e7a836904999f80a1cf/src/testshade/testshade.cpp
15:46.46kunigamibesides declaring each _setup, _render, _print and _free surrounded with extern "C", should I take any other care? The compiling goes fine, but when I try to run ./rt, it gives me undefined symbol for osl_setup
15:47.24brlcadyou declare the bu_structparse table, then add that table to init.c
15:47.43brlcadI think I saw a recent previous commit where you removed it from init
15:48.08kunigamiI added it back already
15:48.54brlcadthere's nothing more to it other than those two steps that come to mind
15:48.58brlcadwhat's the actual error?
15:49.20kunigami./rt: symbol lookup error: /home/kunigami/workspace/dev/bin/brlcad-bin/lib/liboptical.so.19: undefined symbol: osl_setup
15:49.41kunigamiI'll try a clean compiling here (I've been updating only from src/liboptical)
15:50.16brlcadthe function is implemented in an extern "C" block too?
15:50.40kunigamino, but it's hidden from the C code
15:52.42kunigamiabout the testrender update: great! I'll read it later! Maybe it helps me improving the current system I've been using almost like copy & paste
15:52.53brlcadwhat do you mean hidden?
15:53.02brlcadthe callback functions aren't "hidden"
15:53.32brlcadthey can be HIDDEN (i.e., static), but have to be globally addressable otherwise you'll get ... a runtime error ;)
15:53.59brlcadI'm betting it's extern "C" linkage
15:54.05brlcadadd that to the function decl
15:54.17brlcadextern "C" int osl_setup(...) { ...
16:00.10kunigamihmm ok! I don't know why I though that each shader was compiled as a separated unit and then dynamically linked to liboptical :P Fixing that
16:10.16kunigamiworked. thanks!
16:10.17brlcadthere is code in there that will dynamically load new shaders
16:10.38brlcadbut they'd still need to be extern "C" so the symbol names are mangled
16:16.54CIA-62BRL-CAD: 03178.73.220.94 07http://brlcad.org * r2932 10/wiki/MGED_CMD_saveview:
16:19.02CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2933 10/wiki/MGED_CMD_saveview: Reverted edits by [[Special:Contributions/178.73.220.94|178.73.220.94]] ([[User talk:178.73.220.94|Talk]]); changed back to last version by [[User:Sean|Sean]]
16:19.14CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:178.73.220.94]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
16:39.25CIA-62BRL-CAD: 03brlcad * r45178 10/brlcad/trunk/TODO: notes on benchmark suite
16:39.49CIA-62BRL-CAD: 03brlcad * r45179 10/brlcad/trunk/TODO: erase/erase_all merged
16:44.12CIA-62BRL-CAD: 03brlcad * r45180 10/brlcad/trunk/TODO: the rename will ideally have to wait until the next minor update now
16:50.53*** join/#brlcad Stattrav (~Stattrav@117.202.27.251)
16:50.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:17.25*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
17:17.33*** join/#brlcad Stattrav (~Stattrav@117.202.27.251)
17:17.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:19.51*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
17:31.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:41.09kunigamihmm I think I'm doing something wrong :P the sphere was supposed to be the osl shader http://imageshack.us/photo/my-images/16/weirdje.png/
17:47.13kunigamiI'll try adding supersampling
18:04.50CIA-62BRL-CAD: 03kunigami * r45181 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt init.c osl-renderer.cpp sh_osl.cpp): finished porting sh_osl.c to sh_osl.cpp and added some code to integrate osl (but is not working properly)
18:49.49brlcadkunigami: your #ifdef __cplusplus sections in sh_osl.cpp ...
18:49.57brlcadwhen will they ever be false? :)
18:52.12kunigamihmm probably not :)
18:53.49CIA-62BRL-CAD: 03kunigami * r45182 10/brlcad/trunk/src/liboptical/sh_osl.cpp: removed useless cplusplus macros
18:53.53brlcadthe only conditional you might consider would be a toggle on whether OSL is available or not, OSL_ENABLED or WITH_OSL or somesuch
18:54.10brlcadbut that'd only be so you could print "oops, osl not available"
18:55.32brlcadso educate me a little bit -- how does osl shade a pixel given a hit point and normal?
18:55.44brlcadwhat do you provide to osl?
18:59.42kunigamiFrom the testrender example, I think for each pixel we need to provide osl with object normal, incident ray and hit point -- for the most basic case
19:02.45brlcadso then how does it shade given that info?
19:03.46kunigamiactually we also need to provide a shaderstate, which seems to contain information about which osl shader is being used
19:04.01brlcadhow might I take light source visibility into an account, for example, if I'm trying to write an osl shader
19:05.01kunigamiI think that it's done through recursion. When a ray hit a non-emitter surface, it is propagated
19:05.28kunigamiwhen it finally hits a emitter, it just return its color
19:05.33brlcadhow does that happen?  osl didn't shoot the primary ray
19:06.59kunigamiit calculates the output direction from the incident ray and the normal, I think
19:07.33brlcadthat would imply to me that there has to be some way either to register with osl how rays are fired (e.g. register a callbackup that ends up calling rt_shootray()), or call into osl for info to know when a new ray needs to be fired to compute some shader info
19:07.57brlcadsure, it'll know the direction, but it doesn't exactly have any logic to shoot a ray
19:09.00brlcadotherwise, osl would also require the geometry in some format and it wouldn't be a shading library, it'd be a raytracer :)
19:09.15kunigamiIn testrender this logic was implemented along the radiance function. In sh_osl I'm explict calling  rt_shootray
19:10.29CIA-62BRL-CAD: 03brlcad * r45183 10/brlcad/trunk/src/libged/translate.c: c99-style // comments can't be used in C files, must be c89 compliant
19:11.28brlcadi'm not familiar with testrender .. is the radiance function something written in C/C++ and provided to OSL?
19:12.28kunigamino, radiance was a function written by the author of testrender. It's a simple intersection system to find which of the spheres of the scene was hit by the given ray
19:13.37brlcadso in your weirdje image, which shader is on that sphere?
19:14.25brlcadthe reason I'm asking, trying to understand how we'll put this integration to use down the road
19:14.44kunigamithat's an osl shader, which should be a perfect diffuse yellow
19:15.06brlcadI know from a high-high level what OSL is capable of, it's how it gets integrated that seems still to be a mystery
19:16.04brlcadso perfect diffuse, it should be a shader that just needs the ray, object hit point, and surface normal
19:16.14kunigamiyes
19:16.19brlcadso it shades based on the cosine angle, basically light coming from the camera
19:16.42brlcadso why is the bottom of the sphere bright and the top dark then? :)
19:17.40brlcadthat also implies an another open question: how might one implement a phong shader with OSL
19:18.15kunigamiIt seems it's acting like a mirror (the top of the scene is dark and the floor is bright)
19:18.43brlcadhm, true
19:19.33brlcadah, your firing a ray for each hit point, aren't you -- a ray down the normal or something
19:19.53brlcadthe color it gets will be a mirror-like color
19:21.29kunigamiyes, but it's exactly the same thing I do on osl_rt and there the color is as expected
19:21.55brlcadapparently not "exactly" the same :)
19:25.05kunigamithe difference is that in osl_rt all shaders (except the mirror) are osl ones. Probably some information is being stored in the system when a ray jumps from an object to another.
19:25.15brlcadonce you get diffuse working, I'd suggest trying to get a simplistic phong shader implemented, since that really begs questions on how the OSL API is supposed to handle secondary queries
19:28.58brlcadyou could use the cornell box example and make all objects have an osl shader
19:29.06brlcadno sense making it more complicated than it needs to be
19:44.37*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
19:50.52CIA-62BRL-CAD: 03r_weiss * r45184 10/brlcad/trunk/src/libbu/list.c: Fixed a bug in function 'bu_list_reverse' within file 'list.c' of the 'libbu' library. A 'struct bu_list' was not initialized correctly causing a segmentation fault.
19:58.07CIA-62BRL-CAD: 03r_weiss * r45185 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c:
19:58.07CIA-62BRL-CAD: Updated function 'nmg_booltree_evaluate' within file 'nmg_bool.c'. Removed the
19:58.07CIA-62BRL-CAD: call to 'nmg_model_fuse' since it is not necessary here. This is called later
19:58.08CIA-62BRL-CAD: within function 'nmg_bool'. This change will increase the speed in which nmg
19:58.08CIA-62BRL-CAD: boolean operations are performed. For example, the mged command 'facetize' will
19:58.08CIA-62BRL-CAD: run faster.
20:13.48CIA-62BRL-CAD: 03r_weiss * r45186 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c:
20:13.48CIA-62BRL-CAD: Updated functions 'nmg_class_pt_s', 'class_eu_vs_s' and 'class_fu_vs_s' within
20:13.48CIA-62BRL-CAD: file 'nmg_class.c'. The changes will increase the speed in which nmg boolean
20:13.48CIA-62BRL-CAD: operations are performed. For example, the mged command 'facetize' will run
20:13.48CIA-62BRL-CAD: faster. The change adds a compare to the shell bounding box to exclude nmg
20:13.49CIA-62BRL-CAD: objects (shell,face,loop,edge,vertex) as early as possible in the classification
20:13.50CIA-62BRL-CAD: to prevent extra processing.
20:17.12CIA-62BRL-CAD: 03brlcad * r45187 10/brlcad/trunk/db/ (CMakeLists.txt Makefile.am cornell.rt): add a view script for the cornell box that can be used to restore a prototypical view inside the box.
20:18.29brlcadkunigami: that view script may be of interest -- if you run it (sh cornell.rt), it should render a typical view of the existing cornell.g model
20:18.47CIA-62BRL-CAD: 03r_weiss * r45188 10/brlcad/trunk/include/vmath.h:
20:18.47CIA-62BRL-CAD: Added macro 'V3PT_OUT_RPP_TOL' to file 'vmath.h' which tests if a vertex is
20:18.47CIA-62BRL-CAD: outside a bounding box by at least the distance tolerance. This macro supports
20:18.47CIA-62BRL-CAD: changes to functions 'nmg_class_pt_s' and 'class_eu_vs_s' within file
20:18.47CIA-62BRL-CAD: 'nmg_class.c'.
20:18.48brlcadmay be useful for tweaking the cornell.g model to be all osl shaders
20:18.55brlcadfor testing
20:25.17CIA-62BRL-CAD: 03r_weiss * r45189 10/brlcad/trunk/src/librt/primitives/nmg/nmg_pt_fu.c:
20:25.17CIA-62BRL-CAD: Updated function 'nmg_class_pt_lu_except' within file 'nmg_pt_fu.c'. Improved
20:25.17CIA-62BRL-CAD: the test against the loop bounding box by added the distance tolerance and
20:25.17CIA-62BRL-CAD: changed the macro so that the point must be at least the distance tolerance
20:25.17CIA-62BRL-CAD: outside the loop bounding box to be excluded.
20:31.03CIA-62BRL-CAD: 03brlcad * r45190 10/brlcad/trunk/include/bu.h: don't let BU_LIST_INIT_ZERO set the magic number to BU_LIST_HEAD_MAGIC since the pointers are still NULL. the macro is only useful as a zero-initializer.
20:31.37kunigamibrlcad: thanks! I was trying to setup that scene here without much sucess
20:33.23CIA-62BRL-CAD: 03brlcad * r45191 10/brlcad/trunk/NEWS:
20:33.24CIA-62BRL-CAD: through a variety of enhancements, richard has been making headway on improving
20:33.24CIA-62BRL-CAD: the performance and reliability of the nmg/bot processing code. in particular,
20:33.24CIA-62BRL-CAD: he has eliminated duplicative model fusing and improve topology connectivity
20:33.24CIA-62BRL-CAD: evaluations so objects that previously wouldn't convert can.
20:33.53brlcadkunigami: it's a little screwy because that model uses the original cornell specification
20:34.06brlcadwith exact positioning and orientation, which doesn't match our coordinate system
20:34.39brlcadplus you want perspective for that model since you're in such a small confined space, which isn't the default
20:36.15brlcadsomeone needs to remodel the box to fix our render expectations a little bit better, and if only to toss in a sphere :)
20:39.50``Erikferrofluid http://www.youtube.com/watch?v=OsW8zctD7CM
20:44.21CIA-62BRL-CAD: 03r_weiss * r45192 10/brlcad/trunk/src/librt/primitives/ars/ars.c:
20:44.21CIA-62BRL-CAD: Updated the 'rt_ars_tess' function within file 'ars.c'. This change simplifies
20:44.21CIA-62BRL-CAD: the 'ars' primitive geometry to improve the success of performing nmg boolean
20:44.21CIA-62BRL-CAD: operations with 'ars' primitives. Commands such as mged 'facetize' will have
20:44.22CIA-62BRL-CAD: greater success when the geometry to facetize contains 'ars' primitives.
21:05.33CIA-62BRL-CAD: 03128.63.32.62 07http://brlcad.org * r2934 10/wiki/Lexer_Parser: /* Parsers */ - add note pointing to lemon example
21:40.57CIA-62BRL-CAD: 03r_weiss * r45193 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed)
21:40.57CIA-62BRL-CAD: Fixed a bug in function 'nmg_triangulate_rm_degen_loopuse' which caused an
21:40.57CIA-62BRL-CAD: infinite loop when a loopuse contains a single vertexuse instead of a list of
21:40.57CIA-62BRL-CAD: edgeuse. The function now also kills all loopuse which contain only a single
21:40.57CIA-62BRL-CAD: vertexuse. The associated single vertexuse is also killed. This function
21:40.57CIA-62BRL-CAD: supports the new prototype function 'nmg_triangulate_fu' (nmg triangulate
21:40.58CIA-62BRL-CAD: faceuse). Preprocessor commands are added so these updates/additions are
21:57.34*** join/#brlcad crazy_imp (~mj@a89-182-130-99.net-htp.de)
22:00.00*** join/#brlcad dloman (~claymore@BZ.BZFLAG.BZ)
22:00.01*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
22:00.35*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20110622

IRC log for #brlcad on 20110622

00:08.26*** join/#brlcad crazy_imp (~mj@a89-182-222-99.net-htp.de)
00:33.06CIA-62BRL-CAD: 03brlcad * r45194 10/brlcad/trunk/NEWS:
00:33.06CIA-62BRL-CAD: in addition to the general enhancements to nmg processing, there was a specific
00:33.06CIA-62BRL-CAD: simplification/improvement to ARS->NMG conversion so that facetize and exports
00:33.06CIA-62BRL-CAD: will have greater success. merges coplaner faces and simplifies the shells.
00:42.46*** join/#brlcad crazy_imp (~mj@a89-182-162-253.net-htp.de)
03:17.00CIA-62BRL-CAD: 03brlcad * r45195 10/brlcad/trunk/include/brep.h: file name is brep.h, not on_nurb.h
03:25.42CIA-62BRL-CAD: 03brlcad * r45196 10/brlcad/trunk/src/conv/ (26 files): denote as being conv files in order to avoid conflicting with same-named files in other dirs
06:19.26*** join/#brlcad Stattrav (~Stattrav@122.167.214.98)
06:19.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:01.27*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
09:11.31*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
09:11.45pawleeqhello
12:14.28CIA-62BRL-CAD: 03erikgreenwald * r45197 10/brlcad/trunk/src/other/m4/ (gnum4.c lib/setprogname.c misc.c): hacks to get something compiling on winderz (not tested).
12:23.34brlcadkunigami: is include/osl-renderer.h being used?
13:05.00CIA-62BRL-CAD: 03brlcad * r45198 10/brlcad/trunk/src/librt/primitives/ (113 files in 36 dirs): include paths to remove ambiguity with same-named files in other directories
13:17.16CIA-62BRL-CAD: 03brlcad * r45199 10/brlcad/trunk/src/ (132 files in 10 dirs): make the @file name match the file name, disambiguate util files
14:01.17CIA-62BRL-CAD: 03brlcad * r45200 10/brlcad/trunk/src/libpc/pcParameter.h: ws
14:02.21CIA-62BRL-CAD: 03brlcad * r45201 10/brlcad/trunk/src/libpc/pcParameter.h: declare the makeIterator() functions
14:09.51CIA-62BRL-CAD: 03brlcad * r45202 10/brlcad/trunk/src/other/openNURBS/ (CMakeLists.txt Makefile.am): opennurbs_x has nothing to do with X11, it deals with surface/curve intersection events. enable it for compilation.
14:10.13CIA-62BRL-CAD: 03brlcad * r45203 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: don't pretend to be openNURBS
14:11.44CIA-62BRL-CAD: 03brlcad * r45204 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: @check is no-good, @brief
14:16.13CIA-62BRL-CAD: 03brlcad * r45205 10/brlcad/trunk/src/libdm/dm-plot.c: not an e-mail, change to name. doxygenify, use INIT_ZERO.
14:19.57CIA-62BRL-CAD: 03brlcad * r45206 10/brlcad/trunk/include/dvec.h: describe the typedefs
14:20.23CIA-62BRL-CAD: 03brlcad * r45207 10/brlcad/trunk/ (include/wdb.h src/libwdb/reg.c): comments belong in header, only say it once.
14:33.40*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
14:37.54*** join/#brlcad d_rossbe1g (~rossberg@BZ.BZFLAG.BZ)
14:47.43*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
15:03.35*** join/#brlcad mafm (~mafm@243.Red-88-26-141.staticIP.rima-tde.net)
15:16.31*** join/#brlcad Stattrav (~Stattrav@117.202.19.109)
15:16.31*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:00.25*** join/#brlcad Elrohir (~kvirc@p5B14AEB2.dip.t-dialin.net)
16:32.15*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
16:50.47CIA-62BRL-CAD: 03brlcad * r45208 10/brlcad/trunk/include/bu.h: move around the grouping so that all of the libbu groups are within the libbu group. needs lots more work.
16:53.35brlcadhello pawleeq
17:30.25CIA-62BRL-CAD: 03brlcad * r45209 10/brlcad/trunk/include/bu.h:
17:30.25CIA-62BRL-CAD: remove all of the B U _ expanded function names. it helped find API functions
17:30.25CIA-62BRL-CAD: in the source files where they were mixed with implementation code, but in the
17:30.25CIA-62BRL-CAD: header, it's all API. moreover, it makes our documenting job harder since it
17:30.25CIA-62BRL-CAD: prevents auto-brief (recognition of the first line/sentance as a brief
17:30.25CIA-62BRL-CAD: description). with the title removed, we can remove all of the @brief markers
17:30.26CIA-62BRL-CAD: too.
17:33.04CIA-62BRL-CAD: 03brlcad * r45210 10/brlcad/trunk/include/bu.h: deprecated is not a doxygen command, just make it the first line instead. make bu_cv_w_cookie() params match declared param names.
17:34.36CIA-62BRL-CAD: 03brlcad * r45211 10/brlcad/trunk/src/libbu/ (22 files): remove all group inclusions from the source files. cleans up output since the groups were disjoint from those described in the header file and makes it easier to rearrange public API in one place.
18:00.05kunigamibrlcad: yes, osl-renderer.h is used by sh_osl
18:26.35*** join/#brlcad Stattrav (~Stattrav@117.202.19.109)
18:26.35*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:38.03*** join/#brlcad Stattrav (~Stattrav@117.202.19.109)
18:38.03*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:46.02*** join/#brlcad Stattrav (~Stattrav@117.202.19.109)
18:46.02*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:48.02brlcadkunigami: there are two
18:49.24CIA-62BRL-CAD: 03kunigami * r45212 10/brlcad/trunk/include/osl-renderer.h: old version of osl-renderer.h that I forgot to delete. It was moved to liboptical
18:49.46brlcadmade sure it's not in the CMakeLists or Makefile.am?
18:50.53kunigamibrlcad: thanks
18:51.00CIA-62BRL-CAD: 03kunigami * r45213 10/brlcad/trunk/include/CMakeLists.txt: removing osl-renderer.h from CMakeLists.txt
18:59.57*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
19:01.30*** join/#brlcad Stattrav (~Stattrav@117.202.19.109)
19:01.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:14.18*** join/#brlcad Stattrav (~Stattrav@117.202.19.109)
19:14.18*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:03.17CIA-62BRL-CAD: 03bhinesley * r45214 10/brlcad/trunk/src/libged/translate.c: adding 'combination' argument, more robust argument handling
20:06.28CIA-62BRL-CAD: 03bhinesley * r45215 10/brlcad/trunk/src/libged/translate.c: oops, poorly formatted error
20:08.01CIA-62BRL-CAD: 03bhinesley * r45216 10/brlcad/trunk/src/libged/translate.c: heh, still wrong
20:23.15*** join/#brlcad Stattrav (~Stattrav@117.202.19.109)
20:23.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:39.40CIA-62BRL-CAD: 03brlcad * r45217 10/brlcad/trunk/include/ (bu.h cmd.h magic.h vfont-if.h): naturally still needs a lot more work, but sort out more high-level organization of the API sections. top-level groups aren't set yet, but lower-level ones now have fuller names
20:51.03bhinesleyhow can I check that the path to a combination/object is valid? For instance, primitive.s/region.r is a bad path.
20:51.23bhinesleyI mean, is there a function that handles this
20:52.10bhinesleydoh, I guess that would be db_lookup
21:21.35CIA-62BRL-CAD: 03bhinesley * r45218 10/brlcad/trunk/src/libged/translate.c: added checks for existence of paths that are passed in
21:23.33CIA-62BRL-CAD: 03kunigami * r45219 10/brlcad/trunk/src/liboptical/sh_osl.cpp: added a parameter to osl_specifics to hold the shadername
21:49.57CIA-62BRL-CAD: 03bhinesley * r45220 10/brlcad/trunk/src/libged/translate.c: Cleanup, store strings so that conversions aren't needed later, use LOOKUP_NOISY. There remains a problem doing a db_lookup on s_full_path.
23:34.49*** join/#brlcad kunigami_ (~kunigami@201.53.197.251)
IRC log for #brlcad on 20110623

IRC log for #brlcad on 20110623

00:45.08*** join/#brlcad crazy_imp (~mj@a89-182-188-243.net-htp.de)
00:58.04*** join/#brlcad kunigami_ (~kunigami@201.53.197.251)
01:16.32CIA-62BRL-CAD: 03kunigami * r45221 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt osl_rt2.c): the C osl raytracer example is no longer necessary
01:59.42kunigami_when shooting a new ray from a shader, is it better to define a new struct application or to use the same we receive as parameter?
02:09.08*** join/#brlcad ibot (~ibot@rikers.org)
02:09.08*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
02:13.09*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
06:33.55*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
06:37.07*** join/#brlcad Stattrav (~Stattrav@122.167.214.98)
06:37.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:42.11*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
09:39.38*** join/#brlcad Elrohir (~kvirc@p5B14A86A.dip.t-dialin.net)
09:52.27*** join/#brlcad mafm (~mafm@102.Red-81-32-97.dynamicIP.rima-tde.net)
09:55.29*** join/#brlcad mafm_ (~mafm@102.Red-81-32-97.dynamicIP.rima-tde.net)
10:04.45*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
10:04.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:18.14*** join/#brlcad Stattrav_ (~Stattrav@122.167.214.98)
10:45.54*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
11:16.55*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
12:18.37*** join/#brlcad kunigami (~kunigami@201.53.197.251)
12:27.46*** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br)
13:32.06*** join/#brlcad merzo (~merzo@193.254.217.44)
14:00.51starseeker``Erik: http://www.amazon.com/Parsing-Techniques-Practical-Monographs-Computer/dp/1441919015
14:01.01starseekerthat looks interesting (if a bit expensive)
16:31.20*** join/#brlcad Elrohir (~kvirc@p5B14A86A.dip.t-dialin.net)
16:35.13kunigamiis "quaturnion" a typo of "quaternion" or it is actually a valid word?
16:37.58*** join/#brlcad Stattrav (~Stattrav@117.192.130.174)
16:37.58*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:04.45``ErikI'd assume it's a misspelling
19:05.14CIA-62BRL-CAD: 03bob1961 * r45222 10/brlcad/trunk/src/tclscripts/mged/text.tcl: Modified the "gets" proc to use the last line in getsVal.
20:57.13CIA-62BRL-CAD: 03starseeker * r45223 10/brlcad/trunk/src/libpc/CMakeLists.txt: Add libz to the libpc include dirs
21:43.32*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
21:49.42*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
22:04.00kunigamiIn the script db/cornell.rt, the parameter "orientation" is 4-dimensional. If I understood right, it is representing a quaternion. I just learned what a quaternion is and how it can represent a rotation around a given axis. Can I extract the viewing direction from this quaternion?
23:50.21starseekersweet:  http://www.ibm.com/developerworks/library/l-lexyac/index.html
IRC log for #brlcad on 20110624

IRC log for #brlcad on 20110624

00:06.32CIA-62BRL-CAD: 03bhinesley * r45224 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: set outdated argument list to void
00:08.10CIA-62BRL-CAD: 03bhinesley * r45225 10/brlcad/trunk/include/raytrace.h: we have a DB_FULL_PATH_CUR_DIR, so why not add a DB_FULL_PATH_DOOR_DIR, too.
00:10.23CIA-62BRL-CAD: 03bhinesley * r45226 10/brlcad/trunk/src/libged/translate.c: Adding ged_ispath to determine if supplied paths exist. Previous translate cmd tests were all wrong, and were removed. I'll find a better home for ispath once it's working. Not sure if it needs to be an actual command.
00:11.42bhinesleythings are starting to make sense (finally)
00:12.32bhinesleyunderstanding the database format has been a struggle... new to me
00:14.43bhinesleyhaha, that's DB_FULL_PATH_ROOT_DIR, not DOOR_DIR
00:15.22bhinesley's brain is fried
00:31.53CIA-62BRL-CAD: 03bhinesley * r45227 10/brlcad/trunk/include/raytrace.h: r45225 added DB_FULL_PATH_ROOT_DIR, not DB_FULL_PATH_DOOR_DIR
00:45.31*** join/#brlcad crazy_imp (~mj@a89-182-163-109.net-htp.de)
01:50.54CIA-62BRL-CAD: 03kunigami * r45228 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt osl_rt.cpp):
01:50.54CIA-62BRL-CAD: modifying osl_rt so that it renders brl-cad scenes. It shoots its own rays and
01:50.54CIA-62BRL-CAD: calls rt_shootray. I'm using the cornel.g db, with the parameters in
01:50.54CIA-62BRL-CAD: db/cornell.rt script. By now, it justs prints a message when a object is hit.
01:50.54CIA-62BRL-CAD: Next step is to identify the name of the osl-shader the object belongs to
02:02.23CIA-62BRL-CAD: 03bhinesley * r45229 10/brlcad/trunk/src/libged/translate.c: ged_ispath should use standard GED function return codes
02:05.45CIA-62BRL-CAD: 03kunigami * r45230 10/brlcad/trunk/src/ (5 files in 4 dirs): changed occurrences of quaturnion by quaternion
02:32.36*** join/#brlcad ibot (~ibot@rikers.org)
02:32.36*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
02:37.02*** join/#brlcad ibot (~ibot@rikers.org)
02:37.02*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.18.4 is posted! (20110412)
04:01.32*** join/#brlcad DarkCalf (DC@173.231.40.98)
04:08.45CIA-62BRL-CAD: 03bhinesley * r45231 10/brlcad/trunk/src/libged/translate.c: ged_is_path is now functioning (privately) :) It would be useful for several functions, so they can check paths and not die a meaningless death like 'ls shell.c/nut.c'. Now to find it a home.
04:13.48bhinesleybrlcad: really hoping I didn't duplicate any functionality with that one ^
04:13.48bhinesleyI looked around but couldn't find anything that did the trick. Assuming that I haven't, any suggestions on where it should live and/or what it should be named?
04:35.43CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2935 10/wiki/User:Bhinesley: /* Log */ last few days, today, plan tomorrow+
04:39.23CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2936 10/wiki/User:Bhinesley: /* Log */ clarified dates an item was worked on
06:59.46*** join/#brlcad Stattrav (~Stattrav@117.192.148.225)
06:59.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:17.54*** join/#brlcad merzo (~merzo@193.254.217.44)
07:58.22*** join/#brlcad Stattrav (~Stattrav@117.202.16.22)
07:58.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:03.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:15.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:20.43*** join/#brlcad Stattrav_ (~Stattrav@117.192.154.61)
09:15.31*** join/#brlcad mafm_ (~mafm@162.Red-83-38-35.dynamicIP.rima-tde.net)
11:20.19brlcadkunigami: it's usually better to define a new struct application for each new ray segment being fired
11:23.02brlcadkunigami: orientation is a quaternion (and that was a set of typos) and yes, you can extract the viewing direction (which is what the mged "loadview" command partially does
11:26.20brlcadbhinesley: hope you didn't too as low-level functionality like that is easy to replicate (because it can be hard to find unless you wrote it)
11:27.41brlcadI wouldn't be surprised if that logic existed somewhere but the important part is that it's not readily documented, so if your implementat does anything new, it should be that ;)
11:28.46brlcadfor now, I'd treat is as private (documented) libged API (src/libged/ged_private.h)
11:31.05brlcadlibged is supposed to consist of a private API for reuse across ged functions and the public API for external reuse and transactional access into the struct ged
11:33.54brlcadstarseeker: best way to learn lex/yacc, highly recommended -- use that tutorial and write a simple parser for something real but not too complicated (maybe a povray parser or a csv parser)
12:12.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:29.51*** join/#brlcad merzo (~merzo@193.254.217.44)
12:35.27kunigamiI've a strange linker error: http://pastebin.mozilla.org/1256847
12:36.35kunigamiit does not find mlib_setup, even tough I'm linking to liboptical and this function is in the liboptical table
12:37.15kunigamithere's a strange warning too: warning: can't find atom for N_GSYM stabs ep:G(0,423) in CMakeFiles/osl_rt.dir/osl_rt.cpp.o
12:48.25kunigamithis error happens both on mac and linux :(
13:00.01starseekermakes a note to study this more carefully, even though src/other may make it impractical: http://www.vtk.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
14:56.01CIA-62BRL-CAD: 03bhinesley * r45232 10/brlcad/trunk/src/libged/translate.c: check for empty tree is unnecessary, as db_find_named_leaf will return correctly either way
15:25.28CIA-62BRL-CAD: 03bhinesley * r45233 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am ged_private.h path.c translate.c): Renamed ged_is_path to _ged_path_validate, and moved it into a seperate file. Exposed it via ged_private.
15:39.32CIA-62BRL-CAD: 03bhinesley * r45234 10/brlcad/trunk/src/libged/path.c: Document _ged_path_validate interface
16:09.54CIA-62BRL-CAD: 03erikgreenwald * r45235 10/brlcad/trunk/src/libged/translate.c: change strtof to strtod. fastf_t is double and windows doesn't have strtof.
16:16.10kunigamiI'm trying to extract the view direction from the quaternion with the following code: http://pastebin.mozilla.org/1256899 Though the scene that is rendered is not the same as when I run it with cornell.rt script.
16:26.13CIA-62BRL-CAD: 03erikgreenwald * r45236 10/brlcad/trunk/ (include/ged.h src/libged/path.c src/libged/translate.c): Remove _ prefix from _ged_path_validate and add prototype to ged.h.
16:37.14*** join/#brlcad yiyus (1242712427@server1.bouncer4you.de)
16:54.07*** join/#brlcad mafm (~mafm@162.Red-83-38-35.dynamicIP.rima-tde.net)
17:10.36CIA-62BRL-CAD: 03bhinesley * r45237 10/brlcad/trunk/src/libged/ged_private.h: r45236 put ged_path_validate in ged.h, so remove it from ged_private.h
17:30.12*** join/#brlcad Stattrav_ (~Stattrav@117.192.154.61)
17:46.56*** join/#brlcad roberthl (~robert@mediawiki/RobertL)
18:49.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:06.58*** join/#brlcad Stattrav (~Stattrav@117.192.154.61)
19:06.58*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:29.36*** join/#brlcad Stattrav (~Stattrav@117.192.154.61)
19:29.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:41.43*** join/#brlcad Stattrav_ (~Stattrav@117.192.154.61)
20:17.43CIA-62BRL-CAD: 03bhinesley * r45238 10/brlcad/trunk/src/ (66 files in 32 dirs): Quieted all 511 warnings about using number formatting other than %zu for a size_t argument.
21:24.21*** join/#brlcad kunigami (~kunigami@201.53.197.251)
22:13.24*** join/#brlcad Stattrav (~Stattrav@117.192.154.61)
22:13.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:21.46*** join/#brlcad Stattrav (~Stattrav@117.192.154.61)
22:21.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:29.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:47.28*** join/#brlcad Stattrav (~Stattrav@117.192.154.61)
22:47.28*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:53.48*** join/#brlcad Stattrav (~Stattrav@117.192.154.61)
22:53.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
23:02.13*** join/#brlcad Stattrav (~Stattrav@117.192.154.61)
23:02.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
23:13.01bhinesleyfor a windows cmake build, do we use mingw32-make.exe? I can't seem to get it to work: http://pastebin.mozilla.org/1257485
23:35.28*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
23:45.04*** join/#brlcad Stattrav (~Stattrav@117.192.154.61)
23:45.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
IRC log for #brlcad on 20110625

IRC log for #brlcad on 20110625

00:45.50*** join/#brlcad crazy_imp (~mj@a89-182-180-139.net-htp.de)
01:29.25CIA-62BRL-CAD: 03kunigami * r45239 10/brlcad/trunk/src/liboptical/ (osl-renderer.cpp osl_rt.cpp):
01:29.25CIA-62BRL-CAD: updated version of osl_rt. It now renders brlcad scenes using osl shaders. the
01:29.25CIA-62BRL-CAD: results are still strange, but are getting better. I managed to find a suitable
01:29.25CIA-62BRL-CAD: direction for the viewpoint for the scene cornell.g on db/. I did it
01:29.25CIA-62BRL-CAD: empirically, since I couldnt extract this information from the orientation
01:29.26CIA-62BRL-CAD: quaternion.
01:33.29kunigamihttp://dl.dropbox.com/u/1399996/GSoC/OSL_RT-2011-06-24.png -- is the result from the latest osl ray tracer. the scene is the cornell.g. walls are of diffuse blue, floor is diffuse red. Tall box diffuse yellow and short box is mirror. The light in the ceiling is an emitter shader. (the scene is kinda dark. in the next render I'll try a stronger emission value)
07:04.43*** join/#brlcad merzo (~merzo@193.254.217.44)
07:51.13*** join/#brlcad Stattrav (~Stattrav@117.192.154.61)
07:51.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:52.32*** join/#brlcad Stattrav_ (~Stattrav@117.192.154.61)
08:24.40*** join/#brlcad Stattrav (~Stattrav@117.192.133.205)
08:24.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:34.13``Erikis the shader you're using a path tracer? photon mapper?
12:35.30``Erikhave you tried a simple phong shader and compared to non-osl raytraces to try to get the input mapping for osl?
12:35.54``Erik(pretty cool, btw)
13:28.43kunigami1To tell the truth, I actually don't know the difference between path tracer and photon mapper :P I've just adapted a previous renderer that some guy implemented for osl
13:29.13kunigami1I still have to make tests with phong shaders and glass too (thanks)
15:55.02starseekerO.o  http://www.bloodhoundssc.com/car/facts_and_figures/cad_drawings.cfm
16:13.03starseekerneed to translate 'em to STEP...
17:46.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:00.32*** join/#brlcad michael (~michael@cpe-24-210-25-11.columbus.res.rr.com)
18:02.44*** join/#brlcad Otto__ (~Otto@cpe-24-210-25-11.columbus.res.rr.com)
18:03.13*** join/#brlcad Otto__ (~Otto@cpe-24-210-25-11.columbus.res.rr.com)
18:40.04*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
23:12.56louipcShould the channel topic be updated for the new version?
23:14.37*** join/#brlcad Otto__ (~Otto@cpe-24-210-25-11.columbus.res.rr.com)
IRC log for #brlcad on 20110626

IRC log for #brlcad on 20110626

00:46.11*** join/#brlcad crazy_imp (~mj@a89-182-228-189.net-htp.de)
01:29.25*** join/#brlcad kunigami (~kunigami@201.53.197.251)
03:29.08*** join/#brlcad Soze49 (~Soze@186.136.208.223)
03:34.24Soze49Hi, sorry if I'm out of topic but, could you please point me to some information source about making cross sections of 3d models ? I'm working with STL files, and I need yo make cross sections from the models so any advice on existent algorithms, methods, etc is what i need.
03:54.12Otto__the fastest way that I found was to make an arb8 that cut out the part you didn't want. you could also use an arb8 that would only include the area you wanted to keep.  
04:03.02Soze49but I have a 3d model made of triangle facets so the idea is to construct a bitmap of the intersection of a plane with the model
04:17.05Otto__Honestly not to be of any help, but I'm of no help. I'm not too sure of how to go about that.  May google search prove fruitful
07:42.17*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:48.14*** join/#brlcad Stattrav (~Stattrav@117.192.149.147)
08:48.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:55.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:59.07*** join/#brlcad Stattrav (~Stattrav@117.192.149.147)
14:59.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:56.08*** part/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
17:07.24*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
18:27.42*** join/#brlcad Otto_ (~Otto@cpe-24-210-25-11.columbus.res.rr.com)
19:06.08*** join/#brlcad Stattrav (~Stattrav@117.192.133.14)
19:06.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:31.45*** join/#brlcad Stattrav (~Stattrav@117.192.133.14)
22:31.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
IRC log for #brlcad on 20110627

IRC log for #brlcad on 20110627

00:45.33*** join/#brlcad crazy_imp (~mj@a89-182-161-248.net-htp.de)
01:37.22*** part/#brlcad kunigami (~kunigami@201.53.197.251)
01:40.37CIA-62BRL-CAD: 03kunigami * r45240 10/brlcad/trunk/src/liboptical/sh_osl.cpp: instead of using the same struct application, create another one when shooting a new ray
04:09.02*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
04:16.24*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
07:24.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:10.08CIA-62BRL-CAD: 03d_rossberg * r45241 10/brlcad/trunk/src/libgcv/bottess.c: fixed MSVC build: rt_bot_describe() is not DLL-exported (and it should not), used the pointer from the function table instead
11:18.35*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:26.30``Erikherr Roßberg, apologies for leaving that garbage in, it will be gone this week :)
11:33.29d_rossbergapologies accepted, sir :)
11:49.01*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
11:49.12*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
12:29.10*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
16:19.30*** join/#brlcad Stattrav (~Stattrav@117.202.29.208)
16:19.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:38.37CIA-62BRL-CAD: 03r_weiss * r45242 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: Update to quiet compiler warnings. Change was to file 'nmg_bool.c' function 'nmg_booltree_evaluate'.
17:13.47CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2937 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ Week 5
17:51.39CIA-62BRL-CAD: 03r_weiss * r45243 10/brlcad/trunk/src/librt/primitives/nmg/nmg_pt_fu.c: Updated functions 'nmg_class_pt_lu' and 'nmg_class_pt_fu_except' located within file 'nmg_pt_fu.c'. Improved the compare against nmg object bounding boxes by including the distance tolerance in the compare.
17:51.51*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
17:51.53yukonbobhello, #brlcad
17:55.14bhinesleyhi, yukonbob
18:03.00CIA-62BRL-CAD: 03starseeker * r45244 10/brlcad/trunk/src/other/CMakeLists.txt: Mark this option as adavnced - eventually it will go away altogether, once we get it straightened out what tool chain we'll be using and add ThirdParty/Find* tests for what we need.
18:14.41CIA-62BRL-CAD: 03starseeker * r45245 10/brlcad/trunk/ (misc/CMakeLists.txt src/other/CMakeLists.txt): Couple quick distcheck entries.
18:20.26bhinesleystarseeker: for a windows cmake build, do we use mingw32-make.exe? I can't seem to get it to work: http://pastebin.mozilla.org/1257485
18:21.14starseekerbhinesley: Normally we use Microsoft Visual C++
18:21.38bhinesleyok
18:21.40bhinesleythanks
18:22.14starseekerin principle other Windows build approaches should work, but it's quite a lot of time/effort to set up to try them and we just haven't lately
18:22.39bhinesleynods
18:28.21CIA-62BRL-CAD: 03starseeker * r45246 10/brlcad/trunk/src/other/Makefile.am: Ignore files in Makefile.am too.
18:31.14CIA-62BRL-CAD: 03starseeker * r45247 10/brlcad/trunk/src/other/Makefile.am: files too, not just dirs.
18:51.35*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
19:05.23*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
19:09.22*** join/#brlcad __monty__ (~toon@242.93-242-81.adsl-dyn.isp.belgacom.be)
19:10.05__monty__Hi, just looking for the latest version of brl cad that works on a ppc mac. 7.6.6?
19:19.02__monty__Oh, found it 7.10.4, excuse my laziness.
19:35.39CIA-62BRL-CAD: 03bhinesley * r45248 10/brlcad/trunk/src/libged/combmem.c: Using the first element of argv to refer to the command name doesn't work so well after you've incremented it.
22:22.12CIA-62BRL-CAD: 03bhinesley * r45249 10/brlcad/trunk/src/libged/translate.c: Don't allow -r and -k options simultaneously. Distinguish between solids and combinations.
22:28.58*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
22:31.09*** join/#brlcad merzo (~merzo@235-121-133-95.pool.ukrtel.net)
22:32.14CIA-62BRL-CAD: 03starseeker * r45250 10/brlcad/trunk/src/other/ (7 files in 7 dirs): Remove some package stuff in src/other that we don't need and is interfering with rpmbuild - byacc in particular we won't need this for since byacc is intended here only as a build aid.
22:57.35CIA-62BRL-CAD: 03starseeker * r45251 10/brlcad/trunk/src/other/ (tcl.dist tk.dist): dist files worked - complained that these files weren't there.
23:56.59*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20110628

IRC log for #brlcad on 20110628

00:13.33*** join/#brlcad merzo (~merzo@235-121-133-95.pool.ukrtel.net)
00:13.33*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
00:46.05*** join/#brlcad crazy_imp (~mj@a89-182-244-94.net-htp.de)
02:10.46CIA-62BRL-CAD: 03bhinesley * r45252 10/brlcad/trunk/ (include/ged.h src/libged/path.c src/libged/translate.c):
02:10.46CIA-62BRL-CAD: Isolating core translate functionality into a seperate function, so that it
02:10.46CIA-62BRL-CAD: could be more readily called internally. Laid out comments on how it will be
02:10.46CIA-62BRL-CAD: finished (hopefully tomorrow). Also, ged_path_validate had a parameter byval
02:10.46CIA-62BRL-CAD: when it should have been a const \*
05:08.46brlcadstarseeker: what's the equivalent of --disable-strict with cmake?
05:16.11*** join/#brlcad Stattrav (~Stattrav@122.167.214.98)
05:16.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:50.42CIA-62BRL-CAD: 03brlcad * r45253 10/brlcad/trunk/misc/brlcad.spec.in: still woefully incomplete, but this should at least make the spec file behave better for autotool builds
05:52.36brlcadkunigami1: you can load that .rt viewscript into mged, set the view center (I list it in the file itself), then query the view direction (see 'view' command)
05:54.26brlcadthe other piece of the puzzle is that the cornell.rt script sets up a 60 degree perspective view, not orthogonal rays -- if you remove the -p60 from the .rt file, you might have better luck getting a matching fivew
05:56.18brlcadkunigami1: http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-2011-06-24.png is looking pretty swank... nifty
06:00.54*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.0 is posted, 7.20.2 undering build release testing now (20110628)
06:02.07brlcadlouipc: thx for the reminder
06:02.10brlcadthough we're not topic-locked, you (or anyone) can update it as needed ..
06:10.00bhinesleybrlcad: -DBRLCAD-ENABLE_STRICT=OFF
06:16.07brlcadbhinesley: thx
08:33.56*** join/#brlcad merzo (~merzo@235-121-133-95.pool.ukrtel.net)
10:32.46*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:48.48*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:28.00*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
14:02.50*** join/#brlcad merzo (~merzo@157-86-133-95.pool.ukrtel.net)
14:21.49starseekerbrlcad: -DBRLCAD-ENABLE_STRICT=OFF
14:22.30starseekerbrlcad: did you have a chance to reproduce that distcheck failure?
14:28.29brlcadnot yet, but looking at it now
14:28.36brlcadstarseeker: can't find the pdf
14:48.33CIA-62BRL-CAD: 03brlcad * r45254 10/brlcad/trunk/bench/run.sh:
14:48.33CIA-62BRL-CAD: so comparing by -lt makes the timing comparison suck for normal iterations
14:48.33CIA-62BRL-CAD: because it causes the comparison to effectively be the floor() of the elapsed
14:48.33CIA-62BRL-CAD: time, which makes causes TIMEFRAME to get exceeded (e.g., elp=1.99 will iterate
14:48.33CIA-62BRL-CAD: again even if TIMEFRAME=1). revert back to less-than since what we really need
14:48.34CIA-62BRL-CAD: is a do-while loop. achieve the same by initializing our elapsed counters to
14:48.34CIA-62BRL-CAD: negative, so we still get sane behavior at TIMEFRAME=0.
14:52.22CIA-62BRL-CAD: 03brlcad * r45255 10/brlcad/trunk/bench/run.sh: allow the benchmark to accelerate by two orders of magnitude at a time if we're on crazy fast hardware. allows faster convergence with fewer iterations.
14:56.00*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
15:33.14CIA-62BRL-CAD: 03brlcad * r45256 10/brlcad/trunk/bench/Makefile.am: go ahead and add a distclean rule so proper cleaning is performed during distcheck
15:58.43CIA-62BRL-CAD: 03brlcad * r45257 10/brlcad/trunk/bench/run.sh:
15:58.43CIA-62BRL-CAD: change the name of our iteration log/pix files to be more consistent with the
15:58.43CIA-62BRL-CAD: benchmark.log files using -PID prior to the file extension. also be more
15:58.43CIA-62BRL-CAD: careful to only keep a backup once so that a given -PID test iteration backup
15:58.43CIA-62BRL-CAD: file should correspond to the previous *benchmark* run, not just the previous
15:58.44CIA-62BRL-CAD: *iteration*. refactor into function since we do the cleanup twice.
16:00.00CIA-62BRL-CAD: 03brlcad * r45258 10/brlcad/trunk/src/libged/translate.c: c++-style // comments are not allowed for portability
16:18.35CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2938 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ libpng conflict solved
16:50.45*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
17:56.38*** join/#brlcad Stattrav (~Stattrav@117.192.137.220)
17:56.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:47.00*** join/#brlcad Stattrav (~Stattrav@117.192.137.220)
18:47.00*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:11.37*** join/#brlcad Stattrav (~Stattrav@117.192.137.220)
19:11.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:27.26*** join/#brlcad Stattrav (~Stattrav@117.192.137.220)
19:27.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:34.05*** join/#brlcad Stattrav (~Stattrav@117.192.137.220)
19:34.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:42.48*** join/#brlcad Stattrav (~Stattrav@117.192.137.220)
19:42.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:36.53*** join/#brlcad Stattrav (~Stattrav@117.192.137.220)
20:36.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:43.01CIA-62BRL-CAD: 03bhinesley * r45259 10/brlcad/trunk/src/libged/translate.c:
20:43.01CIA-62BRL-CAD: Retrieves correct tree to be edited:
20:43.01CIA-62BRL-CAD: A)If path's CWD isn't '/', the object's parent is retrieved so that the object's entry can be modified.
20:43.01CIA-62BRL-CAD: B)If the path is '/', the object (combination) itself is returned so that all instances of object are changed, by modifying it's entire tree.
20:43.01CIA-62BRL-CAD: All existing logic relating to this was moved to translate().
20:46.07CIA-62BRL-CAD: 03bhinesley * r45260 10/brlcad/trunk/src/libged/translate.c: that's CWD/obj, not "object's parent", whatever that was supposed to mean
21:18.17CIA-62BRL-CAD: 03brlcad * r45261 10/brlcad/trunk/ (include/ged.h src/libged/ged.c): ged_drawable_close() is an implementation detail, probably doesn't need to be public API, so migrate functionality into ged_close() and remove it.
21:24.39CIA-62BRL-CAD: 03brlcad * r45262 10/brlcad/trunk/src/libged/ged.c: same thing with ged_drawable_init() .. remove it from public api, absorbed into ged_init()
21:25.25CIA-62BRL-CAD: 03kunigami * r45263 10/brlcad/trunk/src/liboptical/osl_rt.cpp: performing tests with refraction (glass shader). it is not working correclty. internal ray probably is not being delt right.
21:27.16*** part/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
21:49.11CIA-62BRL-CAD: 03brlcad * r45264 10/brlcad/trunk/src/mged/mged.c: remove calls to ged_drawable_close(). simplifies cleanup to just ged_close().
21:49.43CIA-62BRL-CAD: 03brlcad * r45265 10/brlcad/trunk/include/ged.h: qray stuff shouldn't be public api
21:51.18CIA-62BRL-CAD: 03brlcad * r45266 10/brlcad/trunk/src/libged/ (ged.c ged_private.h nirt.c qray.c qray.h): rename ged_qray_*() functions so they don't appear to be public api. prefix them with just qray_*() and declare the ones used elsewhere in the qray.h private header.
22:01.43CIA-62BRL-CAD: 03brlcad * r45267 10/brlcad/trunk/src/libged/ (10 files): ws indent style cleanup
22:08.07CIA-62BRL-CAD: 03brlcad * r45268 10/brlcad/trunk/src/libged/ (17 files): ws indent style cleanup
22:26.21CIA-62BRL-CAD: 03starseeker * r45269 10/brlcad/trunk/src/other/tktable/unix/: delete empty unix directory.
22:27.59CIA-62BRL-CAD: 03starseeker * r45270 10/brlcad/trunk/src/other/tktable.dist: update tk dist file
22:29.52CIA-62BRL-CAD: 03brlcad * r45271 10/brlcad/trunk/src/libged/ (20 files): ws indent style cleanup
22:32.42CIA-62BRL-CAD: 03bhinesley * r45272 10/brlcad/trunk/src/libged/translate.c: remove superfluous parentheses
22:43.28CIA-62BRL-CAD: 03bhinesley * r45273 10/brlcad/trunk/src/libged/translate.c: break/shorten comments past 70th column
22:46.55starseekerblinks - woah, all of a sudden we're getting ERROR: bad pointer 0x1dc43300: s/b rt_wdb(x5f576462), was Unknown_Magic(x3a24d53e48), file src/librt/wdb.c, line 419
22:47.39CIA-62BRL-CAD: 03brlcad * r45274 10/brlcad/trunk/src/libged/ (22 files): ws indent style cleanup
22:51.47brlcadstarseeker: with what?
22:52.58*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
22:53.13brlcadthere should be a stack report for that one too, should be obvious where it's coming from
22:53.45brlcadmaybe related to r45261 or r45264 or similar change
22:54.05brlcadin which case something just not being initialized or free'd correctly
22:57.39CIA-62BRL-CAD: 03brlcad * r45275 10/brlcad/trunk/src/libged/ (44 files): ws (mostly trailing ws elimination)
22:59.57starseekerbrlcad: make regress - wdb_close is getting bad magic
23:00.51starseekerwdb_close being called by ged_close
23:01.35brlcadk, that has to be related then -- I'll look into it
23:02.13brlcadmust be closing something that was never opened or previously closed but not set to NULL afterwards, or similar
23:10.12CIA-62BRL-CAD: 03brlcad * r45276 10/brlcad/trunk/src/libged/ (58 files): batch indent cleanup
23:22.48brlcadbhinesley: I trust you have read the sources to the other translate command? (otranslate.c)  just checking to make sure you're not spinning on actually implementing translate
23:25.36bhinesleyI've seen it, yes. I think I know what to do now.
23:25.52bhinesleyfor objects, should I just call ged_otranslate?
23:26.30bhinesleyI guess not, it doesn't do relative/absolute/keypoint positioning
23:26.52brlcadright, I'd go the other way around
23:27.10brlcadonce you get yours working, make ged_otranslate call your translate func
23:27.17bhinesleyalright
23:27.19brlcadptranslate is siilar
23:27.23brlcad*similar
23:27.27bhinesleywhat is "p"
23:28.55brlcado => object
23:28.57brlcadp => primitive
23:29.30brlcadin general, "object" (incorrectly and confusingly) refers to non-primitive combination objects
23:30.14bhinesleyok
23:30.34brlcadyou'll see a lot of places where there is a distinction (either at the command or API level) between combs and prims because of how they're implemented, but that's mostly places where librt needs refactoring
23:31.16bhinesleyI wanted to ask about flattening the trees: is it best to just build a recursive function or to flatten the tree? I wouldn't have even though about flattening if I hadn't seen db_flatten_tree.
23:31.39brlcaddepends what you're doing
23:32.22bhinesleyeither doing a translation on one node or all of them
23:32.51bhinesleyI just assumed that the step of flattening was a waste
23:33.09bhinesley(although that's what translate. is doing right now)
23:33.11bhinesley*.c
23:33.57brlcadin general yes
23:34.21brlcadyou shouldn't really (ever) need to flatten a tree unless it's for printing or ease of searching nodes
23:34.33brlcadpoor-mans serialization
23:36.25bhinesleyalright
23:36.56bhinesleyI saw db_flatten_tree being used in a couple places where it probably didn't need to be, then
IRC log for #brlcad on 20110629

IRC log for #brlcad on 20110629

00:09.47brlcadnot surprising
00:09.54CIA-62BRL-CAD: 03brlcad * r45277 10/brlcad/trunk/src/libged/ (100 files): remainder of ws indent consistency cleanup. reorder to eliminate some forward decls too.
00:11.05brlcadimproving code quality is always fair game
00:12.05brlcadwhether it's some bit of logic that could be cleaned up or a usage pattern that begs refactoring or outright crap code that needs to be taken out back and shot
00:14.13CIA-62BRL-CAD: 03brlcad * r45278 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am subtype.c): subtyping is something that should be defined within the objects themselves down in librt, not at this high level. no matter, the code is a ways off from compiling anyways, so removed from dist.
00:15.00*** join/#brlcad merzo (~merzo@157-86-133-95.pool.ukrtel.net)
00:15.41CIA-62BRL-CAD: 03brlcad * r45279 10/brlcad/trunk/src/libged/ (vdraw.c wdb_vdraw.c): vmath provides M_SQRT2
00:23.33CIA-62BRL-CAD: 03brlcad * r45280 10/brlcad/trunk/src/libged/adc.c: remove ged_ prefix on non-public functions, reorder to eliminate forward decls
00:30.31CIA-62BRL-CAD: 03brlcad * r45281 10/brlcad/trunk/src/libged/ged.c: don't blindly close the wdbp
00:38.49CIA-62BRL-CAD: 03brlcad * r45282 10/brlcad/trunk/src/libged/ged.c: initialize the other struct ged members during ged_init() so they can be properly memory-managed.
00:39.34CIA-62BRL-CAD: 03brlcad * r45283 10/brlcad/trunk/src/libged/ged.c: bah, fix typos
00:46.34*** join/#brlcad crazy_imp (~mj@a89-182-231-95.net-htp.de)
00:50.03bhinesleybrlcad: yeah, I should have taken a closer look at otranslate/ptranslate. That helps a lot.
01:14.24CIA-62BRL-CAD: 03bhinesley * r45284 10/brlcad/trunk/src/libged/ (path.c translate.c): ensure path is initialized and isn't / before trying to access it's directories
01:24.06CIA-62BRL-CAD: 03bhinesley * r45285 10/brlcad/trunk/src/libged/translate.c: translate.c accidentally included in last commit... inverse merge 45284
02:44.30CIA-62BRL-CAD: 03bhinesley * r45286 10/brlcad/trunk/src/librt/db_fullpath.c: it is already assumed that an empty string corresponds to '/', so handle a NULL string the same way (rather than bombing)
02:48.49CIA-62BRL-CAD: 03brlcad * r45287 10/brlcad/trunk/src/librt/wdb.c: if we're closing a wdbp, make sure all memory is released. set the magic to 0 for sanity too in case someone looks at that memory again later.
04:08.47*** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862)
04:24.56brlcadstarseeker: definitely related, though how to fix this correctly is going to be very tricky .. spagetti code intermingled on the tcl and c sides, both trying to manage that wdbp
04:53.01CIA-62BRL-CAD: 03bhinesley * r45288 10/brlcad/trunk/src/ (libged/translate.c tclscripts/archer/ArcherCore.tcl): tranlation of all objects in a single combination's tree is now working: 'translate -r 5 5 5 / obj1.c', or equivalently 'translate 5 5 5 obj1.c'
05:04.23*** join/#brlcad DarkCalf (DC@173.231.40.98)
05:21.14*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
05:45.00CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2939 10/wiki/User:Bhinesley: /* Log */ Friday, yesterday, today, plan for the week
05:54.12bhinesleybrlcad: I'm getting a segfault when I run 'make'. I see that you might still be working on it, so I'll just say that after an inverse merge of r45287 it goes away. http://pastebin.mozilla.org/1260422
06:20.30CIA-62BRL-CAD: 03brlcad * r45289 10/brlcad/trunk/src/librt/wdb.c: better wdb init. don't just set the magic, the forw/back list pointers need initializing. init both vls, not just one of them.
06:24.31CIA-62BRL-CAD: 03brlcad * r45290 10/brlcad/trunk/src/librt/wdb.c: set the magic properly useing BU_LIST_MAGIC_SET()
06:25.50CIA-62BRL-CAD: 03brlcad * r45291 10/brlcad/trunk/src/libged/wdb_obj.c: don't wdb_close does the dequeue and vls frees for us
06:26.56CIA-62BRL-CAD: 03brlcad * r45292 10/brlcad/trunk/src/libged/ged.c: be careful the gdp is not already allocated (should get set to null when deallocated)
06:35.24*** join/#brlcad Stattrav (~Stattrav@122.167.214.98)
06:35.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:42.27CIA-62BRL-CAD: 03brlcad * r45293 10/brlcad/trunk/src/mged/setup.c: protect this file from auto-formatting by making the expansion of ',' into a compile-time error. the 35,25 and 45,45 commands along with the mged_display tcl variable relies on there being no spaces around the comma.
06:48.05CIA-62BRL-CAD: 03brlcad * r45294 10/brlcad/trunk/src/mged/mged.c: (log message trimmed)
06:48.05CIA-62BRL-CAD: the wdb tcl objects and ged structures both assume they get to own the wdbp they
06:48.05CIA-62BRL-CAD: were passed. can't just remove the wdb_close() from wdb_deleteProc() as there
06:48.05CIA-62BRL-CAD: doesn't seem to be any place in mged where the .inmem wdb is actually recorded
06:48.05CIA-62BRL-CAD: (it's stored inside a tcl callback). so let the tcl objects do their thing, but
06:48.05CIA-62BRL-CAD: then that means the ged needs to acquire a full-fledged copy of the wdb and gets
06:48.06CIA-62BRL-CAD: treated as another dbi observer. this requires more extensive testing for
06:49.26brlcadstarseeker: that should fix it, but it definitely needs more testing (particularly memory testing) ... the open/close code is a royal mess, so it really warrants a valgrinding
06:59.22CIA-62BRL-CAD: 03brlcad * r45295 10/brlcad/trunk/src/libged/analyze.c: reorder in order to eliminate forward references and disambiguate private functions from public API by not using ged_ prefix.
07:06.50CIA-62BRL-CAD: 03brlcad * r45296 10/brlcad/trunk/src/libged/ (dg_obj.c vdraw.c wdb_vdraw.c): reorder and rename in order to remove the ged_ prefix on non-API functions. disambiguate with the tcl-based vdraw_cmd(), renaming to vdraw_cmd_tcl().
07:21.13*** join/#brlcad merzo (~merzo@193.254.217.44)
10:52.19*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:32.53starseekerbrlcad: so should we hold off on the release for now?
11:33.08*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
11:36.10*** join/#brlcad piksi (piksi@pi-xi.net)
12:08.53*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:28.10*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
13:02.30*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:28.35kunigami<PROTECTED>
13:30.31kunigamiI've been reading refract.c but
13:31.04kunigamiI couldn't notice any difference, except that it changes the hit callback.
13:34.50kunigamiIn osl_rt, first I detect the ray is a refraction one (which occurs when the next ray to be shot and the normal vector -- which I assume is pointing outwards -- have dot product less than zero). After shooting this new ray, I invert the normal given by the application.
13:35.55brlcadstarseeker: I wouldn't think so, if we pass all release testing -- just have to make sure everything really works with actual hands-on modeling
13:37.06brlcadkunigami: if you're inside an object, you won't get a hit until you encounter another object exterior
13:37.19brlcadi believe you'll want to back the ray out of anything that you're in
13:37.55brlcadat least for onehit
13:38.19starseeker/src/libged/draw.c
13:38.20starseeker{standard input}:13976:non-relocatable subtraction expression, "_dgo_open_tcl" minus "L00000000002$pb"
13:39.38brlcadunclean build?  that was just a function that was renamed from dgo_open to dgo_open_tcl
13:40.28brlcadnot used in draw.c, so a lil mystery there
13:41.41kunigamibrlcad: I'm not sure if I understand what you said. When a ray hits a glass object, I need to shoot a refraction ray. This ray will hit this same glass object from inside. I think I need to pass this "internal" ray to OSL system.
13:42.12starseekerah, OK
13:42.19starseekermutters under his breath about autotools...
13:44.21CIA-62BRL-CAD: 03brlcad * r45297 10/brlcad/trunk/src/libged/draw.c: remove the dgo references in here since this file no longer has anything to do with the dgo interface.
13:45.59brlcadkunigami: so in that case, your incoming ray hits glass, you determine that you need to refract, so you don't need to "rehit" that glass surface (so you don't need to back the ray out) -- you just fire from the interior
13:46.23brlcadyou may need to move the ray forward just an epsilon so that it doesn't accidentically rehit the surface due to floating point fuzz
13:49.33CIA-62BRL-CAD: 03brlcad * r45298 10/brlcad/trunk/src/libged/bev.c: replace the ged_ prefix on non-public API
13:52.35kunigamibrlcad: I didn't considered that! Let me try moving the starting point a little bit in the ray direction.
13:53.35CIA-62BRL-CAD: 03starseeker * r45299 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: This symlink probably shouldn't be pointing to the build directory - point it to the final installed location and see if that works...
13:53.53CIA-62BRL-CAD: 03brlcad * r45300 10/brlcad/trunk/src/libged/bot_dump.c: more ged_ prefix removal on non-public API
14:08.59*** join/#brlcad _psilva (~silvap@static-96-255-52-7.washdc.fios.verizon.net)
14:09.10_psilvamornin
14:09.13brlcadhowdy
14:09.33_psilvai'll try svn tonight
14:11.28CIA-62BRL-CAD: 03starseeker * r45301 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Spoke too soon - might be a problem with how BRL-CAD is setting CMAKE_LIBRARY_OUTPUT_DIRECTORY
14:12.20CIA-62BRL-CAD: 03starseeker * r45302 10/brlcad/trunk/CMakeLists.txt: See whether we actually needed to specify the BRLCAD_BINARY_DIR - if we don't, this may avoid libpng's problem.
14:20.00CIA-62BRL-CAD: 03starseeker * r45303 10/brlcad/trunk/CMakeLists.txt: Ah, that's right - that's what gives us the ability to duplicate the installed layout. Will need to do something else with libpng.
14:25.45starseekerdg_obj.c:339: warning: implicit declaration on vdraw_cmd_t
14:29.12_psilvai found g_var still in the distro
14:29.22_psilvadoubt it's used by anyone
14:35.33CIA-62BRL-CAD: 03brlcad * r45304 10/brlcad/trunk/src/libged/ (clip.c color.c ged_private.h): more ged_ (and _ged_) prefix removal. great example where reordering eliminates the need for forward decls and the unnecessary inclusion of the color funcs in ged_private (implying internal reuse API).
14:36.04starseekerbrlcad:  are you able to get a build of BRL-CAD right now?  I can't even in non-strict mode...
14:36.18starseekersrc/libged/vdraw.c:740: error: conflicting types for ‘vdraw_cmd’
14:36.30starseekerinclude/dg.h:264: error: previous declaration of ‘vdraw_cmd’ was here
14:39.38CIA-62BRL-CAD: 03brlcad * r45305 10/brlcad/trunk/src/libged/comb_std.c: ged_/GED_ prefix removal on non-public API
14:40.07brlcadstarseeker: I do get a clean build, lemme see if I have uncommitted files
14:41.24CIA-62BRL-CAD: 03brlcad * r45306 10/brlcad/trunk/include/dg.h: sure enough, uncommitted file. vdraw_cmd() was renamed to vdraw_cmd_tcl().
14:42.24brlcad_psilva: it's not been a maintenance burden, so it's been left alone
14:43.02brlcaddead code tends to get left alone unless/until it incurs a maintenance cost
14:44.16starseekerbrlcad: ah, phew - thanks
14:44.26starseeker(kinda makes release testing harder :-P)
14:45.29_psilvajust saying practically it really has no use
14:45.40_psilvai suppose maybe as a reference for another convertor
14:45.44_psilvait has some value
15:21.19brlcad_psilva: you have the ability to make it useful ;)
15:25.40_psilvaheh, just saying
16:48.59*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
17:25.48CIA-62BRL-CAD: 03kunigami * r45307 10/brlcad/trunk/src/liboptical/osl_rt.cpp: osl-rt can read number of samples from input
17:52.03CIA-62BRL-CAD: 03starseeker * r45308 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Try an alternative approach to the symlink issue.
17:55.31brlcad_psilva: just saying you're going to do it?
17:58.41brlcadactually, I recall looking at that converter a few months back and decided to keep it around because it might be useful as a plugin to our geometry conversion library
17:58.41CIA-62BRL-CAD: 03starseeker * r45309 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Fix up indenting.
18:21.20CIA-62BRL-CAD: 03starseeker * r45310 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Need to use the location property for the active configuration. Probably other places in BRL-CAD where I need to make this change.
18:35.33CIA-62BRL-CAD: 03starseeker * r45311 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Make sure we flush any old symlinks when re-running cmake.
18:36.50CIA-62BRL-CAD: 03bhinesley * r45312 10/brlcad/trunk/src/libged/ptranslate.c: after pointer arithmetic, argv[0] doesn't point to command name
18:48.27CIA-62BRL-CAD: 03starseeker * r45313 10/brlcad/trunk/src/other/libpng/CMakeLists.txt:
18:48.27CIA-62BRL-CAD: Since Windows doesn't symlink, we need to do something else. Rather than run
18:48.28CIA-62BRL-CAD: code on installation, just add a target to do the copy that depends on the
18:48.28CIA-62BRL-CAD: library target. Can do this for the symlink if need but, but so far it doesn't
18:48.28CIA-62BRL-CAD: look like we need to. Untested on Windows.
18:52.07*** join/#brlcad merzo (~merzo@226-207-132-95.pool.ukrtel.net)
18:55.26CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2940 10/wiki/User:Bhinesley: /* Log */ real oed command requires a keypoint
19:00.50CIA-62BRL-CAD: 03starseeker * r45314 10/brlcad/trunk/CMakeLists.txt: LOCATION -> LOCATION_
19:15.05CIA-62BRL-CAD: 03starseeker * r45315 10/brlcad/trunk/CMakeLists.txt:
19:15.05CIA-62BRL-CAD: Most of the time if you're compiling you want Debug build, and when you don't
19:15.05CIA-62BRL-CAD: want that you're specifying Release build - it's extremely rare to really WANT
19:15.05CIA-62BRL-CAD: to not have the build type set. Make the default behavior the common case.
19:27.47``Erikhttp://www.youtube.com/watch?v=X9eriClHWLw  adam savage singing "I will survive" as gollum
19:34.58CIA-62BRL-CAD: 03bhinesley * r45316 10/brlcad/trunk/src/libged/translate.c: Enable support for translating all instances of a primitive. Negative coordinates no longer mistaken for arguments.
19:45.22starseekerbites back cuss words - CMake has it's own notion of permissions, independent of umask
20:44.15*** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net)
20:48.32starseekerbhinesley: I'm seeing the following:
20:48.34starseeker../../../src/libged/translate.c: In function 'ged_translate':
20:48.34starseeker../../../src/libged/translate.c:237: error: expected ')' before 'restrict'
20:48.49bhinesleyhuh, ok
20:50.45*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
20:53.38CIA-62BRL-CAD: 03bhinesley * r45317 10/brlcad/trunk/src/libged/translate.c: restrict qualifier causing build errors
20:54.06bhinesleyI'm rebuilding from scratch right now, so I haven't tested that, but it should get you by (possibly with a warning)
21:18.57CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2941 10/wiki/ESA_Summer_of_Code_in_Space: initial description of SOCIS announcing intent to apply
21:22.26CIA-62BRL-CAD: 03kunigami * r45318 10/brlcad/trunk/src/liboptical/ (7 files): changed osl-renderer to liboslrend
21:30.15kunigamiI can't get refraction to work. In the following render, the tall box is from glass : http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-2011-06-29.png
21:40.09CIA-62BRL-CAD: 03r_weiss * r45319 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c:
21:40.09CIA-62BRL-CAD: Improved function 'nmg_bool' within file 'nmg_bool.c'. These changes will, under
21:40.09CIA-62BRL-CAD: certain conditions, increase the speed in which boolean operations are performed
21:40.09CIA-62BRL-CAD: on nmg structures. This will increase the speed of operations such as when using
21:40.09CIA-62BRL-CAD: the mged 'facetize' or 'ev' command.
21:49.56brlcadkunigami1: would be a good question to pose to the mailing list, maybe see if Rossberg has some suggestions
21:50.36brlcadyou're definitely getting some interesting effects, but reflectivity is clearly dominant
22:13.16CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2942 10/wiki/ESA_Summer_of_Code_in_Space: simplify
22:18.00CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2943 10/wiki/ESA_Summer_of_Code_in_Space: link proj ideas, needs customization to socis
22:19.24CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/Checklist]] moved to [[Summer of Code/Checklist]]: want to reuse the checklist since ESA is running their own SoC
22:24.26CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2946 10/wiki/Summer_of_Code/Checklist: generalize and specify
22:25.37CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/Application Guidelines]] moved to [[Summer of Code/Application Guidelines]]: Now supports two SoC programs
22:26.30CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2949 10/wiki/Summer_of_Code/Application_Guidelines: socify
22:27.01CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2950 10/wiki/Summer_of_Code/Checklist: simplify category
22:27.46CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/Acceptance]] moved to [[Summer of Code/Acceptance]]: now supporting two soc programs
22:32.05CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2953 10/wiki/Summer_of_Code/Acceptance: generalize
22:32.56CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/Expectations]] moved to [[Summer of Code/Expectations]]: now supporting two SoC programs
22:37.12CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2956 10/wiki/Summer_of_Code/Expectations: generalize
22:37.51CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2957 10/wiki/Summer_of_Code/Checklist: be abnoxious
22:38.53CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2958 10/wiki/Summer_of_Code/Checklist: or not
22:40.26CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2959 10/wiki/Google_Summer_of_Code:
22:41.38CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2960 10/wiki/Google_Summer_of_Code/2011:
22:59.55CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2961 10/wiki/ESA_Summer_of_Code_in_Space: generalize
23:01.59CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Category:Google Summer of Code]]": content was: '[[category:Projects]]' (and the only contributor was '[[Special:Contributions/Ssd|Ssd]]')
23:02.53CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2962 10/wiki/Google_Summer_of_Code/2008:
23:03.26CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/move: [[Google Summer of Code/Proposal Evaluation]] moved to [[Summer of Code/Proposal Evaluation]]: generalize
23:05.04CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2965 10/wiki/Summer_of_Code/Proposal_Evaluation: generalify
23:05.50CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2966 10/wiki/User:EBautu: cat
23:06.33CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2967 10/wiki/More_Changelog: cat
23:07.00CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2968 10/wiki/Google_Summer_of_Code/Flyers:
23:07.27CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2969 10/wiki/Google_Summer_of_Code/2009/Project_Ideas: cat
23:07.50CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2970 10/wiki/Google_Summer_of_Code/2008/Project_Ideas: cat
23:08.01CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2971 10/wiki/Google_Summer_of_Code/2009: cat
23:08.27CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2972 10/wiki/Google_Summer_of_Code/2009/Project_Ideas: stray .
23:11.08CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2973 10/wiki/Google_Summer_of_Code/Project_Ideas: generalize
23:14.19CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2974 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: initial stab at ideas for SOCIS, starting with the GSoC list
23:59.32``Erik*grouse* I might have to play a game with highlighters and a trip to someone with a free tube tester O.o
IRC log for #brlcad on 20110630

IRC log for #brlcad on 20110630

00:47.07*** join/#brlcad crazy_imp (~mj@a89-182-123-98.net-htp.de)
01:26.50*** part/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
04:15.18CIA-62BRL-CAD: 03brlcad * r45320 10/brlcad/trunk/src/libged/concat.c: reorder to remove forward decls, remove misleading ged_ prefix from static functions
04:27.16CIA-62BRL-CAD: 03brlcad * r45321 10/brlcad/trunk/src/libged/draw.c: reorder to remove forward decls, remove misleading ged_ prefix from static functions
04:38.02CIA-62BRL-CAD: 03brlcad * r45322 10/brlcad/trunk/src/libged/ (9 files): even more reordering to remove forward decls, remove misleading ged_ prefix from static functions
05:02.36CIA-62BRL-CAD: 03bhinesley * r45323 10/brlcad/trunk/src/libged/translate.c: added support for translating 'only a particular instance' of an object (like 'oed obj1.c obj2.c/kp.s')
05:05.37bhinesleyreally feeling like I understand what needs to happen now. The rest should be muuuch faster :)
05:06.10bhinesleytook every neuron in my central nervous system to figure it out, though
05:08.19bhinesleyyawns
05:24.32CIA-62BRL-CAD: 03bhinesley * r45324 10/brlcad/trunk/src/libged/translate.c: Enable support for 'instance only' and 'all instances' translation of primitives. The main things left to do, are: enabling support for absolute/keypoint positioning and accepting multiple object arguments.
05:28.38CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2975 10/wiki/User:Bhinesley: /* Log */ today
05:29.54CIA-62BRL-CAD: 03brlcad * r45325 10/brlcad/trunk/src/libged/ (20 files): remainder of reordering to remove forward decls and removal of misleading ged_ prefix from static non-public api functions
05:31.17brlcadbhinesley: haha, outstanding :)
05:33.17brlcadyou got/get how the current way oed behaves is to use the natural (aka arbitrary coded keypoint) coordinate system origin of a specified primitive as the origin to use for a keypoint?
05:34.49bhinesleyI get what you're saying
05:37.03bhinesleyshould the 'new' way allow the user to specify any coordinate as well as any object's origin?
05:37.28brlcadideally, yeah
05:37.46bhinesleyanything else?
05:40.57brlcadthree use cases that come to mind are an arbitrary xyz, a 'natural' origin keypoint akin to what oed does now, and a 'default' origin on an object's minimum bounding box center
05:41.51brlcadthere isn't presently a routine to get the third one at the moment, but that's probably the ideal default
05:42.28brlcadfor now it can just be the AABB center or stubbed into the command-line api but unimplemented
05:43.00bhinesleyok
05:43.01brlcadneed some syntax to differentiate an object name refering to the natural vs centered keybpoint
05:43.56bhinesleycould just use different switches (-n -c)
05:44.06brlcadsure
06:44.04*** join/#brlcad Stattrav (~Stattrav@122.178.252.52)
06:44.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:28.21*** join/#brlcad Stattrav (~Stattrav@122.178.211.204)
07:28.21*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:46.23*** join/#brlcad merzo (~merzo@193.254.217.44)
10:54.45*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
11:09.01CIA-62BRL-CAD: 03brlcad * r45326 10/brlcad/trunk/src/libged/ged.c: yet another tweak that 'should be safe' but might not be. release the ged_gdp that we allocated during init. assume that init isn't being called on something already initialized too.
11:52.08*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:24.23CIA-62BRL-CAD: 03brlcad * r45327 10/brlcad/trunk/ (259 files in 7 dirs):
12:24.23CIA-62BRL-CAD: change ged_log an ged_result_str from being directly embedded bu_vls structs to
12:24.23CIA-62BRL-CAD: being pointers. this makes the struct smaller but more importantly lets us
12:24.23CIA-62BRL-CAD: manage memory and initialization more easily. sure, the pointer might now be
12:24.23CIA-62BRL-CAD: null, but that'll be wrapped soon anyways (and can be validated). happens to
12:24.24CIA-62BRL-CAD: save a lot of '&' typing too. ;)
12:32.44brlcadstarseeker: do you happen to have a set of already-rendered nifty NURBS images handy?
12:33.12brlcadideally showcasing relatively simple objects that would be rather complicated to implement as CSG
12:33.47brlcadI know there's the phone images, any others?
12:35.40brlcadideally something that doesn't require release approval, looking to publish an overview of step on the wiki and mailing list really soon
12:36.27CIA-62BRL-CAD: 03brlcad * r45328 10/brlcad/trunk/src/bwish/ (cadAppInit.c main.c): not calling ged_init()
12:37.07*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:38.47CIA-62BRL-CAD: 03brlcad * r45329 10/brlcad/trunk/src/libged/ged.c: have to bu_free() the gedp itself now since ged_free() releases the internal memory (so it can still release memory for ged structs on the stack)
12:58.29CIA-62BRL-CAD: 03brlcad * r45330 10/brlcad/trunk/src/libged/ged.c:
12:58.29CIA-62BRL-CAD: fix compile, missed commit. don't free the gedp itself during ged_free() so we
12:58.29CIA-62BRL-CAD: can still pass static struct ged entities and have their memory allocations
12:58.29CIA-62BRL-CAD: released. this matches with other bu structs and their respective free
12:58.29CIA-62BRL-CAD: functions (e.g. bu_vls_free()).
13:00.24epilegI'm using -DBRLCAD_INSTALL_DATA_DIR= and -DDDATA_DIR= to set share folder, but without success. How can I properly set it?
13:00.49CIA-62BRL-CAD: 03brlcad * r45331 10/brlcad/trunk/src/shapes/ (human.c tire.c): we can now call ged_free() so we're not leaking memory (albeit during exit)
13:08.49brlcadis DDDATA_DIR a typo?
13:09.42CIA-62BRL-CAD: 03brlcad * r45332 10/brlcad/trunk/src/ (libged/wdb_obj.c mged/mged.c mged/setup.c): plug various ged memory leakages. if we fail, reset back to null.
13:10.21epilegbrlcad: is as starseeker typed
13:11.06brlcadlooks like one too many D's to me
13:11.52epilegok, i'll try removing a D
13:15.53brlcadstarseeker: cmake --help-variable-list and all the other various --help-* commands seem to be somewhat useless ... can all the various BRL-CAD vars get added to a BRLCAD module?
13:17.03brlcadepileg: I do see that CMAKE_INSTALL_PREFIX is the equivalent of ./configure --prefix=
13:18.05epilegyes, i know. what 's  BRLCAD_PREFIX?
13:19.00brlcadpresumably the same thing, where do you see that?
13:19.58epilegI' see it with "cmake-gui"
13:20.05brlcadstarseeker: also, INSTALL.cmake looks like it's incomplete?  still has all the configure options, no itemized cmake build options
13:21.52brlcadepileg: ah, yeah -- the CMakeLists file says it's also the install prefix, an advanced option of some sort
13:22.26brlcadit's set to CMAKE_INSTALL_PREFIX, so perhaps just an internal variable
13:23.15epilegbrlcad: ok, thanks. removing a D for share folder properly worked!
13:24.00brlcadform is -D VAR=VAL
13:24.13brlcadso it was suspicious that there'd be a DDATA_DIR var
13:24.20epilegaha
13:25.21brlcadfrom my reading of the usage, the space is even optional so it'd probably be more clear to put the space in our docs
13:25.25``ErikBRLCAD_PREFIX is something starseeker added to prevent using old installed BRL-CAD libs to link during build, should be marked as advanced
13:26.06``ErikCMAKE_INSTALL_PREFIX is the one you want to use
13:27.28epilegThanks brlcad ``Erik
13:27.30CIA-62BRL-CAD: 03starseeker * r45333 10/brlcad/trunk/CMakeLists.txt: Readibility improvement.
13:27.46epilegnow I only need text to properly rendering. Is there a way to do that in cmake?
13:30.56kunigamiI made a scene consisting of a sphere with center (0,0,0) and radius 1 and shot a ray from (-10, 0, 0) with direction (1, 0, 0)
13:31.51kunigamiwhen I call the first rt_shootray it returns (-1, 0, 0) as the hit point (OK). OSL code returns the direction (1, 0, 0) (OK)
13:32.45kunigamithen I forward the hit point a little bit to (-0.9999, 0, 0) and shoot a new ray from there with direction (1, 0, 0). rt_shootray returns (-0.9999, 0, 0) as the hit point
13:34.01kunigamiI'll send this information to the mail list as suggested. I'm probably not setting something right before calling rt_shootray the second time
13:56.45d_rossbergkunigami: (-0.9999, 0, 0) is OK but you are probable interested in the pt_outhit
14:35.38starseekerbrlcad:  seeing a crash: http://pastebin.mozilla.org/1261320
14:35.55starseekerbrlcad: urm.  NURBS images... probably just the phone image handy
14:36.30starseekerhttp://bzflag.bz/~starseeker/phone_large.png
14:40.59starseekerlet me see if I can get an openbook image rendered
14:44.49starseekerhttp://bzflag.bz/~starseeker/openbook_d2.png
14:53.45starseekerbrlcad: um... the cmake help commands are help for cmake developers, not about a particular project
14:55.16starseekerINSTALL.cmake was/is a work in progress.  I haven't pushed to finish it up yet
14:55.58starseekerI didn't figure we would be pushing the CMake build as primary until after this release, so I wasn't worried about it yet.
14:59.40*** join/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
15:00.44*** part/#brlcad Ralith_ (~ralith@S010600221561996a.vc.shawcable.net)
15:05.07brlcadkunigami: ah, probably because you're inside an object, so it's instantly a hit.  since you know you're a refraction ray, you may want to set onehit to false and skip the first partition
15:05.47brlcadotherwise, you have no idea how far forward you'll need to nudge forward to get past that object
15:06.21brlcadah, or what d_rossberg said :)
15:07.02kunigami:) I'm implementing that. For a render with few samples it seems to have worked. Checking with more samples now
15:07.41brlcadstarseeker: yeah, looking for something better than those
15:07.57brlcadphone_large is interesting, but isn't "nurbs-compelling"
15:08.14brlcadopenbook_d2 is "nurbs-compelling", but just not very interesting
15:08.49starseekerbrlcad: yeah, then I don't have anything handy
15:09.17brlcadevan a simple closed surface deformed to all hell wibbly wobbly would probably work, but a real object would be better
15:09.19starseekersorry :-/
15:10.03starseekerare you seeing that bomb issue with ged_init?
15:10.28brlcadlooking at that now
15:10.46brlcadeveryone should see it given that report
15:11.04brlcaddidn't you read it? :)
15:11.28starseekerI did - but figured you'd probably tested the recent commits, so I thought perhaps there was another uncommitted file or some such
15:13.06brlcadtested, but apparently not code that exercised ged_init()
15:13.52CIA-62BRL-CAD: 03brlcad * r45334 10/brlcad/trunk/src/libged/ged.c: have to allocate memory now before init can occur since they're just pointers
15:19.22starseekeryep, that's got it - thanks
15:33.03*** join/#brlcad Stattrav (~Stattrav@117.192.146.37)
15:33.03*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:15.46starseekerkunigami: might want to update the Makefile.am in liboptical
16:16.01kunigamiouch, I always forget
16:17.23starseekerbrlcad: I doubt it's "nurbsy" enough, but here's a rendering of the bugbase model:  http://bzflag.bz/~starseeker/bugbase.png
16:19.42CIA-62BRL-CAD: 03kunigami * r45335 10/brlcad/trunk/src/liboptical/Makefile.am: changed osl-renderer to liboslrend in Makefile.am
16:20.20brlcadbetter, but similarly kind of bland
16:21.01starseekerkunigami: thanks
16:30.07kunigamihttp://dl.dropbox.com/u/1399996/GSoC/OSL_RT-2011-06-30.png
16:30.31kunigamiThe light is a bit too strong, but I think the glass is being rendered right now.
16:32.23starseekerkunigami: nice!
16:50.14*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
16:52.21starseekerbrlcad: hmm - still getting complaints about leftover files from distcheck in the bench directory:  http://pastebin.mozilla.org/1261343
16:53.40brlcadkunigami: awesome .. curious interaction on the ground but not yet clear whether it's "right" or not
16:53.44brlcaddefinitely better though
16:54.49brlcadone thing I remembered to ask you about... are you running through rt or is this through that osl front-end tracer set up to shoot librt rays?
16:55.42brlcadreason I ask, the image looks flipped
16:56.06kunigamiI'm running from the second one. My next step is to port is to rt so that I can try to integrate with BRL-CAD shaders
17:01.38CIA-62BRL-CAD: 03brlcad * r45336 10/brlcad/trunk/bench/Makefile.am: try making these 'local' overrides since something is apparently stopping regular generated files from getting cleaned up during distcheck.
17:01.40brlcadyeah, getting that same output, even without any other brl-cad shaders, via rt would be good
17:02.41brlcadand gets closer towards answering those outstanding questions I had regarding how secondary rays are going to play with arbirary osl shaders
17:06.13CIA-62BRL-CAD: 03brlcad * r45337 10/brlcad/trunk/TODO: mater command bustage??
17:28.11CIA-62BRL-CAD: 03kunigami * r45338 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt Makefile.am osl_rt.cpp): added suport for refraction to osl_rt. Also added it no Makefile.am
17:28.24kunigami*to
17:36.00CIA-62BRL-CAD: 03brlcad * r45339 10/brlcad/trunk/include/bu.h: add some assertions and protections to the bu_list insertion/dequeue macros. make them not dereference null or at least assert gracefully so we don't crash.
17:39.10CIA-62BRL-CAD: 03brlcad * r45340 10/brlcad/trunk/ (NEWS src/liboptical/sh_light.c):
17:39.10CIA-62BRL-CAD: encountered a crash during raytrace rendering a scene that had just one light
17:39.10CIA-62BRL-CAD: with an invalid parameter specification. structparse failed causing
17:39.10CIA-62BRL-CAD: light_free() to be called, which crashed on the light list (that had none added
17:39.10CIA-62BRL-CAD: yet). fixed the bug on both ends, making the list dequeue safe and initializing
17:39.11CIA-62BRL-CAD: the list properly.
17:46.06*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
18:14.52*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:47.49CIA-62BRL-CAD: 03kunigami * r45341 10/brlcad/trunk/src/liboptical/ (osl_rt.cpp sh_osl.cpp): rt now correctly renders reflection
18:48.41kunigamiFor refraction, I'll probably have to create a new callback in the fashion of rr_render
19:04.06*** join/#brlcad Stattrav (~Stattrav@117.192.146.37)
19:04.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:41.19CIA-62BRL-CAD: 03starseeker * r45342 10/brlcad/trunk/ (NEWS TODO src/libged/mater.c):
19:41.19CIA-62BRL-CAD: Fix a bug in the mater command - wasn't respecting the attribute syncing needed
19:41.19CIA-62BRL-CAD: for the new system. Ultimately this should be rewritten to just act on
19:41.19CIA-62BRL-CAD: attributes and not the comb structure, but that's a bit more extensive.
19:44.32CIA-62BRL-CAD: 03starseeker * r45343 10/brlcad/trunk/ (NEWS TODO): Bob fixed a number of issues with rtwizard by porting it to use the new ArcherCore framework (handling unknown units, freezing on some .g files.)
19:45.41starseeker``Erik: I'm assuming that osX link line TODO is the one for CMake?
19:47.44CIA-62BRL-CAD: 03starseeker * r45344 10/brlcad/trunk/TODO: Move a few tasks that aren't going to be handled this go-around.
19:49.51starseekerbrlcad: um.  is "revolve typein" the MGED command line input for our revolve primitive?
19:51.29starseekerfires off distcheck again
19:56.21brlcadstarseeker: i'm not sure the mater color problem was occuring before 7.20.0, only noticed it afterwards
19:56.53brlcadand yes, "in rev revolve ..."
19:57.12brlcadthat avs code seems incredibly complicated for what it's doing
19:59.34kunigamihttp://dl.dropbox.com/u/1399996/GSoC/OSL_RT-Refraction-Corrected-2011-06-30.png
20:00.43kunigamiI was using a wrong index of refraction inside BRL-CAD, so it could be calculating hitting points wrongly
20:33.58starseekerwoot - distcheck passed on linux
20:37.36CIA-62BRL-CAD: 03starseeker * r45345 10/brlcad/trunk/misc/Makefile.am: Need the Doxygen.in file in extradist
20:58.11CIA-62BRL-CAD: 03bhinesley * r45346 10/brlcad/trunk/src/libged/translate.c: Clean up some logic, clarify comments
21:05.11starseeker``Erik: With the inclusion of Doxygen.in, I think the CMake build is now functioning from the autotools tarball
21:12.03brlcadkunigami: yeah, *that* is looking much better :)
21:12.20brlcaddid you make the light bigger?
21:13.28kunigamiyup :P but I did not the right way. Now when I render I get way more overlap messages (just scaled both the ceiling hole and the rectangle by hand)
21:15.54starseekerbrlcad: in rev.s revolve 0 0 0 0 0 1 0 1 0 190 test_sketch works for me
21:16.14starseekerwas there something specific that was a concern?
21:17.39CIA-62BRL-CAD: 03brlcad * r45347 10/brlcad/trunk/src/libged/mater.c: improve handling of the color arguments by properly trimming whitespace before making comparisons or parsing values.
21:18.24CIA-62BRL-CAD: 03kunigami * r45348 10/brlcad/trunk/src/liboptical/sh_osl.cpp: added a callback to be called whenever a refraction ray is shoot. I'm getting some runtime errors like mis-aligned struct hit pointer.
21:20.13CIA-62BRL-CAD: 03brlcad * r45349 10/brlcad/trunk/src/libged/mater.c: free the right vls
21:21.40kunigamiCurrent render by rt for a mirror shader (tall box): http://dl.dropbox.com/u/1399996/GSoC/OSL_Shader_Mirror_Test_2011-06-30.png
21:22.08kunigami... and for glass shader (tall box): http://dl.dropbox.com/u/1399996/GSoC/OSL_Shader_Glass_Test_2011-06-30.png
21:22.50kunigamiwrong, by the way
21:22.51brlcadkunigami: avoid forward decls unless you have a cyclic loop
21:23.11kunigamibrlcad: ok! I'll fix that
21:25.47CIA-62BRL-CAD: 03starseeker * r45350 10/brlcad/trunk/TODO: revolve in seems to function.
21:25.50CIA-62BRL-CAD: 03kunigami * r45351 10/brlcad/trunk/src/liboptical/sh_osl.cpp: avoiding forward decls
21:26.39starseekerbrlcad: I'm guessing that mater bug probably does appear in 7.20.0 - it's almost certainly a consequence of the attribute/red work
21:27.08brlcadstarseeker: nope, just a quick sanity check since the typein interface for it was changed -- maybe try that same in command interactively if it wasn't so it builds up the args
21:27.28starseekerbrlcad: that's how I generated that command - interactively :-P
21:27.33starseekerdidn't know the parameters
21:27.38brlcadk, cool
21:27.45brlcadgood enough!
21:28.23starseekerI think that OSX thing is the CMake logic not sorting out multiple X11 installs on a Mac - probably don't need to swat that right now, that'll involve some fairly heavy duty mucking with FindX11.cmake
21:34.46CIA-62BRL-CAD: 03starseeker * r45352 10/brlcad/trunk/TODO: Move the OSX X11 search issue, add some more notes about what will need to be done.
21:37.50CIA-62BRL-CAD: 03brlcad * r45353 10/brlcad/trunk/src/libged/mater.c: remove the debug avs printing
21:39.29brlcaddoes the build automatically look in the ports dir or did the user specify an additional dyld_library_path?
21:39.40brlcadit shouldn't be looking in the ports dir automatically in the first place
21:39.57brlcadunless someone points there with flags
21:41.15brlcadif it's a user setting, then we can try to detect that and/or tell people to unset their paths
21:41.48starseekerdunno - have to look at FindX11 and what the find paths are by default on OSX
21:43.50starseekerit can probably be handled cleanly, but I don't have time to tackle it for this release
21:44.06brlcadI don't see /opt in the list (except a stray include dir)
21:44.20starseekerwould want to include ``Erik in that discussion, since he spotted the issue first
21:44.33brlcadalso don't see the default mac install location either, though
21:44.54starseekernods - that's why I want to check ``Erik's setup in more detail
21:49.50CIA-62BRL-CAD: 03brlcad * r45354 10/brlcad/trunk/misc/CMake/FindX11.cmake: look in /usr/X11/lib followed by the older convention, X11 subdirs in the system lib.
21:56.24CIA-62BRL-CAD: 03brlcad * r45355 10/brlcad/trunk/src/libged/mater.c: if the avs isn't initialized before it's needed, then we don't need to free it on all the error conditions. also emphasizes the curious double-standardize... intentional?
21:56.25CIA-62BRL-CAD: 03starseeker * r45356 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Tweak the png linking mechanism a bit - test this on a few more platforms.
21:57.29starseekerbrlcad: urm.  IIRC, I think I standardized on import to make sure any changes to the color attribute would override any pre-existing color attributes...
21:58.33starseekernot sure if both are still needed
21:58.58starseekerthat whole thing needs to be rewritten - it shouldn't be acting on the comb structure directly at all, except for the avs
21:59.21starseekeri gotta run, bbl
22:13.45brlcadnods
22:14.53brlcadcurious that the old way has stopped working through -- that's not bidirectional, I'd expect the write of a db_comb_internal to sync comb to attr, then attr to comb, then write out
22:16.10brlcadsince the comb fields are "fixed" and have flags when fields are invalid, they can be used to detect deletions and such that you don't get otherwise
22:23.46CIA-62BRL-CAD: 0376.252.190.26 07http://brlcad.org * r2976 10/wiki/STEP: update/reword scl, esa/nasa sections
22:35.46CIA-62BRL-CAD: 0383.85.24.171 07http://brlcad.org * r2977 10/wiki/ESA_Summer_of_Code_in_Space:
22:38.04bhinesleyis there a standard character we should use for commands skipping coordinate arguments?
22:38.05bhinesleyEx: translate - - 5 sph.s  ;# move sph.s up z-axis 5 units
22:39.39bhinesleyIn that case, zero would work, but there are cases zero would not suffice
22:40.28bhinesleyEx: translate -c - - 5 sph.s ;# move center of sph.s 5 units up z-axis
22:41.07bhinesleyer to z=5, rather
23:42.22CIA-62BRL-CAD: 03r_weiss * r45357 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c:
23:42.22CIA-62BRL-CAD: Updated functions 'nmg_two_face_fuse' and 'nmg_model_face_fuse' within file
23:42.22CIA-62BRL-CAD: 'nmg_fuse.c'. These changes improve the fusing of coplanar faces during boolean
23:42.22CIA-62BRL-CAD: operations of nmg objects. The changes can be seen on curved objects such as
23:42.22CIA-62BRL-CAD: spheres which are not distorted due to improper face fusing. The changes effect
23:42.23CIA-62BRL-CAD: functions such the mged 'facetize' and 'ev' commands.
IRC log for #brlcad on 20110701

IRC log for #brlcad on 20110701

00:17.15CIA-62BRL-CAD: 03r_weiss * r45358 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c:
00:17.15CIA-62BRL-CAD: Updated function 'nmg_shell_coplanar_face_merge' within file 'nmg_mod.c'. This
00:17.15CIA-62BRL-CAD: update improves the success of boolean operations on nmg objects which contain
00:17.15CIA-62BRL-CAD: coplanar faces. This change effects functions such as the mged 'facetize' and
00:17.15CIA-62BRL-CAD: 'ev' commands.
00:27.57*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
00:46.26*** join/#brlcad crazy_imp (~mj@a89-182-114-102.net-htp.de)
01:01.59*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
01:57.08*** join/#brlcad _psilva1 (~Adium@pool-74-96-114-18.washdc.fios.verizon.net)
01:57.30_psilva1eh
01:59.47_psilva1test
01:59.52*** part/#brlcad _psilva1 (~Adium@pool-74-96-114-18.washdc.fios.verizon.net)
02:00.06*** join/#brlcad _psilva1 (~Adium@pool-74-96-114-18.washdc.fios.verizon.net)
02:00.17_psilva1test 2
02:01.42_psilva1anyone compile pkg-config lately?
02:03.11*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
02:49.54``Erikwe were doing a hard push on a release until someone did a metric fuckton of libged commits.. with any luck, we'll finish the release cycle this week with a build that is auto*, cmake and pkg friendly :/
02:55.00``Erikstarseeker: you have access to the box that's causing issue, I'd not qualify it as a show stopper for the release, just a "needs to be looked into soon" issue
03:31.31brlcadbhinesley: probably opt for your previous suggestion, making different options -c # # # == -x # -y # -z #
03:32.21bhinesleyalright
03:33.08bhinesleyI have an idea to make the oed-ish commands more versatile
03:33.25bhinesleyI'll show you later
03:33.40brlcadxyz or ijk
03:33.41brlcadok
03:34.18brlcadcould use xyz for points and ijk for angles or somesuch
03:34.42brlcador gang them together, just a lil messier to validate
03:36.20bhinesleyhmm so you don't like "translate 5 # 7 object2.c"?
03:36.49bhinesleyI'm not quite following
04:08.57brlcadnot particularly
04:09.13brlcadthat would be introducing a new 'convention' of sorts
04:09.28brlcadand not one particularly obvious
04:09.36bhinesleyyeah, I was hoping there was one
04:15.10bhinesleywhat about using the -x -y -z's as placeholders: "translate -k -x -y 5 -x -y 6 obj.c" would move obj.c from 5 to 6 on the z-axis
04:16.11bhinesleywell not exactly... it would be equivalent to 'translate -x -y 1 obj.c'
04:16.30brlcadthat doesn't make a whole lot of immediate sense to me either
04:17.16bhinesleythe trouble with the way you mentioned, is that you can't tell the difference between a -x for a keypoint and a -x for a delta
04:17.59bhinesleythere's something similar to this in AutoCAD called point filters... extremely useful and underused
04:19.09brlcadoh but there is, missing opts
04:20.28brlcadtranslate -a -c 1 2 3 foo ; translate -r -x 2 -y 1 foo ; foo is at 3 3 3
04:20.45brlcadabsolute and relative options
04:21.46brlcador one could be the default so you only need the option to specify the other
04:22.01brlcade.g., relative as default, then -a for absolute
04:24.34brlcadsince all three commands need to work together and writing argv/argc parsing sucks, write out the synopsis first
04:24.42brlcadfor tra, sca, rot
04:25.10bhinesleyI did for my idea... I should show you now.
04:25.28brlcadso we don't end up with -c coordinate, -p point, -k keypoint, all meaning the same thing
04:26.08bhinesleyAlright, keep in mind that I was thinking that using a placeholder like '-' would be okay when I wrote this: http://pastebin.mozilla.org/1261895
04:27.21bhinesleyformatting got a little screwed up
04:29.50brlcadhalfway through
04:30.05brlcadthat's actually looking pretty good
04:31.50brlcadstill think the - is a bit screwy -- we do have a convention of using '.' with another command so that'd be the only relevant convention, but I think that explicit axis opts would provide more clarity and the '.'s would just be a shorthand for experts
04:33.15bhinesleythat sounds good; there's one case that it may be problematic to use the -x/-y/-z with: 'translate -k -x 1 -y 2 -z 3 object' is ambiguous... but it may not be a valid command anyways
04:33.28brlcadanother convention used is a field separator, e.g., "5/2/3" or "3,1,3" .. where you allow empty fields "/2/3" and ",,3"
04:36.21brlcadnot a huge fan, though
04:36.44bhinesleyI think the -x/-y/-z and '.' thing works
04:36.50bhinesleyany ideas for alternatives to the  '-' arguments for the -c/-o options?
04:42.59bhinesleyI suppose I could allow use of '.' intended for experts as with -x/-y/-z, and everyone else just types out the path/obj again
04:46.02bhinesleyor sets it to a TCL variable
04:49.23epilegstarseeker: mged compiled with cmake has these more dependencies http://paste.debian.net/121565/ than the mged compiled with autotools
04:50.27brlcadbhinesley: avoid any interaction with tcl on the libged side of things
04:50.38bhinesleyI meant that the user could
04:50.46brlcadk
04:50.57brlcadthe goal is to make the core libs completely devoid of tcl, long term project
04:51.16brlcadbasically undoing integration from the past 15 years :)
04:51.23bhinesleyhehe
04:53.34brlcadbhinesley: I like the write up
04:53.42brlcadclearly put a good bit of thought into this
04:53.51bhinesleycool, thanks
04:54.46bhinesley...thanks for taking it seriously
04:54.58bhinesleywould have been easy to say "meh. do it my way."
04:55.35brlcadmeh, it's not that bad ;)
04:55.43bhinesleyhehe
04:55.57brlcadI think -x/-y/-z and '.' will help be more consistent
04:56.55brlcadexcept in this context... 0.0 vs 0. vs .0 vs .  are all pretty similar :)
04:58.26brlcadsomething about this is bothersome:  translate -k -23 4 17 9 2 1 bowl.c
04:58.50brlcadI think it's the slew of labeled and unlabeled numbers
05:00.01bhinesleycould make a -d (delta) switch, that is optional/only required when -k is used
05:00.25bhinesley"translate -k -23 4 17 -d 9 2 1 bowl.c"
05:00.49bhinesleyhonestly, that is nothing more than a relative translation that does some math for you
05:03.41brlcadnods
05:03.46brlcadit's more important for rotate
05:04.46brlcadI think it gets back to an optional [-a|-r] for the TO
05:05.12brlcadtranslate -k -23 3 17 -r 9 2 1 bowl.c
05:05.26brlcadwhich is same as translate -k -23 4 17 9 2 1 bowl.c
05:05.33bhinesleygood idea
05:05.34brlcadi.e., -r is optional and default
05:05.42brlcadbut makes documenting instructions more clear
05:06.17brlcadand in that context -k with -a would be pointless since -a wins, but no harm to specify it
05:07.35bhinesleyshouldn't it be "translate -k -23 3 17 -a 9 2 1 bowl.c" though, since the 9,2,1 are absolute coordinates
05:07.57bhinesleyand then "translate -r 5 5 5 obj" == "translate 5 5 5 obj"
05:09.05bhinesleyn/m I read your last sentence
05:09.33*** join/#brlcad _psilvah (~prasad@pool-74-96-114-18.washdc.fios.verizon.net)
05:09.39_psilvahbrlcad: w00t! :D
05:10.06brlcadheh
05:10.08_psilvahfinally progress
05:10.25_psilvahthanks btw
05:12.39brlcadhey, it's for a good cause if it gets you back into useful coding ;)
05:12.54_psilvah3
05:13.24_psilvahbench is next
05:13.39_psilvahtho i need to brush up on svn commands
05:13.55_psilvahnow how do i switch to window 3..
05:13.58_psilvah:(
05:14.12brlcadbhinesley: my understanding is => translate -k 10 10 10 -a -10 0 10 bowl.c => -10,0,10   and...
05:15.16brlcadtranslate -k 10 10 10 -r -10 0 10 bowl.c => translate -k 10 10 10 -10 0 10 bowl.c => translate -k 10 10 10 -10 . 10 bowl.c => 0,10,20
05:18.16bhinesleythat's the exact opposite of what I was thinking :)
05:18.39brlcadhah, outstanding then
05:19.46brlcadhow does a relative translate get you to absolute coordinates from a keypoint?
05:21.58brlcadwould be nice to combine the -c -o -k options, to simplify usage
05:22.08brlcad-k object makes perfect sense to me
05:23.41brlcadjust need to know which point in object
05:25.21bhinesleyI think I just misunderstood what you were saying... translate -k 10 10 10 -a -10 0 10 bowl.c would move you a relative -20,-10,0, right?
05:25.50bhinesleywhen I'm thinking of "-a", I'm thinking, these coordinates are absolute
05:26.25bhinesleymay be too tired to think straight
05:26.33brlcadyou didn't misunderstand, that's not what I wrote -- but that would make sense
05:26.41brlcadI was thinking -k was completely meaningless with -a
05:27.21brlcadwith the reasoning that if you translate to an absolute position (from ANY keypoint), you end up at that position
05:27.56bhinesleyI see
05:28.16brlcadI get your idea too, rather different
05:29.01brlcadand from a utilitarian perspective, yours probably makes more sense since mine is achieved by simply dropping the -k
05:30.21brlcadwhereas yours you can use to calculate
05:31.50brlcadbasically "a - k = point" giving -20,-10,0
05:31.59bhinesleyright
05:32.26brlcadand "k + r = point" for relative
05:33.35brlcad?
05:33.39bhinesleynot exactly
05:34.10bhinesleyr does movements relative to the current position
05:34.21bhinesleyso a -r from any keypoint is the same
05:37.24brlcadif bowl.c is at 100,100,100, then I believe you're saying "translate -k 10 10 10 -a -10 0 10 bowl.c" puts it at 80,90,100  (calculated a -20,-10,0 vector)
05:38.23bhinesleycorrect
05:38.34brlcadif bowl.c is at 100,100,100, then "translate -k 10 10 10 -r -10 0 10 bowl.c" puts it at ...
05:39.21bhinesley-k is ignored; it's the same as "translate -r 10 0 10 bowl.c", so bowl.c is at 110,100,110
05:40.36brlcadpresuming you meant 90,100,110 ;)
05:40.47bhinesleyyes
05:40.56bhinesleyI have these fonts really small
05:41.09bhinesleymissed the '-'
05:41.20brlcadthat seems to defeat the meaning of a keypoint to me
05:42.03bhinesleyI agree, that was just my understanding
05:42.10bhinesleyI like what you said before
05:42.21bhinesleyit's just a bit hard to understand
05:42.44brlcadtranslate -k bowl.c -r -10 0 10 bowl.c == translate -r -10 0 10 bowl.c
05:42.54bhinesley-r moves us to an absolute point, which is a relative distance away from the keypoint
05:44.23brlcadfrom that approach: translate -k bowl.c == translate -k 100 100 100, so tranlsate -k 100 100 100 -r -10 0 10 bowl.c => 90,100,110 make perfect sense
05:44.48brlcadbut then it carries that translate -k 10 10 10 -r -10 0 10 bowl.c should not be the same
05:46.17brlcadk + r is consistent with both
05:46.55bhinesleyok
05:47.02bhinesleysounds good
05:47.02brlcadwith the understanding that k is implicitly the object's position unless overridden
05:48.22brlcadkeeps in line with your nice FROM TO setup
05:48.37brlcadthe TO is wrt the FROM, not the object
05:48.52brlcadunless FROM isn't specified, then it's implicitly the object
05:49.20brlcadlesse, does that still hold for absolute too...
05:49.21bhinesleynice
05:55.20brlcadyeah, a bit to wrap the head around at this hour
05:55.27brlcadnewpos = oldpos + rel = keypoint + rel .. pretty clear cut
05:55.31bhinesleyhaha, exactly
05:56.03brlcadmy original was  newpos = abs  .. which is simple, but not too useful
05:56.23brlcadyou made it derive a vector, to be applied to oldpos
05:58.34brlcadnewpos = abs - keypoint = abs - oldpos = -10,0,10 - 100,100,100 = -110,100,110 .. that doesn't seem right
05:59.47*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
05:59.47*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:59.49brlcadtranslate -a -10 0 10 bowl.c => -10,0,10  .. basically newpos = abs
06:02.24brlcadtranslate -k 10 10 10 -a -10 0 10 bowl.c => 100,100,100 + -20,-10,0 = 80,90,100
06:03.13bhinesleycorrect
06:03.50brlcadthe problem is consistency: translate -k 100 100 100 -a -10 0 10 bowl.c => ???
06:04.23brlcador maybe just not seeing the formulation correctly
06:05.01brlcadaha!
06:05.23brlcad100,100,100 + -110,-100,-90 = -10,0,10
06:06.34brlcadabs is not just "abs" .. it's abs' = abs - oldpos
06:07.04brlcadokay, cool .. that works
06:07.49brlcadthe only other detail in the synopsis is the whole -c -o hullabaloo
06:08.43bhinesleywell -o can go away, as you've shown
06:08.55bhinesley-k obj || -k -10 0 10
06:09.02brlcadnods
06:11.09brlcadactually it's -c that disappeared
06:11.38brlcador that could
06:11.51bhinesleythe center of a primitive is 0,0,0?
06:12.02brlcadat least for arbitrary non-primitive obj, their "V" position is their bounding box center
06:12.11bhinesleyoh.
06:12.12brlcadI wish
06:12.32brlcadeach primitive defines their own "natural" origin
06:12.44brlcadfor a box, it's one of the corners
06:12.56brlcadfor a cylinder, it's the center of the bottom disc
06:13.05brlcadfor a torus, it's the center
06:13.10brlcadetc
06:13.30brlcadit's undefined for combinations
06:13.41brlcadthat's why OED makes you specify a path/to/primitive
06:13.48bhinesleyright
06:14.52brlcadso we can define it to be the bb center for all combination objects
06:15.08brlcadthat makes -k obj work for any object
06:15.20brlcadit's just whether to use that same center even for primitives or whether to use their V
06:15.36brlcadas a default at least
06:15.45brlcadand then an option to specify the other
06:16.18brlcadmy inclination is default to center for everything
06:17.51brlcadtranslate [-n] [-k] [object | 3dpos] [-a | -r] 3dpos object(s)
06:18.50brlcadwhere 3dpos := [-x] {#|.} [-y] {#|.} [-z] {#|.}
06:18.56bhinesleyyeah, I'd say that defaulting to center is more useful
06:19.43brlcadmore precisely...
06:22.06brlcadtranslate [[-n] [-k {object | [-x] {#|.} [-y] {#|.} [-z] {#|.}}]] [-a|-r] [-x] {#|.} [-y] {#|.} [-z] {#|.} object(s)
06:22.09brlcad:)
06:22.39bhinesleydon't we need another object in there somewhere
06:23.14brlcadoh that's right, you allowed the TO to be objects as well
06:23.17brlcadthat's new to me ;)
06:23.42bhinesleyvery nice once you get the hang of it
06:24.18bhinesleysay you have 3 wheels on a vehicle; you can copy one in place, and easily move it into position
06:24.31bhinesleyignoring z-axis
06:24.41brlcadtranslate [-n] [[-k] [object|3dpos]] [[-a|-r] [object|3dpos]] object(s)
06:25.12bhinesleygreat, that actually works ok for parsing too
06:26.03bhinesleyI was worried about "translate -k obj -a obj2 obj3 obj4 obj5 at first
06:26.04brlcadprobably actually end up needing [-n|-c]
06:26.36bhinesleyhow so
06:26.36brlcadand allowing it independently on the TO and the FROM
06:26.49bhinesleyright
06:27.17bhinesleytranslate -c -k obj -n -a obj2 obj3 obj4 obj5
06:27.28brlcador at least need to respecify -n twice
06:27.40bhinesleyeven better
06:28.07brlcadso that it binds to the k|a|r options
06:30.20brlcadtranslate [[-n] [-k {object|3dpos}]] [[-n] -a|-r {object|3dpos}] object(s)
06:30.41brlcadnot exact or useful synopsis syntax in that form...
06:31.50brlcadeither way, really nice work there .. good brainstorming
06:32.19bhinesleythanks; it was a pleasure working with you
06:33.18bhinesleyI should probably ask you: is it alright if I focus on just this oed stuff for my second milestone?
06:33.30bhinesleyI have a feeling it will not all be done + another command
06:33.50brlcadabsolutely
06:33.58bhinesleyright on
06:34.13brlcadthe milestones are completely insignificant if progress like this is being made ;)
06:34.23bhinesleyexcellent
06:34.52bhinesleysorry it's taken me like 3 weeks to do anything significant with this. I ran out of talent.
06:35.10brlcadwas to be expected
06:35.25brlcadnot a simple problem or we would have done it already
06:37.07brlcadeasier to create yet another command that does some specific subset syntax and relies on a stupid oed selection state that is based around implementation detail keypoints insignificant to the modeler
06:37.31brlcadthat's why this consolidates about a dozen commands into just three
06:38.39brlcadif you can recharacterize your writeup (which should be committed, btw, even as you work on it) after our talking, I'd jump over to scale and rotate to make sure the same syntax structure will work for them and make sense
06:38.57brlcadwith angles and distances, rotate might be especially interesting
06:39.22brlcaddegrees, radians
06:39.30bhinesleynods
06:39.41bhinesleyI have it in translate.c right now, is that alright?
06:39.51brlcadoh sure, I missed it there
06:40.00bhinesleyno, not commited
06:40.10bhinesley(yet)
06:40.14brlcadah, okay
06:40.24brlcadwas gonna say, it's not in my copy :)
06:40.43bhinesleyhehe you need to do a 'svn up -r brandon's'
06:41.55brlcadif you get the urge to convert to actual docs, they live in doc/docbook/system/mann/en/
06:42.23brlcadtranslate.xml would get added for the manpage, docbook xml format, lots of examples to follow
06:42.48brlcadgoes walkabout
06:43.02bhinesleygreat, I was wondering how those were generated
06:52.31CIA-62BRL-CAD: 03bhinesley * r45359 10/brlcad/trunk/src/libged/translate.c: Laid out a brand spankin new syntax for translate. It is already obsolete, per irc conversation with Sean. Many ged_translate/translate things are broken, but I'm too tired to go on, so it's commented out for now.
07:15.43*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
07:15.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:00.54*** join/#brlcad merzo (~merzo@193.254.217.44)
08:25.20*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
08:25.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:34.49*** part/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br)
10:36.45*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
11:07.15CIA-62BRL-CAD: 03kunigami * r45360 10/brlcad/trunk/src/liboptical/ (liboslrend.h osl_rt.cpp): removing unused variables
11:21.32kunigamiMay I add an option to rt that reads the number of samples that will be made for each pixel?
11:22.23kunigamiIf yes, it's better to do it through rt script language, right?
11:26.14kunigamiIt would also be great if I could implement that kind of framebuffer that begins noisy and gains shape as more and more samples are done (but this would require to change the way rays are shot by rt)
11:44.06starseekerepileg: is that produced with the make package command?
11:44.32epilegyes, both
11:45.19epilegstarseeker: mmmm, do You mean the binary or the shared libs list?
11:50.58starseekerepileg: well, basically that list looks like it's from untarring one of the tarballs (binary) built by make package
11:51.23starseekerwhich would be really annoying - I thought I had all that path stuff straightened out
11:52.46epilegstarseeker: yes, htey are
11:53.08starseekerthere will be a few things present in a CMake build that aren't in an autotools build, since the CMake build has some new stuff
11:53.27starseekermore disturbing is the /home/jordi/svn/brlcad_7.20.1-0_amd64-2/usr/brlcad/bin path
11:54.15starseekerI'm trying a make package here
11:54.15epilegstarseeker: no no, forget this. I just created two deb packages and uncompress them
11:54.23starseekerOh!
11:54.37starseekerthe CMake package build for debs is completely untested
11:54.42epilegone with autotools and another with cmake
11:55.13starseekerwell, for one thing the CMake build turns on OpenGL by default, while the autotools still has it off by default
11:55.22epilegwell, I have  done the autotools deb packages script
11:55.25starseekerthat's probably where the libGLU is coming from
11:55.56epilegaha
11:56.08starseekerepileg: I need to look over the logic you've done for that and make sure the CMake build incorporates what is needed to reproduce it
11:56.22epilegok
11:56.27starseekerI can't test deb except on a virtual machine though, so I'm not set up for it yet
11:56.37epilegI'll give You exactly what I've done
11:57.02starseekerfor the tcl/tk stuff... at a glance it looks like the CMake build had enabled all local libs and the autotools build didn't
11:57.41starseekerlibpoints is just how CMake is building the MGED points logic, so that's not surprising
11:57.43epilegbut there are more libs in autotools packages than in cmake one
11:58.09starseekerwait - is the list I'm looking at autotools things that hte CMake build Doesn't have?
11:58.40epilegok
11:59.13epilegabout testing, don't worry, I've ready many virtual machines to test them
12:00.20starseekerbhinesley: getting this error:  src/libged/translate.c:49: error: ‘translate’ defined but not used
12:01.28starseekerno worries, but may want to #if it out in the repository until you progress to the point where it's used by something
12:02.00epilegstarseeker: in the autotools package, there are 747 elements, 69,9 MB, and in cmake package 671 elements, 46,3 MB
12:02.13starseekererm.
12:02.14epilegin lib folder
12:03.26epilegin came i used:
12:03.26epilegcmake -DBRLCAD-ENABLE_OPTIMIZED_BUILD=ON \
12:03.26epileg-DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON \
12:03.26epileg-DBRLCAD-ENABLE_STRICT=OFF \
12:03.26epileg-DCMAKE_BUILD_TYPE=Release \
12:03.27epileg-DCMAKE_INSTALL_PREFIX=/usr/brlcad \
12:03.27epileg-DDATA_DIR=share \
12:03.28epileg-DMAN_DIR=share/man
12:04.04epilegcmake*
12:05.15starseekerok
12:05.49starseekerepileg: for each of the two package directories (autotools and cmake) can you do the following?
12:06.12epilegand in autotools:
12:06.12epileg./configure --enable-optimized --enable-almost-everything --with-ogl --disable-debug -disable-strict -prefix=/usr/brlcad
12:06.25epilegyes, tell me
12:06.28starseekerfind . -type f |grep -v .svn|xargs stat --format='%n' > autotools.list
12:06.34starseekerfind . -type f |grep -v .svn|xargs stat --format='%n%s' > autotools_size.list
12:06.40starseekerand the same for cmake
12:06.46epilegok
12:06.59starseekerthose four files will provide a way to compare what is ending up in the two package dirs
12:07.11epilegin the root package folder, right?
12:07.15starseekeryes
12:07.21epilegjust a secont
12:11.21epilegstarseeker: some email to send or paste on a web page?
12:13.24starseekerhttp://paste.debian.net should work
12:13.29epilegok
12:14.24epileg...Length of code is not allowed to exceed 90kb...
12:14.30starseekerphooey
12:14.45starseekeri'll pm you an email addy
12:17.51*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:35.35epilegstarseeker: did You receive it?
12:37.44epilegstarseeker: just one thing. as You can see, at the end of cmake.list and cmake_size.list, there is ./autotools_size.list and ./autotools.list instead of the cmake... filenames
12:38.15epilegthis is because i've changed the filenames after run the command, sorry
12:52.51starseekerepileg: I'll check in a bit - dealing with multiple things at the moment
12:52.59starseeker(shredder broke, vacuum broke...)
12:53.05epilegok, no problem
12:53.31starseekernp - I can spot the autotools.list filesw
12:58.58CIA-62BRL-CAD: 03kunigami * r45361 10/brlcad/trunk/src/liboptical/ (osl_rt.cpp sh_osl.cpp): Still having problems rendering glass material. I've tried even calling OSL QueryColor directly (without mfuncs), but still no success
14:10.52brlcadkunigami: rt has a -H hypersample option already
14:41.09brlcadthat used in conjunction with -s oversizing then downsampling are a common best-practice for producing smoothly anti-aliased images
14:42.01brlcadon that same note, there is a -j jitter flag that will modify the starting ray hit point in various ways depending on the jitter value
15:05.39CIA-62BRL-CAD: 03starseeker * r45362 10/brlcad/trunk/doc/html/CMakeLists.txt: fix target directory for animmate
15:09.14CIA-62BRL-CAD: 03starseeker * r45363 10/brlcad/trunk/src/util/CMakeLists.txt: pc_test isn't supposed to be installed.
15:12.19starseekerepileg: the CMake zlib build isn't installing the private zlib headers, while the autotools build is - unless we need to install them, I'm inclined to go with the CMake behavior
15:13.14starseekerepileg: the CMake build won't have the .la files that the autotools build has - that's expected
15:13.41starseekersome differences with library naming for itcl/itk, looks like... that shouldn't matter
15:15.01epilegstarseeker: I'll be agree with any decision You take
15:15.27starseekertcl/tkConfig.sh scripts aren't there yet for the CMake build of Tcl/Tk
15:15.41starseekerepileg: do the packages generated actually work when installed?
15:15.55epilegyes
15:16.40epilegjust the rtwizard do not properly render, both cmake and autotools builds
15:17.29starseekerwhat's the issue with rtwizard?
15:17.50starseekerepileg: hmm, looks like I haven't gotten around to doing the man pages for iwidgets yet...
15:19.07epilegstarseeker: do You remember the difference between cmake and autotools about text rendering? it's still there
15:20.36epilegerror message from rtwizard
15:20.39epileghttp://paste.debian.net/121606/
15:22.06starseekeroh, I see - autotools build prefixed all of hte man pages before installing them
15:22.35starseekerepileg: is rt in your path?
15:23.03epilegnop
15:23.33epilegbut rt is not provided by brlcad?
15:26.31epilegsorry, something wrong in my system
15:32.33CIA-62BRL-CAD: 03starseeker * r45364 10/brlcad/trunk/src/other/iwidgets/ (CMakeLists.txt doc/CMakeLists.txt): Take care of iwidgets man pages.
15:33.02starseekerother major difference I see is CMake is installing Tcl/Tk man pages, where it looks like autotools isn't
15:33.15epilegaha
15:34.34starseekersomewhat surprisingly, autotools didn't build step-g?
15:43.41*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:44.21epilegstarseeker: so sorry, rtwizard properly works. It was a problem on my environment variables
15:45.13starseekernp
15:45.29starseekerjust glad it wasn't busted yet again :-P
15:46.06epileg:-)
16:42.38*** join/#brlcad Elrohir (~kvirc@pD95EDF28.dip.t-dialin.net)
17:00.40CIA-62BRL-CAD: 03bhinesley * r45365 10/brlcad/trunk/src/libged/translate.c: don't leave private translate function definition enabled if it's not used
17:00.42bhinesleystarseeker: hah, yeah, I was lying in bed last night thinking "really should have just commented out that whole private function"
17:17.28bhinesleyheh *laying
18:37.22brlcadprefixed the man pages?
18:38.53*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD has applied to participate in the ESA Summer of Code in Space!
18:42.36CIA-62BRL-CAD: 03brlcad * r45366 10/brlcad/trunk/bench/Makefile.am: try without defining DISTCLEANFILES
18:42.54brlcadI see why the distcheck was still failing, missed committing a file a few days ago
18:44.57CIA-62BRL-CAD: 03starseeker * r45367 10/brlcad/trunk/src/other/iwidgets/doc/Makefile.am: Add CMakeLists.txt file.
18:59.50CIA-62BRL-CAD: 03kunigami * r45368 10/brlcad/trunk/src/liboptical/sh_osl.cpp:
18:59.50CIA-62BRL-CAD: solved the glass shader. the problem was that the next application was set by
18:59.50CIA-62BRL-CAD: next.a_hit = prev.a_hit, but if prev.a_hit was the refraction callback,
18:59.50CIA-62BRL-CAD: next.a_hit would be also refraction. the expected behavior is to set mext.a_hit
18:59.50CIA-62BRL-CAD: as the first callback (the one that was used by the first ray
19:05.17CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2978 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 6 */ Reports updated
19:10.23CIA-62BRL-CAD: 03starseeker * r45369 10/brlcad/trunk/NEWS: Richard improved facetization by updating routines to merge coplanar faces.
19:11.58CIA-62BRL-CAD: 03starseeker * r45370 10/brlcad/trunk/include/conf/PATCH: Bump patch version number.
19:14.53CIA-62BRL-CAD: 03starseeker * r45371 10/brlcad/trunk/ChangeLog: Update ChangeLog
19:23.52*** join/#brlcad merzo (~merzo@94-20-133-95.pool.ukrtel.net)
19:34.06CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2979 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 6 */
19:49.53CIA-62BRL-CAD: 03kunigami * r45372 10/brlcad/trunk/src/liboptical/sh_osl.cpp: instead of calling OSLQueryColor directly (with the hardcoded name glass), call mf_render. this is better because the refracted ray may not be inside a shader named glass
19:52.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:04.12brlcadkunigami: so lets see it!
20:05.34brlcadaha, http://dl.dropbox.com/u/1399996/GSoC/OSL_RT-Refraction-Corrected-2011-06-30.png
20:06.34brlcadkunigami: what glass parameters are you using?  refraction index, specular and diffuse params, etc
20:06.55CIA-62BRL-CAD: 03starseeker * r45373 10/brlcad/branches/STABLE/ (2197 files in 194 dirs): Sync STABLE to trunk r45358
20:08.49starseekerwoot
20:10.57CIA-62BRL-CAD: 03starseeker * r45374 10/brlcad/branches/STABLE/ (17 files in 12 dirs): Sync STABLE to trunk r45373
20:11.28brlcadthinks you meant trunk TO stable
20:11.57brlcad:)
20:14.32starseekerer, yeah
20:14.44bhinesleyeither way is good ;-)
20:14.58starseekerprepares to tag... drumroll please...
20:15.34starseekerdouble checks the release numbers this time...
20:15.57brlcadand mged acutally runs along with archer :)
20:30.29starseekeryep, they run
20:30.40starseekerhere we go
20:31.18CIA-62BRL-CAD: 03starseeker * r45375 10/brlcad/tags/rel-7-20-2/: Tag release 7.20.2
20:37.08kunigamibrlcad: reading the osl glass shader, it seems that the index of refraction is 1.5
20:39.14kunigamiI don't know the specular and diffuse parameters. would have to take a look at implementation
20:40.08kunigamiThe shader description: http://pastebin.mozilla.org/1262389
20:43.54kunigamiScene with a BRLCAD shader (checkers) and a OSL shader (mirror). The way it is implemented, BRLCAD shaders will act as lights.
20:43.57kunigamihttp://dl.dropbox.com/u/1399996/GSoC/OSL-BRLCAD-Shader-Integration.png
20:52.04brlcadawesome starseeker
20:57.14starseekertarballs up
20:58.57CIA-62BRL-CAD: 03starseeker * r45376 10/brlcad/trunk/ (NEWS README include/conf/PATCH): Bump revision numbers.
21:14.46brlcadhm, rt inside mged is blocking
21:23.58brlcadhere's what that scene looks like with rt: http://tinypic.com/view.php?pic=9kufk1&s=7
21:24.31brlcadand as checker: http://tinypic.com/view.php?pic=i3hzjk&s=7
21:36.17CIA-62BRL-CAD: 03brlcad * r45377 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: gah, post-ta build failure! code is used unitialized. remove it...
21:51.15CIA-62BRL-CAD: 03brlcad * r45378 10/brlcad/branches/STABLE/src/librt/primitives/nmg/nmg_fuse.c: merge r45377 from trunk to stable
22:15.23CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2980 10/wiki/Main_Page: link to socis
22:33.35*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
22:57.43CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2981 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: eliminate some ideas only loosely relevant to space work
22:59.00CIA-62BRL-CAD: 03brlcad * r45379 10/brlcad/tags/rel-7-20-2/src/librt/primitives/nmg/nmg_fuse.c: source tarballs were posted but not announced, so merge r45377 from trunk to stable so we can regenerate them
23:18.26starseekerbrlcad: O.o Sorry - what happened?
23:20.23starseekerbites back cuss words - how in the *bleep* did I get all those successful builds and then have a build failure??
23:21.16starseekerthe tarballs came out of a tagged distcheck build
23:23.39starseekerdeletes source tarballs, regens
23:44.14CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2982 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas:
23:46.17CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2983 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: reorder
23:54.05brlcadstarseeker: did you compile optimized?
23:54.14brlcadoptimized often enables even more warnings
23:55.37brlcadthat's part of my compile script -- all+warn, all+opt+warn, all+32bit+warn, default+warn, default+opt+warn, .... etc etc :)
23:55.55starseekerhrm.  No, I think I used the line in HACKING
23:56.34brlcadyeah, you did it right .. just slipped through
23:57.11brlcadrelease binaries aren't supposed to be optimized anyways (so they can be debugged)
23:57.58brlcadand some platforms don't behave well with optimized, so several reasons why it isn't in HACKING
23:58.53brlcadlooks like my build script tests 13 build configurations testing make, make distcheck, and make test for all 13 ... :)
23:59.36CIA-62BRL-CAD: 03bhinesley * r45380 10/brlcad/trunk/ (6 files in 4 dirs):
23:59.36CIA-62BRL-CAD: Started rearranging things, to put translate/rotate/scale syntax handling in one
23:59.36CIA-62BRL-CAD: place. Re-wrote proposed 'translate' manual per conversation with Sean. There
23:59.36CIA-62BRL-CAD: were a couple more issues resolved and ideas added along the way. Next step is
23:59.36CIA-62BRL-CAD: to ensure that rotate/scale will work alright with the same syntax.
IRC log for #brlcad on 20110702

IRC log for #brlcad on 20110702

00:01.17brlcadthat's 39 compiles, 26 installs, and 26 tests
00:01.44starseekerHum.  Will have to tweak the CMake logic for release - I think I might be turning on optimized by default for a Release build
00:01.54brlcadi'm still amazed when the build fails on some 30-somethingth test .. happens rarely, but has happened a couple times
00:02.18starseekerDing! the new source tarballs are done
00:02.25brlcadoutstanding!
00:02.34starseekerone more time...
00:02.48brlcadi'll try to send out the release announcements this weekend
00:02.59bhinesleyhow do I rename a file? Doing 'svn mv 1 2' and then commiting is giving me an error
00:03.05brlcadwhat's the err?
00:03.28bhinesleyhttp://pastebin.mozilla.org/1262525
00:03.28brlcadand did you do more than that one command .. like mv it then edit it
00:04.08brlcadhm, that looks like some network hiccup
00:04.12bhinesleyI did that at first.. but I undid the move, commited the old file, and now I'm just trying to do the move
00:04.13brlcaddid you just try again?
00:04.28bhinesleyI've tried several times, not just this second though
00:05.21brlcadare you behind a proxy or something?
00:05.31bhinesleynope
00:05.34brlcadsounds like a protocol mismatch
00:06.01brlcadmaybe your isp put you behind a proxy without your knowledge
00:06.08starseekerhmm - internet too swamped locally
00:06.10bhinesley:-O
00:06.18bhinesleylets hope not
00:06.45brlcadis your checkout http or https?
00:07.23bhinesleyhttp, it appears
00:07.32brlcadgrep http .svn/entries
00:08.03bhinesleyhttp
00:08.22brlcadmm.. hm
00:08.57brlcadwell that's about all I got -- it's either something temporary that sf folks are working on and you'll just have to wait
00:09.03brlcador you can try switching to https
00:09.21bhinesleyalright
00:09.31brlcadfind . -name entries -exec perl -pi -e 's/http:/https:/g' {} \;
00:09.34brlcadshould do the trick
00:09.46bhinesleycould you move libged/translate.c to libged/alter.c for me... the build is broken as is
00:09.52brlcadsure
00:09.55bhinesleythx
00:10.01brlcadat least .. I'll try ;)
00:10.05bhinesleyhehe
00:11.43CIA-62BRL-CAD: 03brlcad * r45381 10/brlcad/trunk/src/libged/ (alter.c translate.c): move translate.c to alter.c in order to reflect a mild restructuring.
00:12.56brlcadI'm always on https, so still could have been some proxy badness on isp or sf.net end or just a fluke that's already fixed
00:15.37bhinesleyI seem to have connection problems with them from time to time
00:16.07bhinesleyrecently it's been alright... but sometimes I have to 'svn up' several times to get everything
00:17.07bhinesleyI ran the command you gave me, so hopefully that will help
00:36.53*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
00:46.49*** join/#brlcad crazy_imp (~mj@a89-182-108-165.net-htp.de)
02:05.37starseekerah, there we go
02:05.40starseekerscp to the rescue
04:38.01starseekerhah - http://code.google.com/p/re2
06:17.10*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
06:17.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:19.10*** join/#brlcad yiyus (~124271242@je.je.je)
06:53.55*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
06:53.58*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:04.47*** join/#brlcad merzo (~merzo@94-20-133-95.pool.ukrtel.net)
07:06.10*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
07:06.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:02.51*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
11:02.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:34.44*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
11:34.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:43.21*** join/#brlcad kunigami (~kunigami@201.53.206.27)
12:02.50*** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br)
12:11.46*** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br)
12:12.49kunigamiTesting
12:13.18kunigami_Cool :)
12:40.10*** join/#brlcad kunigami (~kunigami@201.53.206.27)
13:02.52*** join/#brlcad djjara (~djjara@22.Red-79-157-206.dynamicIP.rima-tde.net)
15:51.58brlcadkunigami: here's what that scene looks like with rt
15:52.08brlcadhttp://tinypic.com/view.php?pic=9kufk1&s=7
15:52.47brlcadso not too shabby on the glass :)
15:53.48brlcadyours looks like it's also giving a reflection on the back face of the tall box, which I'm not sure is right but I think I did see that in the osl shader code you posted
15:54.37kunigamiyeah, I had that impression too
15:55.00brlcadhere's another -- similar to your recent image: http://tinypic.com/view.php?pic=i3hzjk&s=7
15:55.42brlcadchecker by itself is not very interesting, you have to use the stack shader and combine checker with phong to get curvature
15:56.32kunigamiwhat do you mean by curvature?
15:56.40brlcadif you want to see that example, the db is at http://brlcad.org/tmp/cornell.g
15:58.16brlcadnotice how the checker box you rendered was "flat"?
15:58.48brlcadthis one: http://dl.dropbox.com/u/1399996/GSoC/OSL-BRLCAD-Shader-Integration.png
15:59.33brlcadno delineation between the top and the sides
16:00.15brlcadnow compare that to my render, still checker but now you can "see the box" -- that's the "stack" shader
16:00.16kunigamihmm, understood. perfect. I'll take a look at the example
16:00.52brlcadstacking together checker and phong (plastic)
18:36.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:17.22*** join/#brlcad Stattrav (~Stattrav@117.192.148.229)
19:17.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:37.36*** join/#brlcad Stattrav (~Stattrav@117.192.148.229)
19:37.36*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:00.54*** join/#brlcad Stattrav (~Stattrav@117.192.148.229)
20:00.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:06.43*** join/#brlcad genba (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net)
20:07.22*** join/#brlcad genba (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net)
20:07.54*** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net)
20:10.25*** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net)
20:15.34*** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net)
20:17.46*** join/#brlcad Stattrav (~Stattrav@117.192.148.229)
20:17.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:23.51*** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net)
20:29.38*** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net)
20:43.15*** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net)
20:49.42*** join/#brlcad genba_ (~genba@74.Red-81-37-61.dynamicIP.rima-tde.net)
20:50.34*** join/#brlcad Stattrav (~Stattrav@117.192.148.229)
20:50.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:00.39*** join/#brlcad Stattrav (~Stattrav@117.192.148.229)
21:00.39*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:10.02*** join/#brlcad Stattrav (~Stattrav@117.192.148.229)
21:10.02*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:32.10*** join/#brlcad Elrohir (~kvirc@p5B14BDA4.dip.t-dialin.net)
IRC log for #brlcad on 20110703

IRC log for #brlcad on 20110703

00:27.41*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
00:29.23kunigamihttp://dl.dropbox.com/u/1399996/GSoC/OSL-BRLCAD-Shader-Integration-2.png
00:30.06kunigamiTest with checker shader + phong (thanks to brlcad)
00:47.20*** join/#brlcad crazy_imp (~mj@a89-182-54-210.net-htp.de)
01:18.55*** join/#brlcad ododo (~ododo@mna75-7-82-230-225-108.fbx.proxad.net)
01:28.44*** part/#brlcad ododo (~ododo@mna75-7-82-230-225-108.fbx.proxad.net)
07:42.04*** join/#brlcad FredGan (~Adium@broadband-109-173-13-224.nationalcablenetworks.ru)
07:42.14*** part/#brlcad FredGan (~Adium@broadband-109-173-13-224.nationalcablenetworks.ru)
13:39.38*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:07.15*** join/#brlcad Stattrav (~Stattrav@117.192.136.92)
15:07.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
15:31.48*** join/#brlcad piksi (piksi@pi-xi.net)
19:55.13*** join/#brlcad Stattrav (~Stattrav@117.192.136.92)
19:55.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:46.18*** join/#brlcad Stattrav (~Stattrav@117.192.136.92)
20:46.18*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:54.34*** join/#brlcad Stattrav (~Stattrav@117.192.136.92)
20:54.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:03.46*** join/#brlcad Stattrav (~Stattrav@117.192.136.92)
21:03.47*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:46.46*** join/#brlcad Stattrav (~Stattrav@117.192.136.92)
21:46.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:02.12*** join/#brlcad Stattrav_ (~Stattrav@117.192.136.92)
IRC log for #brlcad on 20110704

IRC log for #brlcad on 20110704

01:23.06*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
04:08.33*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
05:43.12*** join/#brlcad Stattrav (~Stattrav@117.192.148.193)
05:43.12*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:09.16*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
07:09.16*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:26.04*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:23.02CIA-62BRL-CAD: 03d_rossberg * r45382 10/rt^3/tags/rel-7-20-2/: tag the C++ core interface with the corresponding BRL-CAD version (i.e. 7.20.2)
08:50.48*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
09:38.27*** join/#brlcad merzo (~merzo@86.57.159.195)
10:36.08*** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br)
11:22.27*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
11:33.31*** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br)
14:29.24*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:11.00*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:35.54*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
16:14.10CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2984 10/wiki/User:Kunigami/GSoc2011/Proposal: /* Timeline */ update timeline
16:14.51kunigami1Is there any other suggestion that you think I should give priority?
17:32.50*** join/#brlcad kunigami_ (~kunigami@loco-gw.ic.unicamp.br)
19:00.59*** join/#brlcad Stattrav (~Stattrav@117.192.138.173)
19:01.00*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:13.49*** join/#brlcad Stattrav_ (~Stattrav@117.192.128.214)
19:19.16*** join/#brlcad Stattrav (~Stattrav@117.192.130.127)
19:19.16*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:02.25*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
20:05.52*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
20:19.31kunigami_sorry for asking again, but I think I've lost the conversation log for some reason. may I add an option to rt to read how many samples it will use to render osl shaders?
22:13.35*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
22:26.36*** join/#brlcad _psilva (~silvap@static-96-255-52-7.washdc.fios.verizon.net)
22:34.43*** join/#brlcad kunigami (~kunigami@201.53.206.27)
23:11.59*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20110705

IRC log for #brlcad on 20110705

02:53.18*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
04:52.54*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
04:57.43*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
06:57.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:53.03*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
09:41.21*** join/#brlcad merzo (~merzo@86.57.159.195)
09:58.02*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
11:16.38*** join/#brlcad ibot (~ibot@rikers.org)
11:16.38*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD has applied to participate in the ESA Summer of Code in Space!
11:57.43*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:48.41*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:40.17*** join/#brlcad merzo (~merzo@86.57.159.195)
15:46.14*** join/#brlcad kunigami (~kunigami@201.53.206.27)
16:48.15*** join/#brlcad Stattrav (~Stattrav@117.202.24.255)
16:48.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:59.40*** join/#brlcad merzo (~merzo@86.57.159.195)
17:02.52*** join/#brlcad Stattrav_ (~Stattrav@117.202.19.69)
17:07.53*** join/#brlcad Stattrav (~Stattrav@117.192.147.232)
17:07.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:32.17*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
18:17.27*** join/#brlcad Stattrav (~Stattrav@117.192.133.102)
18:17.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:27.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:28.27CIA-62BRL-CAD: 03bhinesley * r45383 10/brlcad/trunk/src/tclscripts/mged/ (man.tcl openw.tcl): Make the paramater for mged's man command optional. Fix the menu item: don't try to open "Introduction". With the new ManBrowser, it is no longer recognized as a valid argument, but is instead loaded by default.
20:29.47bhinesleynot sure how I didn't catch that ^^
20:30.20bhinesleythe manual page browser works alright, but the menu item was broken
20:30.46bhinesleyshould there be a patch or anything for the release?
20:31.05bhinesleycommand line worked okay
20:38.09*** join/#brlcad Stattrav (~Stattrav@117.192.128.251)
20:38.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:00.31*** join/#brlcad Stattrav (~Stattrav@117.192.128.251)
21:00.31*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:10.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:23.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:29.36CIA-62BRL-CAD: 03bob1961 * r45384 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Fixed the "Affected Tree/List Nodes" behavior.
21:34.46brlcadkunigami: response to that from earlier...
21:34.46brlcadkunigami: rt has a -H hypersample option already
21:34.46brlcadthat used in conjunction with -s oversizing then downsampling are a common best-practice for producing smoothly anti-aliased images
21:34.49brlcadon that same note, there is a -j jitter flag that will modify the starting ray hit point in various ways depending on the jitter value
21:35.18kunigamigreat! thank you
21:35.30brlcadman rt  has more details
21:35.46brlcadbhinesley: releases are past history, so generally too late to make it there
21:36.48brlcadthe release announcement hadn't been posted yet so technically source tarballs could be reposed and the release retagged, but that's a lot of work (and starseeker's on vacation, so he won't do it) especially for a help menu option with a workaround
21:37.06brlcadjust leave it be, note the menu fix as a NEWS line
21:39.27brlcadkunigami: you may also be interested in -i incremental mode, akin to jpeg incremental mode
21:39.34bhinesleyalright
21:39.50brlcadas well as non-buffered output mode
21:48.31CIA-62BRL-CAD: 03bhinesley * r45385 10/brlcad/trunk/src/libged/alter.c: note fix of Manual page item in help menu
21:48.39bhinesleydang it
21:48.52*** join/#brlcad Stattrav (~Stattrav@117.192.128.251)
21:48.52*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:55.28CIA-62BRL-CAD: 03bhinesley * r45386 10/brlcad/trunk/src/libged/alter.c: reversing last commit (wrong file)
21:56.01CIA-62BRL-CAD: 03bhinesley * r45387 10/brlcad/trunk/NEWS: note fix of Manual page item in help menu
22:57.21*** join/#brlcad _psilva_ (~silvap@static-96-255-52-7.washdc.fios.verizon.net)
IRC log for #brlcad on 20110706

IRC log for #brlcad on 20110706

01:11.05CIA-62BRL-CAD: 03kunigami * r45388 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): added support to osl parameters through the sh_osl shader description. I had to implement another parser for the arguments and the syntax is poor. I'll ask in the devs lists for suggestions
01:16.36CIA-62BRL-CAD: 03kunigami * r45389 10/brlcad/trunk/src/other/osl/ (9 files in 2 dirs): added a directory with osl shaders
01:17.59CIA-62BRL-CAD: 03kunigami * r45390 10/brlcad/trunk/src/liboptical/liboslrend.cpp: removing unnecessary code from liboslrend
01:44.32CIA-62BRL-CAD: 03kunigami * r45391 10/brlcad/trunk/src/liboptical/sh_osl.cpp: removed hypersampling from pixels of osl shaders, since rt already has an option for this (I should RTFM)
03:49.07*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
04:20.09*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
05:04.33*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
08:20.00*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:05.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:52.10CIA-62BRL-CAD: 03bhinesley * r45392 10/brlcad/trunk/src/libged/alter.c:
09:52.11CIA-62BRL-CAD: Laid out a rough draft of rotate command Manual page. It's proving to be a bit
09:52.11CIA-62BRL-CAD: more complex, and require more options than translate; there are still several
09:52.11CIA-62BRL-CAD: issues/inconsistencies to work out. Added optional [OFFSET_POS] argument to
09:52.11CIA-62BRL-CAD: every object argument in both commands, in order to add flexibility. Removed '.'
09:52.11CIA-62BRL-CAD: options to ignore specific coordinates, as it would have conflicted with
09:52.12CIA-62BRL-CAD: [OFFSET_POS], and -x/-y/-z options are clearer anyways.
10:46.53*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:05.28*** join/#brlcad Stattrav_ (~Stattrav@117.192.146.209)
11:16.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:32.56*** join/#brlcad merzo (~merzo@86.57.159.195)
12:58.07*** join/#brlcad Stattrav_ (~Stattrav@117.202.16.93)
13:08.11*** join/#brlcad Stattrav (~Stattrav@117.192.129.75)
13:08.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:11.56CIA-62BRL-CAD: 03kunigami * r45393 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h osl_rt.cpp sh_osl.cpp):
13:11.56CIA-62BRL-CAD: Instead of keeping shadername as the identifier or the shader, I now use the
13:11.56CIA-62BRL-CAD: shaderstate which is the only thing required by OSLRender. This is better
13:11.56CIA-62BRL-CAD: because for shader groups (shaders networks), there is not necessarily a name
13:11.56CIA-62BRL-CAD: associated
13:30.35*** join/#brlcad kunigami2 (~kunigami@loco-gw.ic.unicamp.br)
14:35.55*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
14:38.02nsd_Quick question: Is BRL-CAD 7.20.2 a stable release...? It's available for download on sf.net, but it's not listed on the news page. Should I just stick with 7.18.4?
14:42.25``Erikit should be stable, it's just in the process of a formal release, so the news page, announce, freshmeat update, etc. haven't been finished yet
14:44.28nsd_Oh alrighty then, thanks
16:16.35*** join/#brlcad Stattrav (~Stattrav@117.192.148.124)
16:16.35*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:27.50*** join/#brlcad Stattrav_ (~Stattrav@117.192.156.87)
16:39.37*** join/#brlcad Stattrav (~Stattrav@117.192.133.57)
16:39.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:04.18*** join/#brlcad Stattrav (~Stattrav@117.192.133.57)
17:04.18*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:11.00*** join/#brlcad Stattrav_ (~Stattrav@117.192.131.36)
18:15.08*** part/#brlcad epileg (~epileg@unaffiliated/epileg)
19:46.49CIA-62BRL-CAD: 03bhinesley * r45394 10/brlcad/trunk/src/libged/alter.c: Resolved all issues that I could find with "rotate". Still lacking in examples.
20:30.59CIA-62BRL-CAD: 03erikgreenwald * r45395 10/brlcad/trunk/src/libgcv/bottess.c: switch to internal representation. implement some shtuff. add lots of checking.
21:33.49CIA-62BRL-CAD: 03bhinesley * r45396 10/brlcad/trunk/src/libged/alter.c: Added examples of using OFFSET_DIST and X_OBJ/Y_OBJ/Z_OBJ to translate manual. Made several corrections, including in SYNOPSIS for both translate/rotate
22:50.01*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
23:00.28CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2985 10/wiki/User:Bhinesley: /* Log */ Past week, today, plan
23:40.40CIA-62BRL-CAD: 03bhinesley * r45397 10/brlcad/trunk/src/libged/alter.c: several corrections, add more examples, add skeleton of scale manual page
IRC log for #brlcad on 20110707

IRC log for #brlcad on 20110707

01:31.54CIA-62BRL-CAD: 03kunigami * r45398 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): added support to setting Color parameters
01:53.03*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
02:37.02CIA-62BRL-CAD: 03kunigami * r45399 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): added suport to osl shaders network
05:53.05*** join/#brlcad kanzure (~kanzure@131.252.130.248)
06:36.31*** join/#brlcad merzo (~merzo@86.57.159.195)
06:55.19*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
06:55.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:23.50*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:29.49*** join/#brlcad merzo (~merzo@86.57.159.195)
12:19.02*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:30.15kunigamihttp://dl.dropbox.com/u/1399996/GSoC/RT_OSL_checker.png
12:31.51kunigamiI've implemented a checker shader for OSL. It can receive two other shaders as inputs for black color and white color. In the example there's a green shader and pink shader for input
13:22.24CIA-62BRL-CAD: 03indianlarry * r45400 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Fixed win32 and not cygwin side of CREATE_SYMLINK macro pointing to correct file location.
13:26.38CIA-62BRL-CAD: 03indianlarry * r45401 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Added dbl quotes around "files to copy" and destination "path name" to allow for names with spaces.
13:36.44``Eriknice, kunigami! what GI algo are you using, again?
13:38.10kunigamithis was run with rt using 500 hypersamples using OSL shaders. I *think* that OSL system implements path tracer
13:38.37``Erikcool, so rt -H500 -j3 ?
13:39.52kunigamihmm actually I didn't set jitter, so it probably is using the default -J1.  
13:40.03kunigamiis J3 different from J1 for static images?
13:40.10``Erikyes
13:40.39kunigamihmm, ok! let me see the result with -J3
13:40.46``Erikit's a bit flat, 1 changes the origin, 2 changes the direction, 3 does both
13:45.02``Erikhave any docs on how to run it with the osl stuff? I have some relatively heavy hw I can throw at it if you want
13:45.43``Erik(though I'd probably just use a 16 core xeon box :)
13:56.50kunigaminot yet :( is it better to move osl code to brlcad repository or should I just make the doc explaining how to setup osl and then link to brlcad?
14:04.26``Erikthe OSL stuff is basically a script to set up the osl pipeline? what's the license situation on it?
14:05.10``ErikI see some in src/other/osl/ , is that the same stuff?
14:18.27kunigamimy idea was to move osl source code to src/other/osl sometime. By now, I'm just putting there the osl shaders I've been developing
14:20.45d_rossberg``Erik: is rt_bot_ifree2() only temporarily in bottess.c or should this function be declared in raytrace.h for DLL-export?
14:23.19starseekerdid his best to answer the SCL email, but perhaps someone more plugged in this week should answer?
14:25.05starseekerkunigami: if you're referring to the osl library itself, I'd still say not to worry yet about including it in BRL-CAD - the full dependency chain (llvm, etc.) is nothing to sneeze at
14:26.40kunigamistarseeker: ok. I'll try to write a small tutorial so that one can build OSL himself and link it to BRL-CAD
14:30.36``Erikd_rossberg: probably temporary, let me check something really quick on my winderz box
14:30.56``Erik smacks starseeker around for being on the computer when he's supposed to be visiting family O.o
14:35.42CIA-62BRL-CAD: 03erikgreenwald * r45402 10/brlcad/trunk/src/libgcv/bottess.c: disable rt_bot_ifree2 on windows due to symbol export/import issues.
14:38.24``Erikd_rossberg: óssok, I get a full build on msvc2005/vista32 now
14:38.53``Eriks/óss//
14:46.36d_rossberg``Erik: works for me too (msvc2008/xp32) :)
14:58.20*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:31.46kunigamihttp://dl.dropbox.com/u/1399996/GSoC/RT_OSL_checker_glass.png
15:32.13kunigamiJust another example, using a mirror shader and a green shader to compose the checker shader
15:32.29kunigamiI'm still rendering with the option -J3
16:26.33CIA-62BRL-CAD: 03kunigami * r45403 10/brlcad/trunk/src/other/osl/shaders/ (checker.osl gen_color.osl): updated checker shader and added a generic diffuse color shader
17:01.47CIA-62BRL-CAD: 03erikgreenwald * r45404 10/brlcad/trunk/src/libgcv/bottess.c: add/rm face funcs. added some iterators. cleanup/checking.
17:30.52CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2986 10/wiki/User:Kunigami/GSoc2011/OSL_Tutorial: Small tutorial do get OSL working with BRL-CAD
17:31.41CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2987 10/wiki/User:Kunigami/GSoc2011/OSL_Tutorial: /* Compiling some shaders */
17:35.02CIA-62BRL-CAD: 03kunigami * r45405 10/brlcad/trunk/src/other/osl/shaders/ (blue.osl converter.osl red.osl): adding required shaders to run cornell-kunigami.g
17:37.25CIA-62BRL-CAD: 03kunigami * r45406 10/brlcad/trunk/db/cornell-kunigami.g: added the scene I've been using for tests
18:56.29CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2988 10/wiki/User:Kunigami: /* Links */ added link to osl tutorial
19:59.30CIA-62BRL-CAD: 03bhinesley * r45407 10/brlcad/trunk/src/libged/alter.c:
19:59.30CIA-62BRL-CAD: Added -d option to distinguish among the intepretations of ANGLE_TO as an
19:59.30CIA-62BRL-CAD: absolute position (-a), relative distance (-r), or relative degree or radian
19:59.30CIA-62BRL-CAD: offset from ANGLE_FROM (-d). Apparently this was only happening in my brain,
19:59.30CIA-62BRL-CAD: before.
20:53.12CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2989 10/wiki/User:Kunigami/GSoc2011/Proposal: /* Timeline */
20:59.03CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2990 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ week 7 reports
21:31.32CIA-62BRL-CAD: 03erikgreenwald * r45408 10/brlcad/trunk/src/libgcv/bottess.c: Add inverted flag to face foo. remove normal from face (superfluous, it's in the plane eq). Expand the bounding volume slightly for fp fuzz.
21:39.18CIA-62BRL-CAD: 03r_weiss * r45409 10/brlcad/trunk/src/libged/erase.c:
21:39.18CIA-62BRL-CAD: Fixed a bug in the mged 'rm' command. This command 'deletes all occurrences of
21:39.18CIA-62BRL-CAD: the listed members from the specified combination'. A segmentation fault would
21:39.18CIA-62BRL-CAD: occur when a region is displayed in 'mged' and the 'rm' command is used to
21:39.18CIA-62BRL-CAD: remove a member of the displayed region and the member occurs in the region more
21:39.19CIA-62BRL-CAD: than once. The changed function is 'ged_splitGDL' within the 'libged' library
21:39.20CIA-62BRL-CAD: within file 'erase.c'.
21:52.17CIA-62BRL-CAD: 03erikgreenwald * r45410 10/brlcad/trunk/src/libgcv/bottess.c: carry tolerance through. Start on the 2 face split.
21:55.30CIA-62BRL-CAD: 03bhinesley * r45411 10/brlcad/trunk/src/libged/alter.c:
21:55.30CIA-62BRL-CAD: The description of how the default ANGLE_FROM is calculated needed to be much
21:55.30CIA-62BRL-CAD: more precise. It defines the y-axis of the rotation. These defaults came
21:55.30CIA-62BRL-CAD: together really well (so it seems). I'll have to recheck the examples.
IRC log for #brlcad on 20110708

IRC log for #brlcad on 20110708

00:04.45*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
00:30.46*** join/#brlcad KimK (~Kim__@ip174-71-95-176.om.om.cox.net)
01:11.21CIA-62BRL-CAD: 03kunigami * r45412 10/brlcad/trunk/src/other/osl/shaders/cloud.osl: adding the cloud shader
01:11.46kunigamihttp://dl.dropbox.com/u/1399996/GSoC/RT_OSL_cloud.png  sample image
01:55.34CIA-62BRL-CAD: 03bhinesley * r45413 10/brlcad/trunk/src/libged/alter.c:
01:55.34CIA-62BRL-CAD: Added some more practical rotate examples. Added optional ANGLE_ORIGIN argument,
01:55.34CIA-62BRL-CAD: to divorce rotation ANGLE from CENTER of rotation. This will allow for the use
01:55.34CIA-62BRL-CAD: of any reference AXIS/ANGLE in the drawing. Several corrections.
02:01.53CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r2991 10/wiki/User:Bhinesley: /* Log */ today
04:12.46*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
07:06.24*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
07:06.24*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:46.57CIA-62BRL-CAD: 03bhinesley * r45414 10/brlcad/trunk/src/libged/alter.c: fixed several errors and removed poor examples
09:44.05*** join/#brlcad merzo (~merzo@160-35-132-95.pool.ukrtel.net)
10:10.33CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r2992 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 7 */ added screenshot for cloud shader
12:35.20*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
14:15.12*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
16:38.06CIA-62BRL-CAD: 03r_weiss * r45415 10/brlcad/trunk/src/libged/mater.c: Fixed bug in the mged 'mater' command where the inheritance could not be changed unless the color is changed at the same time. This change was in function 'ged_mater' within file 'mater.c' within the 'libged' library.
17:12.48*** join/#brlcad Elrohir (~kvirc@p5B14AA52.dip.t-dialin.net)
18:29.31*** join/#brlcad mafm (~mafm@205.Red-88-15-70.dynamicIP.rima-tde.net)
18:46.41*** join/#brlcad merzo (~merzo@160-35-132-95.pool.ukrtel.net)
19:27.34*** join/#brlcad Stattrav (~Stattrav@14.96.30.86)
19:27.35*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:14.59*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
22:35.46*** join/#brlcad kunigami (~kunigami@201.53.206.27)
23:32.16*** join/#brlcad tharis20 (~tharis@bl21-47-193.dsl.telepac.pt)
IRC log for #brlcad on 20110709

IRC log for #brlcad on 20110709

01:17.22*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
02:22.53*** join/#brlcad DarkCalf (DC@173.231.40.98)
02:25.52*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
03:22.43*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
04:22.58*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
04:49.15*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:30.17*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
08:56.10*** join/#brlcad mafm (~mafm@235.Red-193-153-198.dynamicIP.rima-tde.net)
09:16.16*** join/#brlcad mafm_ (~mafm@235.Red-193-153-198.dynamicIP.rima-tde.net)
09:47.42*** join/#brlcad merzo (~merzo@17-183-94-178.pool.ukrtel.net)
15:41.44*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
17:39.43*** join/#brlcad Stattrav (~Stattrav@117.192.140.74)
17:39.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:50.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:00.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:09.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:20.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:34.36*** join/#brlcad Stattrav (~Stattrav@117.192.140.74)
19:34.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
IRC log for #brlcad on 20110710

IRC log for #brlcad on 20110710

03:19.32*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
04:51.07*** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net)
05:07.25*** join/#brlcad bhinesley (~bhinesley@99.125.86.110)
07:10.05*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
07:10.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:05.17*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
13:55.04*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
13:57.36*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:02.13*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:04.00*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:08.37*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:13.13*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:18.04*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:22.43*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:27.29*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:32.07*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:34.14*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:38.59*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:43.38*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:45.07*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:49.44*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:54.20*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
14:59.22*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
15:03.58*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
15:08.34*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
15:10.43*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
15:15.34*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
15:20.11*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
15:24.52*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
15:29.38*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
15:34.22*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
15:37.42*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
15:42.19*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
15:46.55*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
15:51.34*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
18:50.16*** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net)
18:56.20*** join/#brlcad Stattrav (~Stattrav@14.96.213.27)
18:56.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:16.08CIA-62BRL-CAD: 03brlcad * r45416 10/brlcad/trunk/src/other/step/src/express/expscan.l:
19:16.09CIA-62BRL-CAD: from mpictor's commit fixing a crash from newer versions of flex,
19:16.09CIA-62BRL-CAD: https://github.com/mpictor/StepClassLibrary/commit/37ac5dc82f6da91a62a39596ad0582649fce91a6;
19:16.09CIA-62BRL-CAD: which is from a gentoo spim patch, which seems to have originated from a fedora
19:16.09CIA-62BRL-CAD: patch. apparently yy_init was changed from meaning 'needs to be initialized' to
19:16.09CIA-62BRL-CAD: 'was initialized', effectively flipping the boolean meaning.
20:23.44*** join/#brlcad mafm_ (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
21:10.05*** join/#brlcad mafm (~mafm@223.Red-83-54-181.dynamicIP.rima-tde.net)
22:53.55CIA-62BRL-CAD: 03bhinesley * r45417 10/brlcad/trunk/src/libged/alter.c: Made several corrections to existing manuals, and wrote mock manual for "scale" command. It turns out that it is closer to "rotate" than "translate"\; still much simpler, though. Needs examples to work out any issues.
22:57.10CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2993 10/wiki/Astronomical_units: initial page on astronomical units
23:09.06CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2994 10/wiki/Bending_light: initial writeup for bending light
23:20.04CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2995 10/wiki/Celestial_mechanics_particle_system: initial celestial mechanics idea
23:23.30CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2996 10/wiki/Celestial_mechanics_particle_system: refer to pnts and ell primitives
23:36.31CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2997 10/wiki/Non-vacuum_gravity_simulator: initial physics engine integration idea
23:56.09CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2998 10/wiki/Polarization: initial polarization article
IRC log for #brlcad on 20110711

IRC log for #brlcad on 20110711

00:37.19CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r2999 10/wiki/Density_functions: initial page on material (density) objects
00:37.29CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3000 10/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas: link to all of the new articles
00:41.24*** join/#brlcad kunigami (~kunigami@201.53.206.27)
00:46.03*** join/#brlcad bhinesley (~bhinesley@99.125.86.110)
00:55.46*** join/#brlcad ibot (~ibot@rikers.org)
00:55.46*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD has applied to participate in the ESA Summer of Code in Space!
02:09.13CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3001 10/wiki/Community_Publication_Portal: initial stub of 7.20.2 release announcement
02:46.34CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3002 10/wiki/Community_Publication_Portal: /* Release 7.20.2 */ restructure
03:47.28CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3003 10/wiki/Community_Publication_Portal: /* Release 7.20.2 */ expand writeup, consolidate contributors
03:52.36CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3004 10/wiki/Community_Publication_Portal: /* Release 7.20.2 */
03:57.38CIA-62BRL-CAD: 03brlcad * r45418 10/brlcad/trunk/NEWS: reword the writeup for brevity/clarity
04:15.18CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3005 10/wiki/Community_Publication_Portal: /* Final Editorial Review */ release 7.20.2 posted
04:42.53*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
06:50.32*** join/#brlcad merzo (~merzo@193.254.217.44)
08:05.10CIA-62BRL-CAD: 03d_rossberg * r45419 10/brlcad/trunk/CMakeLists.txt: corrected comment on brlcad.dll flag
08:18.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:32.40*** join/#brlcad poolio_ (~poolio@BZ.BZFLAG.BZ)
09:47.43*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
09:50.30*** join/#brlcad mafm (~mafm@12.Red-193-153-199.dynamicIP.rima-tde.net)
10:01.09*** join/#brlcad piksi_ (piksi@pi-xi.net)
11:31.48*** join/#brlcad kunigami (~kunigami@201.53.206.27)
12:46.26*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:57.35CIA-62BRL-CAD: 03brlcad * r45420 10/brlcad/trunk/src/liboptical/material.c: two found: labels in the same file, bad ju ju
14:20.50*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
14:27.34d_rossbergkunigami: could you solve the refraction issue?
14:29.39kunigamid_rossberg: nope. I think I'll redo the tests and attach the images in the email. Maybe they give a better idea on what's going on
14:32.13d_rossbergdo you know now whats the difference between pt_inhit and pt_outhit?
14:32.23CIA-62BRL-CAD: 03erikgreenwald * r45421 10/brlcad/trunk/src/libgcv/bottess.c: add precomputed face add to avoid fp fuzz on the plane equation
14:45.10*** join/#brlcad silvap (~silvap@static-96-255-52-7.washdc.fios.verizon.net)
14:53.39kunigamiI'm not sure if I understand them correctly. As far as I understand, the outhit is the intersection of the ray as if I were refracted
15:14.36d_rossbergthe ray-trace gives you a series of hits with solids (regions or primitives)
15:15.36d_rossberga hit with a solid is the part of the ray which lies inside the solid
15:16.25d_rossbergand it is determi
15:16.55d_rossberg... sorry, defined by the entry and exit point
15:18.40d_rossbergi.e. pt_inhit descibes the point where your ray enters a solid (point, distance from the rays origin normal of the solin in this point, ...)
15:19.23d_rossbergand pt_outhit does the same for the point where the ray leaves the solid
15:20.38d_rossbergnormaly the light goes outside the solids, but in case of refraction you are interested in the lights way inside a solid
16:34.09brlcadkunigami: make sense?
16:36.02brlcadif you shot a ray towards a sphere, you'll get an inhit at the point where it hits, then an outhit on the other side of the sphere where it would exit
16:36.34brlcadremember you're dealing with solid geometry, not just surfaces, so a sphere isn't just the outer surface -- it's solid all the way through
16:42.34brlcadso the ray tracer gives you sets of inhit/outhit (i.e., partitions)
16:43.34brlcadyou might want to see how our existing phong shader -- src/liboptical/sh_plastic.c -- deals with refraction and transmission, calls rr_render() from refract.c
16:56.37*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
17:02.16kunigamibrlcad: but this outhit takes into account the index of refraction, right?
17:02.50kunigamiI read the code in refract.c. I borrowed part of that code to implement the refraction callback of sh_osl
17:04.14brlcadit depends what you mean by taking it into account
17:05.04brlcadif you rt_shootray an application struct with index of refraction set, then NO .. it won't take it into account for *that* ray being fired
17:05.31brlcadinhit/outhit will always be along the ray pnt->dir being fired
17:05.46brlcadthe index of refraction controls the next ray being fired
17:10.22kunigamihmm, interesting. I had the impression that changing the index of refraction did changed the way the glass looked. maybe I had changed something else
17:10.28kunigamiI'll check again
19:29.54*** join/#brlcad mafm_ (~mafm@12.Red-193-153-199.dynamicIP.rima-tde.net)
19:45.21CIA-62BRL-CAD: 03bhinesley * r45422 10/brlcad/trunk/src/libged/alter.c: Added a few examples to the scale manual to help work out issues. It is straightforward compared to the rotate command. These examples are probably sufficient.
19:56.48bhinesleybrlcad: I'm starting to work on the argument handler (alter) for translate/rotate/scale.
19:56.48bhinesleyWhile all 3 commands accept different arguments, the methods of grouping them are all based on the same concepts. I'm building a sort of argument handling system for alter, so that adding another command, or altering an existing one will be easy enough. What I'm implying is that you can check out the mock manuals at your leisure, and just let me know what changes you'd like.
20:32.29*** part/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
21:49.33brlcadbhinesley: okay
21:49.50brlcadhaven't had a chance to read up in detail since you started on rotate, but will this week
21:50.33brlcadat a glance, would really like scale to accept simple uniform scaling via single arg
21:50.39brlcadlike scale 2.0 foo
21:51.08brlcadsince that's the most common use case, it should be the most brief
21:51.15bhinesleynods
21:53.58bhinesleyI could make  'scale 2.0' == 'scale 2.0 2.0 2.0' while 'scale -x 2.0' performs a stretch
21:56.28bhinesleybut then, should 'scale 2.0 3.0' == 'scale -x 2.0 -y 3.0'? This would seem weird: 'scale 2.0 3.0' == 'scale 2.0 3.0 3.0'
21:58.11bhinesleylooks like 'sca' would do the prior
22:06.45CIA-62BRL-CAD: 03bhinesley * r45423 10/brlcad/trunk/src/libged/alter.c: All 3 FACTOR_TO_POS arguments areset to its first argument, if it is the only one given.
22:07.55CIA-62BRL-CAD: 03bhinesley * r45424 10/brlcad/trunk/src/libged/alter.c: accidentally removed a brace in the last commit
23:31.03``Erikmebbe scale 2/2/2 ? so'z you can do 2// or whatever?
23:35.56``Erik(defmethod scale-x (obj val) (* (x-of obj) val)) (defmethod scale (obj val) (scale-x obj val) (scale-y obj val) (scale-z obj val)) ... :D
23:41.59bhinesley``Erik see libged/alter.c for the manuals I've cooked up so far
23:43.12bhinesleynotably: {xyz_factor | {x y [z]}} | {[-x {x | X_OBJ}] [-y {y | Y_OBJ}] [-z {z | Z_OBJ}]}
23:45.18bhinesley2// would be a stretch in the x-axis
23:45.29bhinesleywhile 2/2/2 would be a uniform scale
23:47.06bhinesleythe slashes would actually work pretty well though, as far as trimming the size of the commands
23:50.37bhinesleyit means we could do things like './sphere.s 1 4 5/7' rather than '-x . -y sphere.s 1 4 5 -z 7'
23:51.48bhinesley(which means: use the x-coordinate of each argument we're scaling, the y-coordinate of the center of sphere.s offset (1,4,5), and the z-coordinate of 7)
23:53.38bhinesleynot that the '.' makes much sense for that particular usage of 'scale', but it is very useful for translate/rotate, which use a similar syntax
23:59.08CIA-62BRL-CAD: 03bhinesley * r45425 10/brlcad/trunk/src/libged/alter.c: expand upon the definition of OFFSET_DIST, to clarify its dissimilarities from *POS arguments
IRC log for #brlcad on 20110712

IRC log for #brlcad on 20110712

00:33.27*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
00:42.09*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
03:34.32``Erikthe / is a relatively safe token for splitting and we use it elsewhere to denote tokens, the comma is used in some locales as a decimal point... if we ever go gettext, could cause issue
03:36.59bhinesleywhat comma are you referring to?
03:37.17``Erik(but I'm no usability expert and make it a point to avoid gui work, so'z *shrug*)
03:37.28``Erik(1,4,5) as a listing of coordinate
03:38.04bhinesleyoh, I was just interpreting the syntax in human readable form
03:38.09bhinesleythere are no commas :)
03:38.26``Erikjust noting that the glyph is risky :) people who haven't done internationalization can easily miss that gotcha :)
03:38.37bhinesleynods
03:38.40bhinesleythanks
03:41.24*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
03:47.15``Erik(and vi, not vim?)
03:52.36``Erikbrlcad: dlo found issues in the solar system scale stuff when mocking up a ringworld as a pre-procdb issue, prolly fp fuzz around 1.5e14mm, so'z the claims in the au page may be a bit... optimistic :)
03:54.07``Erikfor the physics shtuff, my vote is for bullet, my research indicates that it started whupping ode a few years back
04:01.18CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3006 10/wiki/User:Bhinesley: /* Who I am */ vim, not vi :)
04:01.32bhinesley``Erik: ^
04:01.36bhinesley:)
04:02.27``Erik:D I'm a fbsd weenie and the 'default' editor is nvi, very different from vim
04:03.07``Erik(default editor is a bsh, not bash, also confusing to linux folk)
04:03.41bhinesleyI was a fbsd admin for a couple years, but that was a long time ago
04:03.52bhinesley(small company)
04:04.47``Erikcool beans
04:05.17``Erikwhich major?
04:05.23bhinesleycomputer science
04:05.25bhinesleyBS
04:05.36``ErikI meant fbsd major release number :)
04:05.44bhinesleyoh jeez
04:05.55``ErikI went fbsd with a 3, really embraced it at 4
04:06.21``Eriklate 90's, yo
04:07.04bhinesleybased on the release dates on wikipedia it must have been 5 for me
04:07.38bhinesleyI was running 'stable' about 2004 or 2005
04:07.47``Erikbrlcad.org is still running one of the 5 series
04:08.36``Erikit's a good os, can be a bit tricky to maintain if you're not used to the *nix world
04:09.34bhinesleynods
04:09.35bhinesleyI learned on it
04:09.52``Erik<-- is a port maintainer for a couple dozen, has a few hundred pr's, friends with several core folk, good stuff :)
04:10.11bhinesleyawesome
04:10.29``Erikopenbsd is nice, too, theo can be a dick, though
04:10.36bhinesleyhaha
04:10.51bhinesleynever used it, myself
04:11.25``ErikI've only used open in a vm, the X upgrade was a royal pain
04:11.50``Erikdragonfly has some interesting ideas, that was a weird period
04:12.40``Erikwas around '02 I think, major philosophical differences on concurrency and smp
04:13.10``Eriksmelled like both sides weren't listening, just saying that the other side was wrong... was almost like congress *cough* O:-)
04:13.32brlcad``Erik: how is "untested support for astronomical units and lots of room for there to be computational issues" being optimistic?
04:13.35bhinesley"they need to compromise!"
04:14.54brlcadbhinesley: not too worried about supporting FACTOR || X Y || X Y Z .. FACTOR || X Y Z are the two main use cases
04:15.18``Erikbrlcad: the statement that we can do it at a full sol system level, we have known issues at 2% of that
04:15.31brlcador even FACTOR | [-x X] [-y Y] [-z Z]
04:16.15brlcad``Erik: er, where do you see that statement?
04:17.04bhinesleyalright. I won't worry about it, unless it's simpler to just include it.
04:17.14brlcadthe only claim it makes is that objects at that scale can be created .. and then it caveats saying it's all untested and probably has issues
04:17.34``Erikum, the celestial mechanics page says, srry
04:18.41brlcadeven there, it just says you can accurately model the solar system to scale .. which is true, you just can't render that model
04:19.15brlcadand even then -- I don't know if simple ellipsoids at that scale would have an issue
04:19.20``Erikdlo's experiment was a 30m thick strip at 1au and had display issues similar to ogl zbuffer fighting, *shrug*
04:19.59brlcadthat's already changing the numbers involved substantially
04:20.07brlcadsmall detail at a massive scale, I'd expect a problem
04:20.26brlcadmodeling the solar system is effectively no detail at a massive scale
04:20.38``Erikyeah, he was trying to hand-build a niven ringworld, to preview the proc-db I started
04:21.05brlcadI don't see why a super massive sph wouldn't render just fine as an AU scale
04:21.11brlcads/as/at/
04:21.39``Erikan ell should, I'd think
04:21.45brlcadthe only issue might be the transformation it attempts to perform during raytracing so that the primitive is in a normal unitized position during eval
04:21.55brlcadthat might bork the floating
04:22.23brlcadI've created a planet-sized ell before, no problems
04:22.34brlcadbut only at the origina
04:22.40``Erikit might be an op ordering issue that he was seeing, too *shrug*
04:22.53``Erikplanet sizes run quite a wide gambit
04:23.08``Erikwe have the earth sized planet with the star trek stuff in orbit, that works well
04:23.24``Erikbut a planet and local orbit is tiny compared to a solar system
04:24.04brlcadbhinesley: note that some objects can only be scaled uniformly, so there will have to be error checking if attempting to only scale 1 or 2 axes
04:24.40bhinesleyI figured as much; such as a sphere
04:26.03``Erikmeasuring in meters, I think a 64b ieee854 is around ~10 meter accuract at a pluto orbit (~50au), so mm would be 10km accuracy
04:26.07brlcadsphere is fine, they become ellipsoids
04:26.20bhinesleyoh, hah
04:26.24``Erikand that's straight measure, no math to increase inacuracy
04:26.25brlcadtorus is the typical error case
04:27.00``Eriktgc's can also be touchy, iirc
04:27.22brlcad``Erik: which implies simulating our solar system to scale would be just fine .. 10km would be sub-sub-pixel
04:28.37``Erikmeans I can't put a toy jeep on neptune, though :D
04:29.28brlcadheh
04:30.22``Eriknow my frame of reference... back in the late 90's, I was trying to make an xwing type game and was looking for ways to have a small craft be accurate anywhere in a solar system
04:30.24brlcadyeah, that'd be about *45M* km per pixel for a basic "overhead" render
04:31.24brlcadmeans earth is sub-pixel to scale too
04:31.53brlcadso you'd have to scale the bodies up several orders of magnitude, which might be neat in itself
04:31.54``Erikfor most displays, the only thing that MIGHT get a pixel for a solar system scale render ist he sun...
04:32.41brlcadyeah, sun is sub-pixel 1.39M km diameter
04:33.12brlcadthree orders of magnitude would make them visible
04:33.15``Erikbut a 10,000 km 'tile' eliminates any surface detail in the outer bits
04:35.36``Erik*shrug* at solar scales, we lose a lot of accuracy, 'sall :)
04:36.18``Eriknerds who want to make ringworlds, dyson spheres, etc might be a bit upset when it doesn't quite work right
04:37.29``Erikimma catch some z's, hasta manana :)
04:38.52brlcadnods
04:38.55bhinesleysee ya
04:39.10brlcadthe first units project aims to help fix the units issue better
04:39.59brlcadmaking sure the math is stable for existing prims, then maybe working on scaling zones
04:41.21brlcadbhinesley: curious choice of 'alter' for the command name
04:41.35brlcadany reason that over 'edit'?
04:41.55bhinesleynope, edit would be fine
04:42.14bhinesleyalter just came to mind, and it's easy enough to change, so I went with it
04:43.01brlcadit's fine, just wondering if there was some underlying motivation
04:43.15brlcadboth edit and alter are a little vague
04:43.56brlcadambiguous even, since I can't edit/alter some object parameters
04:45.31brlcadthose three subcommands are all transformations, so 'xform' would be pretty fitting too
04:46.47bhinesleywhatever name it is, it will be "extern thename" in ged_private.h
04:47.03bhinesleyand also, "extern thename_translate", etc
04:47.30bhinesleythe idea is, thename_translate will be as primitive of a translate as possible
04:48.01brlcadyou mean only as private api, not a new parent command?
04:48.26bhinesleyif I understand you correctly: there will be both
04:48.43brlcadthen what do you mean by "extern thename" in ged_private.h ?
04:49.01brlcadged_private is for declaring non-public API (functions)
04:49.28bhinesleyged_thename will be public
04:49.47brlcadso then it goes in ged.h :)
04:49.56bhinesleycorrect
04:50.21brlcadokay, just confused by your prior statement
04:50.21brlcad00:46 < bhinesley> whatever name it is, it will be "extern thename" in ged_private.h
04:50.26bhinesleythere is a separate function, "thename", which is for calling internally without using argv
04:50.52brlcadah, I think I might get what you're saying
04:50.57bhinesleyged_thename simply parses command line arguments and passes it to thename
04:51.01brlcadnods
04:51.03brlcadgot it
04:51.16bhinesleyyeah, excuse me... I'm not very good at expressing these things
04:51.23bhinesley(yet)
04:52.14brlcadfuncs still only need to be declared extern in ged_private.h if they're going to be used by more than one file
04:52.29brlcadso if it all lives in alter.c, you're fine with simple function ordering
04:53.37bhinesleyA command that needs to do a simple translate could call thename_translate. If it needed to do a batch translate using '.', or if it needed to use objects/distances to calculate coordinates, then it could call thename.
04:53.52brlcadit'd only be if you broke it out into alter.c, translate.c, rotate.c, scale.c with the latter three ged_[cmd]() funcs calling ged_alter()
04:55.05bhinesleyokay, I'm a little confused.
04:55.20brlcadno worries, carry on :)
04:55.44bhinesleyged.h is for sharing with commands outside of libged, while ged_private.h is for sharing internally to libged only?
04:56.01brlcadalmost
04:56.37brlcadged.h is public declaration for use anywhere (inside/outside)
04:57.06brlcadged_private.h is private declaration where there is internal reuse
04:57.47brlcadso funcs are added to ged.h when they're "published" but should only ged added to ged_private.h when they're actually used in more than one file
04:57.55brlcadeven if they're ripe for reuse
04:58.35bhinesleyokay
04:58.50brlcadnot a big issue if they're declared in ged_private.h and not used in multiple places, but the decls might get removed/cleaned up down the road to keep files simple
04:59.41bhinesleysounds like ged_thename goes in ged.h for now, and eventually thename/thename_translate/etc may go in ged_private.h
04:59.48brlcadthere are 400+ commands which means there could easily be 3x that many "private yet potentially reusable" internal funcs .. which wouldn't be too useful to browse through
05:00.11brlcadright, that's the intention at least
05:00.58brlcadmy guy feeling is that any function prime for libged reuse probably doesn't even belong in libged
05:01.07brlcadbegs refactoring down into librt
05:01.33bhinesleywhy does so much end up in librt? I thought it was just raytracing?
05:01.37brlcadaside from commands calling other commands at the libged API level
05:01.47brlcadlibrt isn't just raytracing
05:02.00brlcadit's the underlying geometry management
05:02.09bhinesleyI mean, I have seen that... I just didn't understand the reasoning
05:02.49brlcadgeometry representation, disk I/O, serialization, and ray tracing
05:03.24brlcadit would probably be more appropriately named "libg", except that the main reason for its existence is to shoot rays
05:03.56bhinesleyalright, that makes sense
05:04.15brlcadand there is a very close relationship between the on-disk representation and the in-memory format used for ray-tracing
05:04.44brlcadthe two are tightly coupled for performance reasons, why we can raytrace massive multi GB scenes in mere seconds
05:04.53bhinesleyahh
05:05.42brlcadwe've talked about separating the two into different libraries, but it would be tricky to do cleanly API-wise
05:05.53bhinesleyso, as you were saying: should uhh... 'thename' live in librt?
05:06.28brlcadif it's argc/argv style, then it still belongs in libged
05:07.06bhinesleywell, only ged_thename is argc/argv style
05:12.21brlcadit depends what the command ends up looking like parameter-wise
05:12.39brlcadkeep an eye on rt_matrix_transform() since that is the current closest-fit API call already in librt that comes to mind
05:12.50brlcadit's how mged applies most matrix edits now
05:13.00brlcads/matrix/primitive/
05:13.37brlcadthrough transformation matrices (with scaling, translation, and rotation components)
05:18.20bhinesleyinteresting
08:10.00*** join/#brlcad mafm (~mafm@83.Red-83-54-79.dynamicIP.rima-tde.net)
08:36.36brlcadcalls it done for now
08:38.56*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
08:38.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:34.51CIA-62BRL-CAD: 03bhinesley * r45426 10/brlcad/trunk/src/libged/alter.c: Set up the struct and flags for ged_alter and alter command argument handling. Other small cleanup/setup stuff.
11:18.17CIA-62BRL-CAD: 03indianlarry * r45427 10/brlcad/trunk/include/dm.h: externalize display manager interfaces
13:42.28*** join/#brlcad mafm (~mafm@83.Red-83-54-79.dynamicIP.rima-tde.net)
13:56.33*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
16:30.28*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
17:30.54CIA-62BRL-CAD: 03starseeker * r45428 10/brlcad/trunk/CMakeLists.txt: If we don't have a defined CMAKE_SIZEOF_VOID_P, assume 32 bit to be safe.
17:59.24CIA-62BRL-CAD: 03erikgreenwald * r45429 10/brlcad/trunk/CMakeLists.txt: match the endif to the if
18:13.20CIA-62BRL-CAD: 03r_weiss * r45430 10/brlcad/trunk/ (6 files in 3 dirs): (log message trimmed)
18:13.20CIA-62BRL-CAD: Changed function nmg_model_edge_g_fuse by renaming it to nmg_edge_g_fuse and
18:13.20CIA-62BRL-CAD: allowing the magic of a nmg object to be passed in instead of a pointer to a nmg
18:13.20CIA-62BRL-CAD: model structure. This change allows the function to fuse edge geometry in other
18:13.20CIA-62BRL-CAD: smaller nmg objects such as an nmg shell or nmg faceuse. The following files
18:13.20CIA-62BRL-CAD: were changed raytrace.h nmg_simplify.c wdb_obj.c nmg_tri.c nmg_fuse.c
18:13.21CIA-62BRL-CAD: nmg_bool.c. The purpose of this change is to improve performance of nmg boolean
18:38.16*** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
18:43.31*** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
18:44.53*** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
19:23.54*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
19:51.40CIA-62BRL-CAD: 03r_weiss * r45431 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c:
19:51.40CIA-62BRL-CAD: Updated function nmg_bool within file nmg_bool.c. This change removes
19:51.40CIA-62BRL-CAD: unnecessary operations to improve the speed of nmg boolean operations. This
19:51.40CIA-62BRL-CAD: change will increase the speed of functions such as the mged 'ev' and 'facetize'
19:51.40CIA-62BRL-CAD: commands.
20:29.39CIA-62BRL-CAD: 03r_weiss * r45432 10/brlcad/trunk/ (include/raytrace.h src/librt/primitives/nmg/nmg_ck.c):
20:29.39CIA-62BRL-CAD: Added a new function nmg_vsshell which validates the pointer structures within a
20:29.39CIA-62BRL-CAD: single nmg shell structure and all structures within. The function nmg_vshell
20:29.39CIA-62BRL-CAD: was changed to call the nmg_vsshell function. The function nmg_vshell is passed
20:29.39CIA-62BRL-CAD: a list of shells to validate instead of a single shell. The purpose of this
20:29.39CIA-62BRL-CAD: change is to allow a single nmg shell to be validated instead of all shells
20:29.40CIA-62BRL-CAD: within an nmg model. The files raytrace.h and nmg_ck.c were changed.
20:36.28*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:16.57CIA-62BRL-CAD: 03r_weiss * r45433 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
21:16.58CIA-62BRL-CAD: Updated functions nmg_triangulate_model and nmg_triangulate_shell within file
21:16.58CIA-62BRL-CAD: nmg_tri.c. These changes make the operations of these functions consistent so
21:16.58CIA-62BRL-CAD: that the difference is only one triangulates an nmg shell and the other
21:16.58CIA-62BRL-CAD: triangulates all the nmg shells within an nmg model.
21:18.31*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
21:20.56CIA-62BRL-CAD: 03bhinesley * r45434 10/brlcad/trunk/src/libged/alter.c: Added a union to store distinct command argument groupings for each command. This obsoleted some of the command-specific #define flags; I'll fix that later. Started on helper functions for building args.
21:31.30CIA-62BRL-CAD: 03r_weiss * r45435 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c:
21:31.30CIA-62BRL-CAD: Fixed a bug in function class_eu_vs_s within file nmg_class.c. The mid point of
21:31.30CIA-62BRL-CAD: the edge was not computed correctly. I also used points near the vertices but
21:31.30CIA-62BRL-CAD: still on the edge for the fallback if the mid point can not be classified. This
21:31.30CIA-62BRL-CAD: change improves the success of nmg boolean operations and can be seen when
21:31.30CIA-62BRL-CAD: running, for example, the mged 'facetize' and 'ev' commands.
22:14.50CIA-62BRL-CAD: 03r_weiss * r45436 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
22:14.50CIA-62BRL-CAD: Updated the prototype version of the function cut_unimonotone within file
22:14.50CIA-62BRL-CAD: nmg_tri.c. This is a work in progress and this change is disabled by default.
22:14.50CIA-62BRL-CAD: Some code cleanup was done and the ability to reverse the direction of loopuse
22:14.50CIA-62BRL-CAD: was added to correct situations after a loop cut that the direction reverses
22:14.51CIA-62BRL-CAD: i.e. is cw and should be ccw. This change supports the prototype version of the
22:14.52CIA-62BRL-CAD: function nmg_triangulate_fu.
22:30.37CIA-62BRL-CAD: 03brlcad * r45437 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am zoom/ zoom/zoom.c zoom.c): zoom becomes the guinea piggie. move it into a subdir in preparation for sorting out fully self-contained modular commands.
22:31.19CIA-62BRL-CAD: 03brlcad * r45438 10/brlcad/trunk/src/libged/zoom/zoom.c: remove unnecessary headers and useless doxy file comment
22:32.36CIA-62BRL-CAD: 03brlcad * r45439 10/brlcad/trunk/src/libged/zoom/zoom.c: technically, ged_private.h is no longer in this dir
22:40.28CIA-62BRL-CAD: 03brlcad * r45440 10/brlcad/trunk/src/libged/ (ged_private.h vutil.c zoom/zoom.c): move _ged_do_zoom() out of vutil into zoom.c since that's the only place it's used, no longer needing private decl. rename to zoom().
22:44.03CIA-62BRL-CAD: 03brlcad * r45441 10/brlcad/trunk/src/libged/zoom/zoom.c: reduce and simplify
22:44.51CIA-62BRL-CAD: 03brlcad * r45442 10/brlcad/trunk/src/libged/zoom/zoom.c: don't need a db to scale the view
22:58.13CIA-62BRL-CAD: 03brlcad * r45443 10/brlcad/trunk/src/libged/zoom/zoom.c: make sure we set sf before testing its value, simplify validity to the two boundaries while treating the edge case as inside.
22:59.44CIA-62BRL-CAD: 03brlcad * r45444 10/brlcad/trunk/include/vmath.h: ws
23:51.16*** join/#brlcad mafm (~mafm@83.Red-83-54-79.dynamicIP.rima-tde.net)
IRC log for #brlcad on 20110713

IRC log for #brlcad on 20110713

00:28.57*** join/#brlcad DarkCalf (DC@173.231.40.98)
00:50.42CIA-62BRL-CAD: 03kunigami * r45445 10/brlcad/trunk/src/liboptical/ (liboslrend.h sh_osl.cpp):
00:50.42CIA-62BRL-CAD: trying to allow multi-threading. I surrounded OSLRender access with semaphores
00:50.42CIA-62BRL-CAD: lock, but with 2 processors it is still crashing. I first tried using
00:50.42CIA-62BRL-CAD: RT_SEM_LAST, but I get a run-time error because the number of semaphores
00:50.42CIA-62BRL-CAD: exceeded 12, so I added a random identifier 8
01:59.46*** join/#brlcad ibot (~ibot@rikers.org)
01:59.46*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD has applied to participate in the ESA Summer of Code in Space!
03:06.12starseeker``Erik: do you know a good desktop PC maker these days?
03:06.43starseekermay have to look into a new system, and isn't sure he can afford the time to collect components and do it "right"
03:09.28*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
03:28.56*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
03:42.53CIA-62BRL-CAD: 03bhinesley * r45446 10/brlcad/trunk/src/libged/alter.c: update argument flags, add several argument node helper functions
05:39.30*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
07:30.00*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:34.45*** join/#brlcad Stattrav (~Stattrav@117.202.18.108)
07:34.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:25.14*** join/#brlcad mafm (~mafm@90.Red-83-42-153.dynamicIP.rima-tde.net)
09:14.56*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
09:14.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:54.15*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
12:08.38``Erikstarseeker: been starting to research that myself, think I'm about due for 2 new machines
13:21.29kunigami_Which tool do you use to debug multi-thread applications?
13:30.31brlcadkunigami_: gdb can be used to debug multithreaded apps, you can switch threads and processes while debugging, set separate breakpoints, etc
13:30.45*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
13:30.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:37.02CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3007 10/wiki/Celestial_mechanics_particle_system:
13:39.05*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:42.15*** join/#brlcad mafm (~mafm@90.Red-83-42-153.dynamicIP.rima-tde.net)
13:47.34brlcadyawns
14:42.00*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
17:25.06*** join/#brlcad merzo (~merzo@252-7-132-95.pool.ukrtel.net)
18:20.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:24.36*** join/#brlcad dli (~dli@66.49.188.111)
18:49.40CIA-62BRL-CAD: 03erikgreenwald * r45447 10/brlcad/trunk/src/proc-db/ringworld.c: add some body to make this do something (shows render issues at large scale)
18:52.34CIA-62BRL-CAD: 03erikgreenwald * r45448 10/brlcad/trunk/NEWS: list ringworld proc-db
18:53.48CIA-62BRL-CAD: 03brlcad * r45449 10/brlcad/trunk/include/bu.h: add a BU_LIST_INIT_MAGIC() macro so we can init and set a magic as a one-liner
18:59.13CIA-62BRL-CAD: 03brlcad * r45450 10/brlcad/trunk/include/bu.h: use the new BU_LIST_INIT_MAGIC() macro, reduce
19:01.02CIA-62BRL-CAD: 03brlcad * r45451 10/brlcad/trunk/include/ged.h: initial stubs for supporting a ged command container within the ged struct. a ged_cmd object describes a single named command providing the name, a brief description, the name of its manual page, and callback hooks.
19:01.37CIA-62BRL-CAD: 03brlcad * r45452 10/brlcad/trunk/include/magic.h: define a magic number for ged_cmd objects. using 'exec' since that's the heart of a ged command.
19:08.34CIA-62BRL-CAD: 03brlcad * r45453 10/brlcad/trunk/include/ (bu.h magic.h):
19:08.34CIA-62BRL-CAD: fix a FIXME, define a magic number for bu_observer objects. if there was bad
19:08.34CIA-62BRL-CAD: code that relied on zero-initialization (e.g., via calloc), that will no longer
19:08.34CIA-62BRL-CAD: result in proper initialization and will fail until fixed with a
19:08.34CIA-62BRL-CAD: BU_OBSERVER_INIT OR BU_OBSERVER_INIT_ZERO call.
19:16.53CIA-62BRL-CAD: 03brlcad * r45454 10/brlcad/trunk/src/liboptical/sh_prj.c: set the magic as soon as we begin as part of initialization.
19:18.13CIA-62BRL-CAD: 03brlcad * r45455 10/brlcad/trunk/src/ (5 files in 3 dirs): use the new BU_LIST_INIT_MAGIC() macro, reducing a few lines
19:25.40CIA-62BRL-CAD: 03brlcad * r45456 10/brlcad/trunk/src/libged/zoom/zoom.c: work in progress. define the zoom command including load/unload functions that add/remove it from a gedp.
19:29.17bhinesleygrabs popcorn
19:32.01kunigami_Even adding semaphores around OSLRender sh_osl crashes for two processors. I tried increasing the size of the stack at bu_parallel. without sucess
19:33.18kunigami_The problem only occurs when I do recursive calls (through rt_shootray)
19:34.07kunigami_I took a look at the implementation of rr_render and it does not seem to take any extra care before calling rt_shootray
19:57.30CIA-62BRL-CAD: 03brlcad * r45457 10/brlcad/trunk/include/magic.h: expand all of the magic numbers with what they represent in ascii, using '?' for non-printable characters.
20:13.37CIA-62BRL-CAD: 03starseeker * r45458 10/brlcad/trunk/CMakeLists.txt:
20:13.37CIA-62BRL-CAD: Start trying to get the point where we can do 64 bit builds on 32 bit systems
20:13.37CIA-62BRL-CAD: and vice versa with the flick of an option. Start with a more verbose warning
20:13.37CIA-62BRL-CAD: and option correction for MSVC, where one must pick one generator or the other
20:13.37CIA-62BRL-CAD: at CMake configure time.
21:25.10CIA-62BRL-CAD: 03starseeker * r45459 10/brlcad/trunk/src/libfft/CMakeLists.txt: Whoops - adding --no-undefined to linker flags caught libfft needing M_LIBRARY
21:26.08CIA-62BRL-CAD: 03starseeker * r45460 10/brlcad/trunk/CMakeLists.txt: Add --no-undefined to linker, fix printing of linker settings.
21:27.10CIA-62BRL-CAD: 03starseeker * r45461 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Untested, but add in some flags intended to help handle the 'build 32 on 64bit' situation.
21:31.13CIA-62BRL-CAD: 03starseeker * r45462 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Add linker settings for 32 as well. Ideally these should be tests to see if the linker can handle the flags, but not sure how to set that up yet.
21:31.37CIA-62BRL-CAD: 03brlcad * r45463 10/brlcad/trunk/include/nurb.h: don't conditionally include the headers we need. they already have built-in inclusion protection.
21:34.51CIA-62BRL-CAD: 03brlcad * r45464 10/brlcad/trunk/ (3 files in 3 dirs): replace RT_CNURB_MAGIC and RT_SNURB_MAGIC with the corresponding NMG magic defines that were identical values.
22:40.14CIA-62BRL-CAD: 03bhinesley * r45465 10/brlcad/trunk/src/libged/alter.c: rename several silly struct/union/members, more helper function work
22:46.33kunigami_Running with GDB, I always get one of these two errors: http://paste.ubuntu.com/643588/ (the cause seems to be invalid memory access)
22:52.43CIA-62BRL-CAD: 03bhinesley * r45466 10/brlcad/trunk/src/libged/ (alter.c edit.c): renaming alter to edit... let's see if I can rename the file first
23:01.07CIA-62BRL-CAD: 03bhinesley * r45467 10/brlcad/trunk/ (6 files in 4 dirs): other instances of alter that needed to be renamed to edit, and add edit command to archer
23:16.44*** join/#brlcad mafm (~mafm@90.Red-83-42-153.dynamicIP.rima-tde.net)
23:28.38CIA-62BRL-CAD: 03bhinesley * r45468 10/brlcad/trunk/src/mged/setup.c: rename alter -> edit for mged
23:29.42CIA-62BRL-CAD: 03bhinesley * r45469 10/brlcad/trunk/src/libged/edit.c: make most functions HIDDEN, at least for now
IRC log for #brlcad on 20110714

IRC log for #brlcad on 20110714

00:36.49*** join/#brlcad crux000 (~dan@66.110.178.234)
00:37.50*** part/#brlcad crux000 (~dan@66.110.178.234)
00:45.53CIA-62BRL-CAD: 03kunigami * r45470 10/brlcad/trunk/src/liboptical/sh_osl.cpp:
00:45.53CIA-62BRL-CAD: Instead of copying only a_rtip, a_hit and a_miss from the previous application,
00:45.53CIA-62BRL-CAD: I'm now copying the whole structure before calling rt_shootray at osl_render. I
00:45.53CIA-62BRL-CAD: have no idea why it worked for single threads but not for multiple threads.
00:47.29CIA-62BRL-CAD: 03brlcad * r45471 10/brlcad/trunk/ (7 files in 5 dirs): replace BU_LIST_MAGIC_OK() and BU_LIST_MAGIC_WRONG() with BU_LIST_MAGIC_EQUAL() in order for the API to be more consistent with convention already established in libbn.
00:48.00brlcadkunigami_: aha, so that fixed it?
00:49.23brlcaddidn't realize you were doing a partial copy there .. there are cpu-specific resource structures in an application struct, so when you weren't copying them it would have been in some peculiar uninitialized state (not suitable for threaded use)
00:51.37CIA-62BRL-CAD: 03brlcad * r45472 10/brlcad/trunk/include/bu.h: remove BU_LIST_CLOSE() since it appears to not be in use any where and it's use is rather limited with the embedded return; there's also no corresponding 'open' so it was just bad API to begin with
00:55.33CIA-62BRL-CAD: 03bhinesley * r45473 10/brlcad/trunk/src/ (3 files in 3 dirs):
00:55.33CIA-62BRL-CAD: Add edit and translate/rotate/scale to Archer. Edit command aliases are
00:55.33CIA-62BRL-CAD: intentionally only available to Archer, to keep existing mged commands intact
00:55.33CIA-62BRL-CAD: for the time being. Once everything is working, translate/rotate/scale will be
00:55.33CIA-62BRL-CAD: mapped directly to ged_edit.
00:56.18brlcadbasically, your new application struct wasn't being initialized properly
00:57.07brlcadanytime you do a full struct copy, you should denote it with a /* struct copy */ comment or similar
01:02.42brlcadstarseeker: is nirt building on windows?
01:03.56brlcadah, I see you just disabled those files .. never mind
01:04.28CIA-62BRL-CAD: 03brlcad * r45474 10/brlcad/trunk/src/nirt/dist_def.c: use FMAX() instead of fmax() since the latter is C99
01:32.51kunigami_brlcad: it seems to have been solved :) I'll add that comment
02:13.29*** join/#brlcad merzo (~merzo@252-7-132-95.pool.ukrtel.net)
02:29.32*** join/#brlcad mafm (~mafm@90.Red-83-42-153.dynamicIP.rima-tde.net)
02:49.41*** join/#brlcad IriX64 (~root@bas2-sudbury98-1177871903.dsl.bell.ca)
02:55.50*** join/#brlcad IriX64_ (~root@bas2-sudbury98-1177872273.dsl.bell.ca)
03:00.56*** join/#brlcad IriX64 (~root@bas2-sudbury98-1096601331.dsl.bell.ca)
03:05.59*** join/#brlcad IriX64_ (~root@bas2-sudbury98-1128564768.dsl.bell.ca)
03:35.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
04:18.25CIA-62BRL-CAD: 03brlcad * r45475 10/brlcad/trunk/src/nirt/ (CMakeLists.txt Makefile.am dist_def.c):
04:18.25CIA-62BRL-CAD: remove dist_def.c which was disabled from compilation, but appears to have been
04:18.25CIA-62BRL-CAD: related to an earlier implementation of nirt's backout command. since that code
04:18.25CIA-62BRL-CAD: has since changed and been improved, just kill this old bit.
04:21.53CIA-62BRL-CAD: 03brlcad * r45476 10/brlcad/trunk/ (3 files in 3 dirs): remove nurb's MIN/MAX macros since we already rely on FMIN/FMAX elsewhere.
04:28.06CIA-62BRL-CAD: 03brlcad * r45477 10/brlcad/trunk/src/burst/grid.c: remove the min()/max() functions since there don't seem to be any uses that will have side-effects, use FMIN()/FMAX() instead like already being used.
04:28.52CIA-62BRL-CAD: 03brlcad * r45478 10/brlcad/trunk/src/proc-db/masonry.c: get rid of the min/max macros in favor of the FMIN/FMAX decls from common.h
04:30.58CIA-62BRL-CAD: 03brlcad * r45479 10/brlcad/trunk/src/fb/pl-fb.c: remove unused min() macro
04:36.12CIA-62BRL-CAD: 03brlcad * r45480 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: call NEAR_EQUAL() instead of BN_APPROXEQUAL() since they do the same thing and the latter is unnecessary api.
04:41.03CIA-62BRL-CAD: 03brlcad * r45481 10/brlcad/trunk/include/bn.h: remove BN_APPROXEQUAL since NEAR_EQUAL is practically equivalent just without requiring a bn_tol. looks like the only use was isolated to brep.cpp, so yank it.
04:48.35*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
04:58.48CIA-62BRL-CAD: 03brlcad * r45482 10/brlcad/trunk/src/irprep/ (CMakeLists.txt Makefile.am ir-sgi.1 ir-sgi.c): remove the antiquated ir-sgi tool since IRIX is no longer a supported platform
05:03.04CIA-62BRL-CAD: 03brlcad * r45483 10/brlcad/trunk/src/irprep/ (CMakeLists.txt Makefile.am irdisp.c pictsgi.1 pictsgi.c): same for pictsgi and irdisp tools, which called ir-sgi. remove pictsgi since it's no longer functional without ir-sgi.
05:10.11CIA-62BRL-CAD: 03brlcad * r45484 10/brlcad/trunk/include/ (bu.h raytrace.h): remove sgi/mips references, platform no longer relevant
05:16.58CIA-62BRL-CAD: 03brlcad * r45485 10/brlcad/trunk/src/lgt/ (6 files): remove all references to sgi since the platform is no longer maintainable
05:37.28CIA-62BRL-CAD: 03brlcad * r45486 10/brlcad/trunk/src/canon/ (Makefile.am canonlib.c): more sgi/irix/mips removal. no longer need libds too.
05:45.48CIA-62BRL-CAD: 03brlcad * r45487 10/brlcad/trunk/src/libfb/if_X.c: we still need this with Xorg, not SGI-specific
05:46.02CIA-62BRL-CAD: 03brlcad * r45488 10/brlcad/trunk/src/libfb/ (fbserv_obj.c if_ogl.c): remove sgi from comments
05:50.50CIA-62BRL-CAD: 03brlcad * r45489 10/brlcad/trunk/src/libfb/if_X.c: actually, it looks like peeking at the fd is the only internal we look for so call ConnectionNumber() to get it so we can unset XLIB_ILLEGAL_ACCESS.
05:52.53CIA-62BRL-CAD: 03brlcad * r45490 10/brlcad/trunk/src/ (bwish/Makefile.am conv/Makefile.am): LINK_STATIC_REQUIRED was needed for irix, simplify
05:58.36CIA-62BRL-CAD: 03brlcad * r45491 10/brlcad/trunk/ (16 files in 9 dirs): the sgi/irix/mips platform is no more and has been that way for many years now. reduce maintenance cost, remove and refactor accordingly.
06:17.26*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
06:17.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:12.43*** join/#brlcad merzo (~merzo@193.254.217.44)
08:05.59*** join/#brlcad merzo (~merzo@193.254.217.44)
09:34.51*** join/#brlcad mafm (~mafm@247.Red-83-38-35.dynamicIP.rima-tde.net)
11:49.25*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-187-000.wlan.tudelft.nl)
12:01.57CIA-62BRL-CAD: 03starseeker * r45492 10/brlcad/trunk/CMakeLists.txt:
12:01.57CIA-62BRL-CAD: Ah hah. Per http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix, the
12:01.57CIA-62BRL-CAD: *IGNORE_PATH variables weren't around until 2.8.3 - that's probably why the new
12:01.57CIA-62BRL-CAD: mechanism for ignoring install paths wasn't working in some tests. Bump our
12:01.57CIA-62BRL-CAD: required version, as we need to avoid finding old installed BRL-CAD libraries.
12:22.20*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:33.34brlcadmoin
13:18.35CIA-62BRL-CAD: 03brlcad * r45493 10/brlcad/trunk/src/ (5 files in 4 dirs): more irix reference removals.
13:29.51``Erikyargh
13:30.34``Erikhm, broken stuff, but vaccuum lady is here :/
13:43.37*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
13:43.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:07.56*** join/#brlcad kunigami__ (~kunigami@201.53.206.27)
14:18.16*** join/#brlcad dli (~dli@dsl-67-204-13-217.acanac.net)
14:40.48*** join/#brlcad dli (~dli@66.49.171.226)
16:34.50CIA-62BRL-CAD: 03r_weiss * r45494 10/brlcad/trunk/src/librt/primitives/ars/ars.c: (log message trimmed)
16:34.51CIA-62BRL-CAD: Updated the rt_ars_tess function within file ars.c. I disabled the functions
16:34.51CIA-62BRL-CAD: nmg_shell_coplanar_face_merge and nmg_simplify_shell unless the prototype
16:34.51CIA-62BRL-CAD: triangulation is enabled. The problem is these functions simplify the ars which
16:34.51CIA-62BRL-CAD: causes more work for later triangulating the ars. The original triangulation
16:34.51CIA-62BRL-CAD: code is unable to triangulate the resulting ars after being simplifed. In order
16:34.52CIA-62BRL-CAD: to raytrace an ars, it is first converted to a bot primitive which requires
16:36.08*** join/#brlcad dli (~dli@173.248.249.148)
16:56.49*** join/#brlcad dli (~dli@66.49.131.81)
17:03.28*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
17:04.31starseekerwhoops
17:04.52starseekermake makes a note that quit != part in issi
17:04.55starseekerirssi even
17:19.20``Erikheh, nope, not equal :)
17:30.03*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
17:42.42*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
18:04.02*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:18.20*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
19:18.20*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:38.17CIA-62BRL-CAD: 03bhinesley * r45495 10/brlcad/trunk/src/libged/edit.c: remove trailing ws
19:54.56*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601243.dsl.bell.ca)
19:55.44IriX64brlcad/regress is missing CMakeLists.txt
19:57.49IriX64btw i run el6Workstation now, cygwin is retired :)  ill ask my self to leave now.
20:02.11*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096600661.dsl.bell.ca)
20:02.50IriX64shouldn't do this so soon but cmake generates man/html, configure generates man/html/pdf if anybody cares
20:03.19IriX64i hear me asking myself to leave again, wont be back today
20:25.33kunigami_13min to render a scene with one processor. 14min to run with 2 :) The problem is that I'm blocking the OSLRender every time I query a color, which is probably where most all the time is spent. I'm currently looking for multi-threaded examples using OSL system to block less parts of code.  
20:56.14dlicmake trouble: [ 17%] make[2]: *** No rule to make target `usr/brlcad/share/tclscripts/archer/tclIndex', needed by `src/tclscripts/archer/CMakeFiles/archer_tclIndex'
20:58.54bhinesleyhmm.. . it's working for me
21:03.14bhinesleydli: are you working on a recent svn checkout, a tarball, or what?
21:03.25dlibhinesley, 7.20.2
21:03.36bhinesleywindows?
21:03.43dlibhinesley, linux
21:05.11bhinesleyunless someone else has an idea, I will take a look but it will take me a bit to download/compile
21:05.49dlibhinesley, this is my cmake line: http://pastebin.com/hrXWMCZn
21:08.52bhinesleyhmm... starseeker may have to take a look at that one
21:09.24bhinesleyis just a student
21:09.30dlibhinesley, I know he started the cmake branch
21:09.55bhinesleyyep, he's your man
21:10.54dlibhinesley, also, I have to tweak CMakefile.txt a little bit: http://paste.pocoo.org/show/438902/
21:11.47bhinesleyodd
21:13.33bhinesleywhat is there currently: http://pastebin.mozilla.org/1272356
21:13.48*** join/#brlcad mafm (~mafm@247.Red-83-38-35.dynamicIP.rima-tde.net)
21:14.12dlibhinesley, current some ${${path_label}_LABEL} contain space within
21:15.11dlibhinesley, therefore, sending more than two arguments to LENGTH, and break cmake
21:15.57bhinesleyyeah, I misread, your original is identical to the current revision
21:17.35bhinesleyI won't waste your time: I wouldn't know how to fix it.
21:18.03dlibhinesley, don't worry :)
21:34.56dlibhinesley, seems to be something wrong with make configure line, it builds now
21:39.11bhinesleycan you show me what you changed it to?
21:42.32dlibhinesley, sure
21:44.52dlibhinesley, http://paste.pocoo.org/show/438926/
21:45.10dlibhinesley, I guess the incorrect PREFIX broke it
21:53.20bhinesleydli: yeah I see that there there is no DCMAKE_PREFIX in your correct version, but there are two DCMAKE_INSTALL_PREFIX's
21:53.28bhinesleyer, working version
21:53.46bhinesleyer DBRLCAD_PREFIX I mean
21:55.27dlibhinesley, it's okay, one instance is always added by the gentoo script, the second one overrides it
21:56.55bhinesleynods
21:59.28dli^[[0m[ 98%] Built target step-g
21:59.28dlimake: *** [all] Error 2
21:59.32dlino luck :(
21:59.45bhinesley:-/
22:00.04dlibhinesley, can I disable step-g ?
22:00.33dlibhinesley, it says 'built', so it's not step-g
22:11.40brlcadmake VERBOSE=1
22:11.55dlibrlcad, doing that now
22:16.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
23:30.57``Eriknotes that --no-undefined is not a recognized option on some of his compilers O.o (like the mac)
23:54.34*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
23:56.29*** join/#brlcad kunigami__ (~kunigami@201.53.206.27)
23:57.00starseeker``Erik: yeah, need to test for that somehow or other
23:59.36starseekerdli: "usr" is still a really bad value for CMAKE_INSTALL_PREFIX
23:59.53starseekeralso, you don't need to set BRLCAD_PREFIX any more - it's just an interal thing now
IRC log for #brlcad on 20110715

IRC log for #brlcad on 20110715

00:00.14dlistarseeker, yes, I figured it out by trying brutal force :(
00:00.33starseekersorry - been busy
00:00.48dlistarseeker, how do I add LDFLAGS for itcl and itk? still broken after 98% built
00:01.24starseekergrowl.  pastebin?
00:02.03dliusr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -litcl
00:02.35starseekerum - are you using system itcl or the local one?
00:02.46dlistarseeker, and itcl is at: /usr/lib64/itcl3.4/libitcl3.4.so , using system one
00:03.54starseekerwhat does your CMakeCache.txt say for ITCL_LIBRARY?
00:03.57dlistarseeker, do I need CMAKE_LINK_FLAGS or could it auto detect system itcl/itk
00:04.16starseekerI thought I had set up detection for Itcl/Itk
00:04.43dlistarseeker, grep ITCL_LIBRARY CMakeCache.txt found nothing
00:04.47starseekerI seldom build with system libs, so it's possible the Find* logic for Itcl/Itk isn't functioning quite right
00:05.09starseekerhmm - you do have a CMakeCache.txt file?
00:05.18dlistarseeker, grep ITCL found something: http://paste.pocoo.org/show/439032/
00:06.17starseekerhmm - so the question is what the find routines are doing
00:08.05dlistarseeker, for the time being, I will try CMAKE_LINK_FLAGS
00:09.19starseekerIf the find routines were working, you wouldn't be getting itcl
00:10.04dlistarseeker, do you mean be getting itcl/itk trouble?
00:10.17CIA-62BRL-CAD: 03starseeker * r45496 10/brlcad/trunk/CMakeLists.txt: Quote some path strings for robustness - need more testing of the logic with spaces and other unfriendly characters paths
00:10.31starseekerdli:  I'm assuming your using system Tcl/Tk?
00:10.40dlistarseeker, yes
00:11.04starseekerdli: what happens if you just run cmake without forcing off libraries?
00:11.18starseeker(i.e what does the summary report at the end?)
00:11.28starseekerit will try to use system libraries if it can find them by default
00:11.53dlistarseeker, I will try that later, it's building with CMAKE_LINK_FLAGS now :( slow core2duo
00:12.12starseekerk - if it's not using system Tcl/Tk, there's probably a reason
00:12.34starseekerforcing system lib usage when the cmake logic doesn't select them by default is problematic
00:12.49starseekerif the cmake logic is doing its job, it is rejecting them for a reason
00:13.31dlistarseeker, summary of report: http://pastebin.com/AkxGVSdZ
00:14.07starseekerand your CMakeCache.txt file still doesn't have ITCL_LIBRARY?
00:15.10dlistarseeker, no, still no ITCL_LIBRARY
00:17.04starseekerOH.  I know what's going on
00:17.14starseekerthis is a consequence of switching back to using the Itcl/Itk C API
00:17.45dlistarseeker, so, I probably need a patch for 7.20.2
00:17.59starseekerI had changed things so that we were simply doing package require Itcl where needed - brlcad got a report of some breakage somewhere
00:18.07starseekerI never could reproduce it
00:18.24starseekerdli: you might try the autotools build - that should still work
00:18.40dlistarseeker, already tested, it works
00:19.13dlistarseeker, I'm trying to make a gentoo ebuild for cmake building
00:19.14starseekerbrlcad: do you recall what the problem was with using package require and what the conditions were to reproduce the bug?  If it's a choice between fixing that bug and reworking the Itcl/Itk detection logic to find the C API I'd vote for fixing the bug
00:20.53starseekerdli: this isn't all that simple - the Itcl/Itk C headers require internal headers we can't count on from an installed system version
00:21.27dlistarseeker, but autotools still build it properly
00:21.43starseekerdli: yes, because all the necessary scary logic is already in there
00:22.09starseekerwe shouldn't actually need the Itcl/Itk C api at all - I yanked it out once, but there was a report of a bug
00:22.23starseekersomething about loading iwidgets twice IIRC, but I couldn't duplicate it
00:22.47dlistarseeker, I would love to see itcl/itk removed. :(
00:22.58starseekerdli: we can't remove it - it's used extensively
00:23.13starseekeronce we can just do "package require Itcl" it gets a lot easier
00:23.52starseekerThe Tcl/Tk headers are horrible about API separation - lots of extensions need access to "internal" headers just to build
00:24.06dlistarseeker, for the time being I can force local building of itcl/itk, seems to be a workaround
00:24.14starseekerdli: yeah, that should work
00:24.29starseekeralthough if you're doing a gentoo ebuild they'll never go for it
00:25.12dlistarseeker, let me try ;(
00:28.26dlistarseeker, I have to enable tcl/tk local building, not simply itcl/itk, right?
00:28.40starseekerum.  You can try just itcl/itk
00:28.58starseekernot sure if that'll fly without the tcl/tk internal headers, but you can give it a shot
00:29.28dlistarseeker, no such flag ITCL/ITK in CMakeLists.txt
00:29.44starseeker-DBRLCAD_BUILD_LOCAL_ITCL=ON
00:29.55starseeker-DBRLCAD_BUILD_LOCAL_ITK=ON
00:29.57starseekertry those
00:32.24kunigami__Is there any way I can get the identifier of a thread in a sh_xyz code?
00:33.14dlistarseeker, no, no effect, cmake still found system itcl/itk
00:33.25starseekerone sec...
00:34.12starseekercrud - yeah, you may need to enable tcl/tk then
00:34.37starseekerI was probably thinking a "sane" Itcl/Itk build couldn't depend on a system tcl/tk install having what it needed anyway
00:37.07kunigami__This identifier should be passed along application and probably set at do_pixel
00:37.28starseekerkunigami__: sorry, that's a little outside my expertice
00:40.09starseekerdli: the only reason we can even "mix" system Tcl/Tk and local package builds in the old autotools setup is due to our logic supplying our own local include directories in src/other to the builds of those extensions that need them
00:40.11dlistarseeker, still no luck, cmake still found system tcl/tk/itcl/itk
00:40.36kunigami__starseeker: no problem :) I'm just thinking aloud to see if I can get some feedback
00:40.36kunigami__]
00:40.48starseeker-DBRLCAD_BUILD_LOCAL_TCL_FORCE=ON
00:41.11starseekeror rather -DBRLCAD_BUILD_LOCAL_TCL_FORCE_ON=ON
00:44.02dlistarseeker, yes, FORCE_ON does the trick
00:54.41kunigami__<PROTECTED>
00:59.19CIA-62BRL-CAD: 03starseeker * r45497 10/brlcad/trunk/CMakeLists.txt: Comment out the --no-undefined linker option until I figure out how to test it.
01:17.15kunigami__thanks :)
01:18.09dlistarseeker, yes, with FORCE_ON, it builds properly. Thanks
01:19.28starseekerdli: no problem
01:23.44CIA-62BRL-CAD: 03kunigami * r45498 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): changing OSLRender methods to static. I think this will be necessary to increase parallelism
02:28.22bhinesleyWhen I have argc > 1 and my command returns GED_HELP, Archer prints the error "No ledger entry found for help." What am I missing?
02:28.48bhinesleyin that case, argv[2] was help
02:29.41bhinesleyexcuse me, argv[1] was help
02:37.16CIA-62BRL-CAD: 03bhinesley * r45499 10/brlcad/trunk/include/ged.h: moved ged_edit to more appropriate place
02:43.55CIA-62BRL-CAD: 03bhinesley * r45500 10/brlcad/trunk/src/ (8 files in 3 dirs): Validate subcommand names, add ged_edit stuff to a few places I missed before, cleanup.
02:45.58CIA-62BRL-CAD: 03bhinesley * r45501 10/brlcad/trunk/src/libged/edit.c: quiet compiler warning about unused variable
02:52.13*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
03:12.36brlcadkunigami__: libbu's parallelism passes the cpu/thread id to the worker callback
03:12.54brlcadfor rt, that's the worker() function in src/rt/worker.c, which in turn calls do_pixel() with the cpu
03:13.44brlcadthe application struct's a_resource is then set to a cpu-specific resource structure safe for that thread to use without blocking
03:14.18brlcadwhy you'd need to know that is a bit of a mystery, though ... :)
03:15.28brlcadbhinesley: I'm not sure what archer was set up to use, but it may be pulling help from src/tclscripts/helplib.tcl and/or src/tclscripts/help.tcl  ... old help interface
03:15.59brlcadthe modular command refactoring that I started is the beginnings of making those obsolete
03:16.57bhinesleybrlcad: that was sort of a bad example. It prints "No ledger entry found for <whatever argv[1] is>"
03:17.42bhinesleyassuming that I return GED_HELP
03:18.09brlcadboth mged and archer tell you that or just archer?
03:18.13bhinesleyjust archer
03:19.36bhinesleyyou weren't kidding... there really are a lot of places to make changes when you add a command
03:19.52*** join/#brlcad dli (~dli@dsl-69-172-83-119.acanac.net)
03:21.46brlcadyeah, it's really terrible
03:22.23brlcad15 years of a very active dev not doing hardly any proper refactoring, at least not for the DRY principle
03:24.17brlcadpart of the problem is that even with a clean refactoring towards libged, a silly route was taken to make it fit the existing archer interface .. once again needing to repeat all commands
03:24.43brlcadall of the *_obj.c files should be killed, but that's a refactoring task in itself -- feel free to tackle any and all of them
03:25.46bhinesleynods
03:25.55bhinesleydefinitely no lack of things to do
03:31.53brlcadhe's also like the 3rd or 4th most experienced tcl dev on the planet (at least as measured by ohloh), so (for him) he's very adept wandering around the bowels of mged and archer
03:32.14brlcadsort of has his own perspective on maintainability
03:34.02bhinesleyis he ever in here?
03:34.12bhinesleyor lists only?
03:37.52brlcadmostly mailing list
03:38.08brlcadso that ledger issue, more replication crap
03:38.36brlcadand it's not code I really understand, so can't be of much help -- might make a good mailing list question if you have any
03:38.42bhinesleyalright, well, it's not inhibiting the functionality of the command, so I won't worry about it right now
03:39.00brlcadtclscripts/archer/Archer.tcl  AND  tclscripts/archer/ArcherCore.tcl .. both list commands for some reason
03:39.19brlcadI presume if you don't list the command that it's calling some generic wrapper, and pulling the wrong argv for your command or something
03:39.54bhinesleylooks into this
03:40.07bhinesleyhey, ohloh is pretty neat
03:40.10bhinesleyjust now checking it out
03:40.17brlcadreally? :)
03:40.33brlcadhttp://www.ohloh.net/p/brlcad
03:41.37bhinesleyfirst thing I did was search for brlcad ;-)
03:51.20bhinesley96 commits... hm... I'd better step it up a notch
03:59.40brlcadadd two orders of magnitude and you'll be in the #3 spot ;)
03:59.59brlcadthat's like two years
04:11.19CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3008 10/wiki/Non-vacuum_gravity_simulator: missing paren
04:20.37CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3009 10/wiki/Celestial_mechanics_particle_system: link to some 3rd party libs
04:21.08CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3010 10/wiki/Non-vacuum_gravity_simulator:
04:41.35*** join/#brlcad dli (~dli@67.55.33.66)
07:09.17*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
07:10.29*** join/#brlcad merzo (~merzo@193.254.217.44)
07:12.14*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
07:12.56*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
07:16.23*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
08:02.47*** join/#brlcad merzo (~merzo@193.254.217.44)
09:10.01*** join/#brlcad mafm (~mafm@120.Red-83-42-153.dynamicIP.rima-tde.net)
09:18.18*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:56.23kunigami__brlcad: it seems I need to set different vars for each thread when first calling OSLRender and I dont know how to do that without an identifier for each thread.
10:08.14kunigami__unless I initialize OSLRender right in do_pixel
11:02.51*** join/#brlcad dli (~dli@67.55.33.66)
11:20.07*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:39.20*** join/#brlcad __name__ (~name@sburn/devel/name)
11:47.31*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:13.20*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
14:05.29*** join/#brlcad dli (~dli@66.49.183.65)
14:50.42brlcadkunigami__: you could use the address of the struct resource in the application struct -- that is unique per process/thread
15:12.05*** join/#brlcad mafm_ (~mafm@120.Red-83-42-153.dynamicIP.rima-tde.net)
16:47.47*** join/#brlcad __name__ (~name@chello080108038152.1.11.vie.surfer.at)
16:47.47*** join/#brlcad __name__ (~name@sburn/devel/name)
17:11.42__name__Hello! I've been reading your SOCIS projects and would be interested whether there are any tools of preference for the web applications (language, DB, whether it's supposed the be ajaxy, etc.)
17:21.48CIA-62BRL-CAD: 03r_weiss * r45502 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
17:21.48CIA-62BRL-CAD: Updated the prototype version of function cut_unimonotone within file nmg_tri.c.
17:21.48CIA-62BRL-CAD: This function supports the prototype version of function nmg_triangulate_fu.
17:21.48CIA-62BRL-CAD: These prototype functions are disabled by default. This is a work is progress.
17:21.48CIA-62BRL-CAD: Changed the test for an infinite loop and added more error checking. Also did
17:21.49CIA-62BRL-CAD: code cleanup.
18:11.18*** join/#brlcad name (~name@sburn/devel/name)
18:34.55brlcadhello __name__
18:35.45brlcad__name__: there isn't a strong preference, but something that works for most users, is easy to install and maintain, and does the job best
18:36.16brlcadcurrent website is a drupal+mediawiki combo
18:46.45*** join/#brlcad DarkCalff (DC@173.231.40.98)
18:48.44CIA-62BRL-CAD: 03erikgreenwald * r45503 10/brlcad/trunk/src/libged/edit.c: Clean up C90 warning on some compilers.
19:12.08CIA-62BRL-CAD: 03r_weiss * r45504 10/brlcad/trunk/src/irprep/ (Compile.sgi Makefile.am): sgi files are gone in irprep - let the Makefile.am know about it.
19:34.37*** join/#brlcad epileg (~epileg@188.119.210.222.dynamic.eurona.net)
19:34.41*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
19:40.22*** join/#brlcad indianlarry (~indianlar@BZ.BZFLAG.BZ)
19:50.42brlcadwootness
20:35.14starseekerbrlcad: hmm?
20:35.30__name__brlcad: Well you cannot really base a benchmark web-UI on either of those.
21:08.37CIA-62BRL-CAD: 03r_weiss * r45505 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
21:08.37CIA-62BRL-CAD: Updated the prototype version of the function nmg_triangulate_fu within file
21:08.37CIA-62BRL-CAD: nmg_tri.c. This function is disabled by default. This is a work is process. The
21:08.37CIA-62BRL-CAD: majority of the changes were code cleanup. Added logic to prevent unnecessary
21:08.37CIA-62BRL-CAD: processing of already triangulated faceuse.
21:09.19CIA-62BRL-CAD: 03starseeker * r45506 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Clang likes to complain about unused command line arguments, and we don't really care.
21:19.19starseekerfirst crack at building BRL-CAD with clang/clang++ in XCode 4:  http://pastebin.mozilla.org/1272704
21:19.45brlcad__name__: sure you could -- I could make plain html work too
21:19.50brlcadall in the design
21:20.02brlcaddoesn't mean you're constrained to those, just saying what's already handy
21:20.08starseekerdoesn't know enough about why those externs are there to know if they are still needed...
21:20.09__name__brlcad: Doesn't sound like a good idea though.
21:20.21brlcadthat's a different statement ;)
21:20.31__name__(Generating pure HTML.)
21:21.05brlcadbig difference between "cannot" and "not a good idea" ;)
21:21.15__name__brlcad: Fair point.
21:21.20brlcadyou have a windows build handy?
21:21.29brlcadsry, starseeker: http://pastebin.mozilla.org/1272704
21:21.38brlcadbah .. starseeker: you have a windows build handy?
21:23.13__name__brlcad: Anyway. I'd be happy to do the web-application (or any other not-too-physics-heavy task).
21:24.12starseekerbrlcad: not at the moment - problem?
21:24.13brlcadstarseeker: huh, interesting warnings .. apparently llvm thinks that declarations can shadow declarations
21:24.34starseekerliboptical isn't happy either:  http://pastebin.mozilla.org/1272706
21:25.16brlcadstarseeker: the good news is that those are just duplicate decls and llvm can help weed them out
21:25.49brlcadjust remove the redundant duplicate
21:26.32brlcadstarseeker: and no, not a problem -- I just have an implementation of fchmod() for Windows that will likely break the Windows build, need someone to test
21:26.51starseekerah
21:27.25starseekeryeah, probably would take me at least an hour or so to kick my Windows build back into gear
21:28.47CIA-62BRL-CAD: 03starseeker * r45507 10/brlcad/trunk/src/ (libfb/fb_generic.c librt/tcl.c): remove duplicate decls (XCode 4 clang no likie)
21:28.54starseekerbounces over to the Windows box...
21:29.09starseekerbrlcad: whats the MFUNCS thing all about?
21:29.31brlcadhold a sec, looking
21:31.26CIA-62BRL-CAD: 03brlcad * r45508 10/brlcad/trunk/src/libbu/fchmod.c:
21:31.26CIA-62BRL-CAD: implement fchmod() for Windows. this will likely break the Windows build, but
21:31.26CIA-62BRL-CAD: committing it since the only issue should be minor header and preprocessor
21:31.26CIA-62BRL-CAD: symbolage. in order to implement fchmod on Windows, we rely on chmod() instead
21:31.26CIA-62BRL-CAD: which is available but requires a filename. this is normally not knowable, but
21:31.27CIA-62BRL-CAD: windows provides a roundabout way to get it, so run with it.
21:42.57CIA-62BRL-CAD: 03starseeker * r45509 10/brlcad/trunk/src/liboptical/sh_wood.c: duplicate declarations in sh_wood.c
21:47.28CIA-62BRL-CAD: 03r_weiss * r45510 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
21:47.28CIA-62BRL-CAD: Updated the prototype function nmg_plot_fu within file nmg_tri.c. This function
21:47.28CIA-62BRL-CAD: supports the prototype function nmg_triangulate_fu. These functions are disabled
21:47.28CIA-62BRL-CAD: by default. This is a work in process. The changes were code cleanup.
21:55.05CIA-62BRL-CAD: 03starseeker * r45511 10/brlcad/trunk/src/ (14 files in 10 dirs): Remove all non-liboptical shadowing warnings.
22:00.01starseekerah right, the optical/multispectral thing
22:02.06CIA-62BRL-CAD: 03starseeker * r45512 10/brlcad/trunk/src/liboptical/init.c:
22:02.06CIA-62BRL-CAD: Some of these MFUNCS are declared in the header for libmultispectral - for
22:02.06CIA-62BRL-CAD: those, don't do the extern struct part of the original MFUNCS macro. Add a
22:02.06CIA-62BRL-CAD: DMFUNCS macro for both the extern and the mlib_add shader call, and make MFUNCS
22:02.06CIA-62BRL-CAD: just do the mlib_add_shader bit.
22:04.04CIA-62BRL-CAD: 03starseeker * r45513 10/brlcad/trunk/src/fbed/fbed.c: f_Stop doesn't take any arguments
22:07.46CIA-62BRL-CAD: 03starseeker * r45514 10/brlcad/trunk/src/libmultispectral/init.c: Same trick for libmultispectral as for liboptical.
22:09.08*** join/#brlcad piksi (piksi@pi-xi.net)
22:10.57CIA-62BRL-CAD: 03starseeker * r45515 10/brlcad/trunk/src/gtools/beset/population.c: resp was unused here? Not really sure what the intent of that statement was.
22:11.47CIA-62BRL-CAD: 03starseeker * r45516 10/brlcad/trunk/src/rt/ (viewarea.c viewfrac.c viewpp.c): Some more duplicate declarations.
22:13.38brlcadstarseeker: MFUNCS is how each shader is registered with liboptical
22:13.53CIA-62BRL-CAD: 03starseeker * r45517 10/brlcad/trunk/src/lgt/do_options.c: More functions that don't take any arguments.
22:14.26brlcadthe problem is that a few shaders might have to be declared for libmultispectral, so some are declared in optical.h
22:14.56starseekerbrlcad: right - I had forgotten about that, something I think from the Windows build
22:14.59starseekerI got is straight
22:15.17brlcadthey shouldn't need to be declared in optical.h
22:15.21starseekerWoot!  clang build with XCode 4 finished
22:15.30brlcadsort of breaks the whole modularity DRY principle
22:17.42brlcadpretty cool, yay for portability
22:18.08starseekerbrlcad: what was the intent of that bset/population.c line I wonder?
22:29.50brlcadI don't see a beset line
22:34.05starseekerr45515
22:34.32starseekersvn diff -r45514:45515
22:40.52starseekerOuch
22:40.59starseekerbenchmark results:
22:41.07starseekerclang vgr:  13540
22:41.21starseekergcc vgr:  14944
22:41.30starseeker(debug builds in both cases)
22:47.05``Erikoptimized?
22:47.12starseeker``Erik: working on it now
22:49.14starseekerbrlcad: fchmod.c Windows build failures:  http://pastebin.mozilla.org/1272750
23:03.53CIA-62BRL-CAD: 03starseeker * r45518 10/brlcad/trunk/src/mged/utility1.c: clang is reporting these as unused. Looks like this is part of the stuff that has moved to libged - nuke.
23:16.46starseekergcc vgr (optimized): 33425
23:18.01starseekercan already tell the clang results will be slower
23:20.45*** join/#brlcad webmaster (~webmaster@93-152-34-168.xln.managedbroadband.co.uk)
23:30.26starseekerclang vgr (optimized): 30409
23:30.56starseekersigh.  Oh, well - at least it's a useful tool for debugging - I like the error messages
IRC log for #brlcad on 20110716

IRC log for #brlcad on 20110716

02:00.11CIA-62BRL-CAD: 03bhinesley * r45519 10/brlcad/trunk/src/libged/edit.c: (log message trimmed)
02:00.11CIA-62BRL-CAD: Changed the way that commands are added/stored, to use an array of structs
02:00.11CIA-62BRL-CAD: similar to other command lists in BRL-CAD; much better. Set up ged_edit so that
02:00.11CIA-62BRL-CAD: it behaves like a wrapper when the command name is not a ged_edit subcommand.
02:00.11CIA-62BRL-CAD: Otherwise, when the command name is a ged_edit subcommand, it behaves as if it
02:00.11CIA-62BRL-CAD: were the only command available. The syntax for some of the subcommands is
02:00.11CIA-62BRL-CAD: pretty intense, so I also implemented a help system that displays the expanded
03:59.48*** join/#brlcad ibot (~ibot@rikers.org)
03:59.48*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 being tagged today (20110701) || BRL-CAD has applied to participate in the ESA Summer of Code in Space!
04:00.56CIA-62BRL-CAD: 03brlcad * r45520 10/brlcad/trunk/src/libbu/fchmod.c: fix a variety of minor build issues that came up during compilation testing. thanks starseeker!
04:02.48brlcadstarseeker: ah, that resp just looks like a typo.  probably never noticed because it's doesn't affect anything.
04:03.22brlcadresp is a resource pointer, so probably was being typed to get passed to some function
04:58.26*** join/#brlcad indianla1ry (~indianlar@BZ.BZFLAG.BZ)
06:15.10*** join/#brlcad Stattrav (~Stattrav@117.192.148.223)
06:15.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:20.19starseekerbrlcad: do you recall what the issue was with using "package require Itcl" instead of the C api?
06:21.02starseekerI'd really like to get that straight so I don't have to muck up the src/other build logic for the system tcl/tk local itcl/itk case...
06:40.47*** join/#brlcad Stattrav_ (~Stattrav@117.192.139.74)
06:45.48*** join/#brlcad Stattrav (~Stattrav@117.202.31.116)
06:45.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:11.38*** join/#brlcad Stattrav_ (~Stattrav@117.192.154.180)
08:23.48*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:08.01*** join/#brlcad dli (~dli@66.49.183.65)
10:31.16*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:42.16CIA-62BRL-CAD: 03brlcad * r45521 10/brlcad/trunk/ (5 files in 2 dirs): renamed stat.c to file.c in order to reflect the API supporting more than determining whether a file exists and stat-style permissions info.
10:44.20CIA-62BRL-CAD: 03brlcad * r45522 10/brlcad/trunk/src/libbu/file.c: don't need _bu_ prefix on HIDDEN funcs, use file prefix.
10:47.22*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
10:47.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:48.29brlcadstarseeker: I do not recall other than it being related to packages being rather mucked up with double inclusions and runtime failures
10:50.07brlcadI don't think the problem is understood well enough at this point given it seems to only either work with autotools or cmake build but not both as a package require .. something isn't right
10:51.33brlcadgiven a choice between always failing autotools and sometimes failing cmake with the right build options, we'll still need to keep both working until the deprecation timeframe is over
10:53.05brlcadthe underlying issue needs to be understood, should be working for both build systems (*especially* the package require approach, that's why it has fewer warm fuzzies that it's right)
11:06.12``Erikhm, xcode4 still requires a an ios/mac paid dev acct :/
12:19.17*** join/#brlcad KimK_afk (~Kim__@209.248.147.2.nw.nuvox.net)
12:27.07*** join/#brlcad name (~name@chello080108038152.1.11.vie.surfer.at)
12:27.07*** join/#brlcad name (~name@sburn/devel/name)
13:18.25*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
13:18.25*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:23.41*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
15:11.57*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
15:33.41*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
17:00.49*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
19:59.38*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
20:16.37*** join/#brlcad Stattrav (~Stattrav@117.192.133.54)
20:16.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:39.44*** join/#brlcad Stattrav_ (~Stattrav@117.192.136.248)
20:55.43*** join/#brlcad Stattrav (~Stattrav@117.192.136.210)
20:55.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
23:48.14*** part/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
IRC log for #brlcad on 20110717

IRC log for #brlcad on 20110717

01:53.12*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:36.30*** join/#brlcad __name__ (~name@bitsrc.org)
04:42.03*** join/#brlcad DarkCalf (DC@173.231.40.98)
10:07.22*** join/#brlcad merzo (~merzo@165-40-132-95.pool.ukrtel.net)
10:09.50*** join/#brlcad merzo (~merzo@165-40-132-95.pool.ukrtel.net)
10:18.59*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:42.14merzoI'm trying to get sources via svn but get an error:
10:42.17merzoChecksum mismatch: src/other/tkimg/Makefile.am
10:42.17merzoexpected: daed4d060f148304dad5b5f7bba69966
10:42.17merzo<PROTECTED>
10:42.25merzoon revision 30755
10:45.36merzoguys how to solve it?
10:51.15merzoprobably I can ignore this broken revision?
11:07.48*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
11:07.48*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:15.12*** join/#brlcad __name__ (~name@sburn/devel/name)
12:17.02*** join/#brlcad __name__ (~name@sburn/devel/name)
12:57.49brlcadmerzo: what is your checkout line?
12:58.02brlcadsuggest just "try again", maybe some network hiccup
13:02.22brlcadhttp://stackoverflow.com/questions/6130/repair-svn-checksum
13:02.36brlcadbasically you can rm -rf src/other/tkimg then svn update again, should work
13:26.39*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
13:54.07``Erikhuh, this X install has variatic macros in the X headers, causing libdm to fail due to iso strictness
14:35.07*** join/#brlcad merzo (~merzo@37-236-132-95.pool.ukrtel.net)
17:53.10*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
17:58.56*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
23:33.44CIA-62BRL-CAD: 03brlcad * r45523 10/brlcad/trunk/include/optical.h:
23:33.44CIA-62BRL-CAD: FIXME, should not need to declare all liboptical shaders used by
23:33.44CIA-62BRL-CAD: libmultispectral. in theory, multispectral can use all of them and having to
23:33.44CIA-62BRL-CAD: list shaders in three places really sucks. could give multispectral a prefix or
23:33.44CIA-62BRL-CAD: suffix so it's a different var, but they shouldn't even be globals.
IRC log for #brlcad on 20110718

IRC log for #brlcad on 20110718

00:49.38*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
01:23.33*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
03:06.57brlcadFYI, we're now within a sagonet maintenance window for the next 6 hours
03:07.25brlcadsry, next 7 hours (till 6am edt)
03:07.35brlcaddowntime shouldn't exceed 20min, but will be any time in that window
03:08.00brlcadrack in datacenter is being moved
03:47.22brlcadstarseeker: where are the functions listed in configure.ac, section 7, getting checked in the CMake build logic?  can't find them
04:04.51brlcadhope the answer isn't what it's looking like ... that'd be a lot of useful functionality falling back to dumb defaults
05:03.05*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
05:58.34*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
05:58.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:14.17*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
07:20.06*** join/#brlcad merzo (~merzo@193.254.217.44)
07:24.46*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
11:05.18*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:25.40*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:45.13CIA-62BRL-CAD: 03brlcad * r45524 10/brlcad/trunk/BUGS:
14:45.13CIA-62BRL-CAD: rt run from within mged (and probably also within archer, but untested) doesn't
14:45.13CIA-62BRL-CAD: output anything other than the final success/failure message from libged.
14:45.13CIA-62BRL-CAD: something is suppressing all output, which doesn't seem to have been intentional
14:45.13CIA-62BRL-CAD: (undocumented).
14:58.33brlcadheh, new server was rebooted, but apparently the firewall was turned on (without any rules, defaulting to block everything)
15:02.02*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
15:03.58``ErikI was able to log into it about 20 minutes ago O.o
15:04.26``Eriksure ya got the right IP? a lot of stuff pointing to the 'new' server is pointing to the 'old' 'new' server, like the crit domain name
15:06.11``Erik(or was that fixed before I logged in at 10:41?)
15:09.44brlcadI got it fixed a couple hours ago
15:09.54brlcadipfw is turned off at the moment
15:12.04``ErikI think I tried to set up the auto-deny script you had, I may've munged it up
15:12.10``Erikwas a while back *shrug*
15:12.14brlcadnp
15:13.10``Erikwith the reboots, might be prime time to expediate the migration
15:13.37brlcadi've been actively trying for some time now
15:15.31brlcadthinks brep plot just might be stuck in an infinite loop... been trying to plot an 800-object model for over an hour now
15:16.01``ErikI think I've installed all the right ports, it's the config that might need work *shrug* you have some businesses using it and I don't want to risk their revenue *shrug* :)
15:16.23``Erikshrugs himself to the kitchen to do some dishes
15:16.29*** join/#brlcad merzo (~merzo@193.254.217.44)
15:29.59``ErikHAH, apple releases an ios update to prevent jailbreaking and it's broken almost immediately, only a 12hr gap in the slapsnot stories, nice
15:42.15louipcjajajaja
15:45.18``Eriknice spin, the update notes say "Fixes security vulnerability associated with viewing malicious PDF files."
15:45.42``Erik(the jailbreak uses a flaw in the pdf render stack)
15:45.49starseekerbrlcad: Um - do you mean the AC_CHECK_FUNCS list on line 4506 of configure.ac?
15:46.29starseekercorrection, line 2262
15:46.54starseekersimilar tests are in CMakeLists.txt starting at line 1096
15:49.21``Erikhm, liboptical throws a slew of warnings, %d fed an int instead of a long int
16:26.54brlcadstarseeker: aha! thanks ... I'd grepped down the source tree and into misc/ but apparently not the top-level CMakeLists.txt file
16:27.38brlcaddo think this brep plot is in an inf loop .. damn
16:34.14starseekercrud - it is a debug build?
16:35.04brlcadshould be
16:35.54brlcadcould also just be insancely slow, but it's been 2-3 hours
16:36.37brlcadhttp://pastebin.mozilla.org/1274946
16:42.45brlcadlets it keep churning for now
16:43.29brlcadstack does keep changing, at least up to plot_BBNode, so if it's an inf loop, it's fairly complex or at the plot_BBNode level
16:49.39starseekeryipe
16:55.44CIA-62BRL-CAD: 03starseeker * r45525 10/geomcore/trunk/CMake/FindCppUnit.cmake: Don't use FATAL_ERROR when checking for CppUnit - it's not essential.
17:12.14``Erikmac? fbsd? attach pid to process to see what it's doing?
17:12.30``Erikshark, truss, uh, I think linux strace or ktrace may do something
17:12.39brlcadnifty, rt crash on nurbs raytrace
17:13.04``Erikor winderz, attach msvc debugger to process, pheer
17:13.12brlcadthat is attached, did watch .. hence my comments about the "stack does keep changing"
17:13.35``Erikaight, then it's doing something, but could be an infinite loop *shrug*
17:14.00``Erikstop occasionally and record the stack dump?
17:14.12brlcadof course
17:14.12``Erikif they don't change, it might be infinite
17:14.27brlcadblinks
17:14.33brlcadI feel like a broken record
17:14.41``Eriksrry, just got back from exercising and showering, brain isn't quite right
17:14.57``Erik<-- playing the captain obvious role, it usually helps *shrug* :)
17:14.57brlcadexerwhaat?  you okay?
17:15.16brlcadhit you head and stumble into the gym by accident?
17:15.27``Eriknah, walking/jogging a trail in the heat
17:15.48``Erikya sure it's plugged into the wall? is the power on? :>
17:16.42``Erikan infinite loop in the opennurbs stuff would be an interesting find, indianlarry is pretty good at what he does and I doubt the originators would not have noticed such a thing
17:17.09``Erikslow, yes, infinite... not highly probable
17:19.22``Erikbrlcad: is MoRe the right place to dump works in progress for critique?
17:20.43``Erikhah, guess they're moving that rack now
17:21.11CIA-62BRL-CAD: 03starseeker * r45526 10/geomcore/trunk/tests/func/GE/CMakeLists.txt: Hmm - don't think we need CPPUNIT_INCLUDE_DIR here? Not in unit directory in any case...
17:27.33CIA-62BRL-CAD: 03starseeker * r45527 10/geomcore/trunk/tests/func/svntest/main.c: Sync up with macro API cleanup in r45032
17:37.45*** join/#brlcad Stattrav (~Stattrav@117.202.20.234)
17:37.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:42.41*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
18:32.35*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
18:32.48brlcadlooks like sagonet borked a router
18:33.32brlcadmaybe someone kicked the power cord right as you were mentioning it, otherwise, last msg received was 13:17 local
18:34.07brlcadI've narrowed it down to a single brep primitive .. looking very likely that it's infinite
18:44.53*** join/#brlcad Stattrav_ (~Stattrav@117.202.20.234)
18:49.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:11.17*** join/#brlcad Stattrav (~Stattrav@117.202.20.234)
19:11.17*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:18.59*** join/#brlcad Stattrav (~Stattrav@117.202.20.234)
19:19.00*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:26.23*** join/#brlcad Stattrav (~Stattrav@117.202.20.234)
19:26.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:32.59*** join/#brlcad Stattrav (~Stattrav@117.202.20.234)
19:32.59*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:49.07*** join/#brlcad Stattrav (~Stattrav@117.202.20.234)
19:49.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:00.18*** join/#brlcad yaadam (~chatzilla@188.147.8.128.nat.umts.dynamic.t-mobile.pl)
20:02.26*** join/#brlcad yaadam (~chatzilla@188.147.8.128.nat.umts.dynamic.t-mobile.pl)
20:03.18yaadamWhat, about list of accept Logo BrlCAD ?
20:06.11yaadamI want to :-D see a gallery work of logo - I send a one.
20:09.19yaadamOr just you wait to deadline of logo Competition?
20:09.35yaadamAnd then show all send work?
20:09.42yaadamright :-) ?
20:13.22CIA-62BRL-CAD: 03kunigami * r45528 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): added support to multi-thread using the OSL cocept of thread_info (hope I get it right :P) preliminary tests show a decrease in the time needed to render an example image when going from 1 to 2 processors
20:23.39CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r3011 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ added report for last week
20:23.59CIA-62BRL-CAD: 03bhinesley * r45529 10/brlcad/trunk/src/libged/edit.c: comment detailing how ged_edit will handle standardized and unique (unrecognized) subcommand options/args in a generic way, without requiring changes when a new command is added. Spellchecked file.
20:55.35CIA-62BRL-CAD: 03bhinesley * r45530 10/brlcad/trunk/include/bu.h: typo
21:20.01brlcadpatience yaadam
21:21.54kunigami_seems he didn't have patience even to wait for a response :)
21:23.10*** join/#brlcad yaadam (~chatzilla@188.147.8.128.nat.umts.dynamic.t-mobile.pl)
21:23.29CIA-62BRL-CAD: 03r_weiss * r45531 10/brlcad/trunk/src/libbn/plane.c:
21:23.29CIA-62BRL-CAD: Created a new prototype version of function bn_isect_line_lseg in the libbn
21:23.29CIA-62BRL-CAD: library within file plane.c. This new version is disabled by default and exists
21:23.29CIA-62BRL-CAD: to support the prototype version of nmg_triangulate_fu. The changes to this
21:23.29CIA-62BRL-CAD: function were necessary to process the output from the prototype function
21:23.30CIA-62BRL-CAD: bn_isect_line3_line3_new. This is a work in progress.
21:37.10CIA-62BRL-CAD: 03brlcad * r45532 10/brlcad/trunk/ (NEWS src/librt/opennurbs_ext.h):
21:37.10CIA-62BRL-CAD: fixed a bug in NURBS plot where it was getting stuck in an infinite loop due to
21:37.10CIA-62BRL-CAD: hitting an edge case where our v estimate for a given u was _exactly_ hitting
21:37.10CIA-62BRL-CAD: the test point causing subsequent tests to repeatedly test the same point over
21:37.10CIA-62BRL-CAD: and over. this edge case is actually a happy done-with-function case so we can
21:37.10CIA-62BRL-CAD: just return the precise v value.
21:40.27CIA-62BRL-CAD: 03brlcad * r45533 10/brlcad/trunk/src/librt/opennurbs_ext.h: add another subtle change in case the == case ever gets removed, swap the logic so that the <= case will cause the comparison to clamp correctly to the singular point (and further prevent the inf loop).
22:00.47*** join/#brlcad yAdam (~chatzilla@178.180.65.32.nat.umts.dynamic.t-mobile.pl)
22:12.26CIA-62BRL-CAD: 03kunigami * r45534 10/brlcad/trunk/src/liboptical/init.c: osl_mfuncs should be included on DMFUNCS too
22:27.18*** join/#brlcad yAdam (~chatzilla@178.180.65.32.nat.umts.dynamic.t-mobile.pl)
22:56.18*** part/#brlcad yAdam (~chatzilla@178.180.65.32.nat.umts.dynamic.t-mobile.pl)
IRC log for #brlcad on 20110719

IRC log for #brlcad on 20110719

01:44.54CIA-62BRL-CAD: 03kunigami * r45535 10/brlcad/trunk/src/other/ (4 files in 3 dirs): Added cmakefile to compile the .osl shaders into .oso ones. This is done only if the OSL flag is enabled
02:03.23CIA-62BRL-CAD: 03kunigami * r45536 10/brlcad/trunk/src/liboptical/sh_osl.cpp: changed sh_osl to read shaders from ../shaders instead of ./
02:17.17CIA-62BRL-CAD: 03bhinesley * r45537 10/brlcad/trunk/src/libged/edit.c: adding generic subargument handling to ged_edit; it's a work in progress. incomplete sections are disabled
02:30.37CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3012 10/wiki/User:Bhinesley: /* Log */ wrong month on a few dates
02:33.00CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3013 10/wiki/User:Bhinesley: /* Log */ overwrote a couple dates last change
02:53.22CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3014 10/wiki/User:Bhinesley: /* Log */ catching up
03:04.46CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3015 10/wiki/User:Bhinesley: /* Log */ cross out completed items
03:57.06*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
04:38.51*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
05:53.12*** join/#brlcad poolio (~poolio@BZ.BZFLAG.BZ)
07:14.06*** join/#brlcad merzo (~merzo@193.254.217.44)
07:57.17*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:34.05*** join/#brlcad yAdam (~chatzilla@188.147.179.132.nat.umts.dynamic.t-mobile.pl)
10:09.28*** join/#brlcad yAdam (~chatzilla@188.147.201.90.nat.umts.dynamic.t-mobile.pl)
10:15.46*** join/#brlcad yAdam (~chatzilla@188.147.201.90.nat.umts.dynamic.t-mobile.pl)
12:52.35*** join/#brlcad yAdam (~chatzilla@188.146.24.10.nat.umts.dynamic.t-mobile.pl)
13:03.29*** part/#brlcad yAdam (~chatzilla@188.146.24.10.nat.umts.dynamic.t-mobile.pl)
13:20.35CIA-62BRL-CAD: 03erikgreenwald * r45538 10/brlcad/trunk/src/libged/edit.c: #if0 some unused funcs marked HIDDEN, causes compile failure when debugging is disabled
13:41.09CIA-62BRL-CAD: 03brlcad * r45539 10/brlcad/trunk/ (include/bu.h src/libbu/file.c):
13:41.09CIA-62BRL-CAD: initial implementation of bu_file_delete() for removing files. performs a
13:41.09CIA-62BRL-CAD: simple remove() but then will try harder by relaxing the file permissions on a
13:41.09CIA-62BRL-CAD: second pass attempt if the first fails. untested on windows but remove() is c90
13:41.09CIA-62BRL-CAD: so we should be able to rely on it. callers will just have to make sure the
13:41.10CIA-62BRL-CAD: file isn't opened.
13:49.45*** join/#brlcad yAdam (~chatzilla@188.146.24.10.nat.umts.dynamic.t-mobile.pl)
13:49.58*** part/#brlcad yAdam (~chatzilla@188.146.24.10.nat.umts.dynamic.t-mobile.pl)
14:16.51*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) ||
14:16.58brlcadbah
14:17.34*** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
14:17.58brlcadall orgs get just one slot
14:18.48__name__shouldn't this have been announced yesterday?
14:19.56brlcadthey were a little late due to more submissions than they anticipated
14:20.17brlcadit was just announced a little bit ago
14:22.09__name__Their FAQ still are not complete either.
14:24.37brlcadis a faq ever complete?
14:24.52__name__They have questions without answers isted.
14:24.55brlcadunless you define the frequency, there will always be someone with a question
14:24.55__name__*listed even
14:25.01brlcadah, meh
14:25.03brlcadnot really concerning -- they're pretty closely mirrored after gsoc
14:25.21brlcadlimited time and resources, building it up as they go .. it is a pilot program after all
14:25.40brlcadany info is a plus, the whole thing could be done over private e-mail exchanges
14:25.41__name__Yeah.
14:25.54brlcador (shudder) phone calls
14:26.34brlcadI'm impressed they got 20 slots funded by their management
14:27.02brlcadroughly 100-200k pilot
14:28.00``Erikheh, a faq with no answers would be awesome "look, it's a faq, not an atfaq! just the questions!" :D
14:29.16__name__Hah
14:33.33*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
15:10.02bhinesley``Erik: I wonder why it doesn't fail for me when there are unused functions... I have debugging enabled
15:10.37bhinesleyI don't even get a warning
15:11.41bhinesleysmacks self awake
15:12.22*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:05.21brlcadbhinesley: different versions of the same compiler will report different warnings, plus other compilation settings (such as optimized) can affect warnings
16:07.46bhinesleydo you always build with strict on? It never works for me
16:07.58``Erikwith debugging OFF, the NDEBUG flag gets set, which turns HIDDEN into "static", otherwise it's defined as /* */
16:08.24``Erikthat's where that issue came from
16:08.52bhinesleyhmm
16:11.09bhinesleythe question I really mean to ask is: what should I be doing differently, so that you guys don't have to follow me around to clean up my mess? :)
16:11.27``Erikstop making a mess? :D
16:11.51bhinesleyI have to figure out how to identify a mess first
16:11.54``ErikI like to have a 'build' directory with several subdirs for different configurations to spot those
16:12.47bhinesleyokay, so you build with various options as a matter of course
16:13.37``Erikyeah, and a variety of os/arch's, to boot
16:14.35bhinesleyok
16:21.27brlcadbhinesley: strict should always work -- if it doesn't, that's something that needs to be addressed
16:21.48brlcadshould be building with strict enabled
16:22.20brlcaddebug enabled and strict enabled -- optimized can be on or off
16:23.22bhinesleythere are thousands upon thousands of warnings... I'm guessing that only certain types are treated as errors
16:23.26bhinesley?
16:24.13bhinesleyI will take a look at what is stopping me from building strict
16:35.24brlcadwhat are the first few?
16:35.48brlcadi'm guessing that it's something like printf specifier conversions
16:38.04*** join/#brlcad Stattrav (~Stattrav@117.192.157.143)
16:38.04*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:54.02*** join/#brlcad alex_jon1 (~alex_joni@81.196.65.201)
16:59.28bhinesleybrlcad: lots of printf specifier conversions, yes. Also, a lot of variables not set or not used (these are stopping me from building strict).
16:59.43*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
17:01.57brlcadbhinesley: what os and version of gcc?
17:02.03brlcadand cmake or autotools build?
17:02.35brlcadif you can produce a full build log, I can look into whether there is a categoric fix
17:03.03bhinesleyFedora 15, gcc 4.6.0 20110530, cmake
17:03.08brlcadI suspect you're just using a version of gcc newer than everyone else or on a curious platform with odd 32-bit/64-bit size mixtures
17:03.17bhinesley64-bit
17:03.23brlcaddefinitely a pretty new gcc
17:04.21brlcadmake -k 2>&1 | tee build.log
17:05.01``Erikinstalls gcc47 on crit O.o
17:05.19bhinesleyOkay, I'm running that. It seems that the unused variables are primarily what is preventing build, so I'll see how far the rabbit hole goes in the meantime.
17:06.59bhinesleya lot of "{int ret; ret = somefunction();}" -> "{(void)somefunction();}"
17:13.33bhinesleyhttp://db.tt/rITDTCH
17:13.54bhinesleybrlcad ^ build log
17:18.31CIA-62BRL-CAD: 03bhinesley * r45540 10/brlcad/trunk/src/libbu/ (bomb.c crashreport.c): removed unused variables and quiet compiler
17:20.23bhinesleymore complex to fix: http://pastebin.mozilla.org/1276121
17:21.11bhinesleyI'm assuming we want to keep BU_LIST_APPEND's BU_ASSERT's
17:27.52CIA-62BRL-CAD: 03bhinesley * r45541 10/brlcad/trunk/src/libbu/vlb.c: remove unused variable missed last commit
17:32.20bhinesleyvery quietly disables strict and goes back to work for now
17:50.20brlcadbhinesley: don't go too far down that route
17:50.56brlcadfunctions like read()/write() will thrown warnings with different versions of the compiler if you cast the return to (void)
17:51.10bhinesleyah
17:51.35brlcadthe fact that the return value is being stashed in a var was to quiet earlier warnings
17:51.46bhinesleyalright, I'll revert
17:52.30brlcadnote that r45540 unveils two issues
17:53.07brlcadfwrite doesn't return an int, it returns a size_t
17:54.43bhinesleyokay, so I'll fix it
17:54.45brlcadwrite and fwrite return values are compared against the number of values written, write is an int, fwrite a size_t, both if (ret != nvals) perror("fwrite/write failed");
17:55.14brlcadjust calling perror() preserves current behavior, just printing the issue
17:55.51brlcad(as a two-liner, not one-liner)
17:57.15*** join/#brlcad merzo (~merzo@48-81-132-95.pool.ukrtel.net)
18:06.42*** join/#brlcad Stattrav (~Stattrav@117.192.157.143)
18:06.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:33.35*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
19:23.15CIA-62BRL-CAD: 03bhinesley * r45542 10/brlcad/trunk/src/libbu/ (bomb.c crashreport.c vlb.c): resolved issues regarding fwrite/write return value validation, unveiled by r45540/r45541 per conversation with Sean
19:42.26*** join/#brlcad KimK_afk (~Kim__@209.248.147.2.nw.nuvox.net)
19:46.08brlcadbhinesley: thought you said there were thousands?
19:46.29brlcadonly see a dozen or so files in your log
19:56.57bhinesleyI must have different options set. I did a `wc` of lines containing "error" a couple weeks ago, and there were thousands.
19:57.07bhinesleyer "warning"
19:59.31bhinesleythat's how I found the 511 warnings that I fixed with r45238
20:00.02bhinesley(all regarding printf specifiers)
20:03.15bhinesleyanyways, it seems that I misunderstood the meaning of strict; I thought that *all* warnings were treated as errors. When I saw so many warnings, I assumed that compiling w/ strict was a goal, not a reality. Then I noticed that people were finding problems with my code a little too fast >.<
20:06.22brlcadyeah, nope .. you're just ahead of us with your fancy new compilerness ;)
20:06.33bhinesleyhah
20:06.45brlcadsuprised starseeker hadn't hit the issues on gentoo
20:09.06CIA-62BRL-CAD: 03brlcad * r45543 10/brlcad/trunk/src/libbu/crashreport.c: quell warning on || && logic, wrap latter in parens
20:15.08CIA-62BRL-CAD: 03128.63.32.74 07http://brlcad.org * r3016 10/wiki/Community_Publication_Portal: stub in ESA SOCIS announcement
20:19.56CIA-62BRL-CAD: 03brlcad * r45544 10/brlcad/trunk/ (NEWS src/mged/mged.c src/mged/setup.c): now that the ged struct is fully initialized during ged_init(), it exposed a bug where code wasn't initializing the output handler properly after opening a database. this restores rt command output.
20:47.30brlcadstarseeker: the csgbrep bomb is valid -- the arbn block creates an nmgmodel and tries to pass it forward as an rt_arbn_internal, so it bombs
20:47.54brlcadthe magic check was probably what changed, no idea how it ever would have worked as it is now
20:48.28brlcadcsgbrep.cpp:261 is where it goes wrong
20:52.41CIA-62BRL-CAD: 03brlcad * r45545 10/brlcad/trunk/src/proc-db/csgbrep.cpp:
20:52.41CIA-62BRL-CAD: looks like this is calling the wrong function table entry. it's setting an NMG
20:52.41CIA-62BRL-CAD: as the object pointer, but was trying to call the ARBN functab. tripped a bomb
20:52.41CIA-62BRL-CAD: magic detection. calling the NMG converter seems to work in a better non-crashy
20:52.41CIA-62BRL-CAD: way.
21:08.42starseekerbrlcad: ah, cool - thanks
21:31.14*** join/#brlcad merzo (~merzo@48-81-132-95.pool.ukrtel.net)
21:31.56CIA-62BRL-CAD: 03kunigami * r45546 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): Added support for setting string parameters to OSL shaders
21:41.03CIA-62BRL-CAD: 03Intmiti 07http://brlcad.org * r3017 10/wiki/Videopoker_is_definately_the_best_casino_games: New page: look for for online casinos on [http://www.google.com Google]
21:41.55*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
22:03.48CIA-62BRL-CAD: 03bhinesley * r45547 10/brlcad/trunk/src/libged/edit.c: change a labeled block to a private function
22:27.16*** join/#brlcad merzo (~merzo@48-81-132-95.pool.ukrtel.net)
22:48.17CIA-62BRL-CAD: 03Antlipi 07http://www.solidgeometry.org * r3018 10/wiki/Blackjack_is_without_any_doubts_the_best_casino_games: New page: look for for ambling on [http://www.google.com Google]
23:14.21CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Antlipi]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
23:14.24CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Blackjack is without any doubts the best casino games]]": content was: 'look for for ambling on [http://www.google.com Google]' (and the only contributor was '[[Special:Contributions/Antlipi|Antlipi]]')
23:14.28CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Intmiti]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
23:14.33CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Videopoker is definately the best casino games]]": content was: 'look for for online casinos on [http://www.google.com Google]' (and the only contributor was '[[Special:Contributions/Intmiti|Intmiti]]')
23:24.26CIA-62BRL-CAD: 03kunigami * r45548 10/brlcad/trunk/src/other/osl/shaders/ (converter.osl sh_texture.osl): texture shader. this one was pretty straightforward since there's already an implemented internal function
23:25.09kunigami_Testing the texture shader: http://dl.dropbox.com/u/1399996/GSoC/osl_texture.png
23:39.04brlcadheh, nifty
23:39.22brlcadwhat happened to the light source, though?
23:40.26brlcadilluminating the left corner but not the right just from the reflective box?  if so, seems like there's some energy loss (I'd expect it to be brighter given previous images)
23:51.14kunigami_brlcad: in previous images I was multiplying the colors by a factor of 2 or 3 because the scene was too dark. Now I'm just using a very very bright light. I'm not sure if that's the cause of difference
23:51.30brlcadkunigami_: so you mentioned earlier that you have to hypersample 1000 times .. that just sounds wrong for many reasons.. how is hypersampling being used?
23:53.01kunigami_the image above was hypersamples 1000 times too. I'm just using -H 1000 -J3
23:53.13brlcadshould work without any hypersampling, just perhaps not as well converged global light (e.g., corners not quite as dark as they should be)
23:53.25brlcadright, but .. why? :)
23:53.38brlcadwhat does non -H1000 look like?
23:55.22kunigami_brlcad: http://dl.dropbox.com/u/1399996/GSoC/no-hypersampling.png
23:55.55brlcadso can you explain that?
23:56.43brlcadevery pixel has a ray being fired, so why wouldn't they all return a color for a primary hit?
23:57.07kunigami_the osl system returns a random reflection direction everytime I make a query (biased depending on the shader), so it's necessary
23:57.19``Erik-H only effects the primary ray, didn't the path tracer and photon mapper twingy did get a HUGE benefit by multiplying secondaries instead of primaries?
23:57.24kunigami_a large number of samples so the color converges
23:58.58brlcadkunigami_: returning a random reflection direction sounds like a controllable parameter though, no?
23:59.41brlcadit's the shader's job to determine whether there is reflection in the first place
23:59.50kunigami_hm not sure. I'd have to find out
IRC log for #brlcad on 20110720

IRC log for #brlcad on 20110720

00:00.23brlcadunless you just happen to be using an osl shader that returns random reflections
00:00.50brlcadotherwise, it sounds like something they's just default to .. but isn't actually necessary -- should be able to converge much faster
00:01.16brlcadotherwise it sounds like it basically acting like a generalized path tracer
00:01.28brlcadotherwise ;)
00:01.42kunigami_I think it's a path tracer
00:01.53brlcadit is and it isn't ;)
00:02.02brlcadisn't supposed to be a generalized shader system
00:02.22brlcadmeaning you could use it as a path tracer or not
00:02.42kunigami_hmm makes sense
00:02.42brlcadperhaps it just defaults to path tracing
00:02.55``Erikaccidental negative? it IS supposed to be generalized, no? so'z it can be path trace, radiosity, phong, etc
00:03.26brlcad"isn't it supposed to be"
00:04.06brlcador s/isn't/it's/ :)
00:04.06``Erikah, s/t/ t it/;s/$/?/
00:04.34kunigami_the thing is that I based my code in a example and maybe there it was implementing a path tracer
00:05.00kunigami_I wasn't aware that this could be just a "mode"
00:05.07``Erikkunigami: sounds so, is there a basic phong OSL script you can slap in there? that'd be a lot quicker on the tests and be a pretty close relative to the current 'default' of rt
00:05.13brlcadso then we (you) have some homework to figure out ;)
00:06.04``Erikwould think pixdiffs of the current C phong/plastic vs the OSL phong would be interesting
00:06.23brlcadfor starters, making sure you're working with rt from here forward, not a standalone so we make sure the integration migrations towards something production usable, even if it's the path tracer
00:06.40brlcadI don't think OSL ships phong by default
00:07.22``Erikany guess on how difficult it'd be to write? I'd hope trivial...
00:08.01brlcadhm, mildly related discussion: http://groups.google.com/group/osl-dev/browse_thread/thread/3350532577b3f8b7/657b1956e545b5ba?lnk=raot
00:08.30kunigami_I think there's a implementation of a phong shader, but if I remember well, it wasn't much different from the diffuse
00:08.39kunigami_let me try here
00:09.52brlcadhates it when he searches for some topic like this and the top hits are our own irc log discussions
00:10.35brlcadso phong() is an OSL function
00:10.45brlcadalong with cooktorrance()
00:10.52brlcadand a few others
00:11.23``Erikok, so we do have the theoretical opportunity for a 1:1 comparison of our own shader system vs osl
00:11.57brlcadstill unclear how you drive the phong reflectance/specular rays
00:13.10``Erikif push comes to shove, we SHOULD be able to re-implement our interpretation in osl, I'd hope?
00:13.30brlcadit's not that
00:13.39brlcadlibrt is still the one shooting rays and managing geometry
00:13.55brlcadso librt fires, hits an osl surface, calls into osl to figure out what to do
00:14.01``Erik*shrug* either way, hasta luego, see ya'll tomorrie :)
00:14.15brlcadthen it needs to fire more rays .. how it does that isn't clear to me
00:15.41brlcadthis should be like a "chapter 1" or intro-to-osl detail spelled out somewhere
00:18.28brlcadaha, language spec talks about it somem
00:19.04brlcad"Effects that would ordinarily require explicit ray tracing, such as reflection and refraction, are simply part of the radiance closure and look like any other BSDF
00:21.07brlcadmm, getting the gist
00:21.11brlcadkunigami_: so I'll have to read through this some more tonight, but I think the first step is to not gang off the -H option since that fires multiple primary rays ...
00:23.21brlcadvery expensive
00:23.28brlcaddo something trivial like getenv(LIBRT_OSL_SAMPLES) instead of a command line option and use that parameter to toggle how many internal osl samples it needs to acquire per ray
00:24.27brlcadshould shave massive amounts of time since it doesn't need to rewalk the spatial partitioning, and still give the same resulting picture
00:25.17kunigami_ah I was just asking that. ok, so going back to my first implemented hypersampling
00:25.34brlcadwe can tie it to command-line options later if it all gets working cleanly
00:25.52brlcadit *shouldn't* need to re-call rt_shootray()
00:26.08brlcadthe ray hit is the same for 1 sample as it was for 1 million
00:56.40CIA-62BRL-CAD: 03kunigami * r45549 10/brlcad/trunk/src/liboptical/sh_osl.cpp:
00:56.40CIA-62BRL-CAD: added back hypersampling right on sh_osl instead of using the -H parameter. It's
00:56.40CIA-62BRL-CAD: much less expensive since we dont need to re-calculate the hit point which, in
00:56.40CIA-62BRL-CAD: the end, will be the same for all samples. It reads the number of samples from
00:56.40CIA-62BRL-CAD: an environment variable, which is better than having a hardcoded value
01:31.05*** join/#brlcad Stattrav_ (~Stattrav@117.192.132.140)
01:37.19*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
01:42.45brlcadkunigami_: there are several items in your nsamples loop there that do not change across loop iterations -- should pull them out so they're only computed once
02:01.29*** join/#brlcad Stattrav_ (~Stattrav@117.192.152.125)
02:06.32*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
02:11.35*** join/#brlcad Stattrav_ (~Stattrav@117.192.148.37)
03:03.39*** join/#brlcad Stattrav (~Stattrav@117.192.149.58)
03:03.39*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
03:07.41CIA-62BRL-CAD: 03bhinesley * r45550 10/brlcad/trunk/src/libged/edit.c:
03:07.41CIA-62BRL-CAD: Cut down on a lot of duplication. Fixed a few issues with subcmd arg helper
03:07.41CIA-62BRL-CAD: functions (and most are enabled/used now). ged_edit() generic subcommand
03:07.41CIA-62BRL-CAD: argument parsing is nearly done. Still a WIP. Some option combinations are
03:07.41CIA-62BRL-CAD: accepted that shouldn't be. It is crashing right now, too. That is to be
03:07.42CIA-62BRL-CAD: expected, as it needs edit_str_to_arg() to work properly, and that is
03:07.43CIA-62BRL-CAD: incomplete/needs some modifications.
03:18.01*** join/#brlcad Stattrav (~Stattrav@117.192.132.193)
03:18.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
03:34.20*** join/#brlcad Stattrav_ (~Stattrav@117.192.157.12)
03:55.43*** join/#brlcad Stattrav (~Stattrav@117.202.18.126)
03:55.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
04:00.42*** join/#brlcad Stattrav_ (~Stattrav@117.202.16.214)
04:05.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
04:25.44*** join/#brlcad Stattrav_ (~Stattrav@117.202.23.44)
04:37.55*** join/#brlcad Stattrav (~Stattrav@117.202.24.28)
04:37.55*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
04:55.29*** join/#brlcad Stattrav (~Stattrav@117.192.156.5)
04:55.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:00.28*** join/#brlcad Stattrav_ (~Stattrav@117.192.146.128)
05:05.26*** join/#brlcad Stattrav (~Stattrav@117.202.28.81)
05:05.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:16.45*** join/#brlcad Stattrav_ (~Stattrav@117.202.22.242)
05:24.24CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload: uploaded a new version of "[[Image:Industry Diagram.pdf]]": Fifth revision of the BRL-CAD Industry Diagram.
05:27.32*** join/#brlcad Stattrav (~Stattrav@117.192.159.51)
05:27.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
05:29.15brlcadstarseeker: care to try another attempt at converting the diagram to an open format? :)
05:30.05brlcadbeen a few years, better fonts, hopefully better rendering
05:31.10*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
05:31.18yukonbobhello, #brlcad :)
05:33.12*** join/#brlcad Stattrav_ (~Stattrav@117.192.154.48)
05:43.41brlcadhowdy
05:52.57yukonbobhai
05:53.22yukonbobhow're things?
06:47.55*** join/#brlcad Stattrav (~Stattrav@117.192.128.91)
06:47.55*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:00.39*** join/#brlcad merzo (~merzo@193.254.217.44)
07:28.52*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:11.31*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:23.10*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:51.49*** join/#brlcad Stattrav (~Stattrav@122.178.195.64)
10:51.49*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:33.04*** join/#brlcad SCD101 (~sam@109.77.120.154)
12:33.19SCD101Hey there :)
12:37.35SCD101Many people enquired about the ESA SoC?
12:48.06CIA-62BRL-CAD: 03kunigami * r45551 10/brlcad/trunk/src/liboptical/sh_osl.cpp: moving constant parts out of the loop
12:56.40brlcadSCD101: I think we're up to approximately 482
12:57.06SCD101482 for just your projects? Wow
12:58.04brlcadSCD101: heh, if you believe that, I have a bridge to sell you
12:58.36SCD101Well considering there are 20 places in total over all of the organisations :P
12:58.47SCD101How many really? :L
12:59.10SCD101Also, how big is the bridge?
12:59.15SCD101:P
12:59.16brlcadit's a wonderful bridge, connecting reality with Mr. Roger's Neighborhood
12:59.32brlcadjust a couple
13:00.24brlcad20 orgs, but the program isn't exceptionally well known, only affects EU students, and is for students with an interest in a niche domain (space)
13:00.30SCD101Ah cool. I only know C and am doing GSoC atm. Would I need experience with BRL-CAD or is it only needed for some of the projects?
13:18.02brlcadshouldn't matter for most projects, you's learn what you need as you go
13:18.50brlcadyou don't need experience with BRL-CAD, but you should be able to read and comprehend existing source code quickly so anything you work on is properly integrated
13:19.26brlcadnone of the projects are stand alone, work-off-in-a-corner tasks
13:19.54brlcadthey're all intended to be fully integrated so that when you're done, you've improved BRL-CAD in some fashion
13:33.21SCD101brlcad, I'm currently working on dpkg for Debian. So I've gotten some good experience with large codebases. However I do hope our codebase has more comments than dpkg :P
13:36.12brlcadat more than 1M lines, you'll find some parts are extensively commented, beautiful lush examples, along with  entire continents of code without comments
13:36.34brlcadso it depends where you're working, but there are plenty of devs to help you along
13:36.58SCD101Ok that's good :)
13:37.21SCD101And all of the projects are open for submission? I only ask because there can only be one can't there? :P
13:38.46brlcadnot sure what you mean
13:39.02brlcadyou propose the project
13:39.05brlcadwe just suggest ideas
13:39.37SCD101Nvm got confused :L
13:41.04SCD101I'm liking the look of this bending light idea :P
13:41.39SCD101AH you use svn
13:47.51SCD101Ok I really like the code layout. Looks nice to work with
15:55.38*** join/#brlcad SCD101 (~sam@109.77.120.154)
16:04.49brlcadif you have any questions, this is usually the place (or the mailing list)
17:00.04kunigami_it seems osl shaders have functions named eval_reflect and eval_transmit which must be fed with the view direction and the lighting direction and they return the color
17:05.50kunigami_hmm so we need to consider the contribution of each light source and get a color?
17:07.21kunigami_then, if there's reflection/refraction to be done, we compute the directions?
17:45.11*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
18:15.10*** join/#brlcad merzo (~merzo@142-55-132-95.pool.ukrtel.net)
18:30.17CIA-62BRL-CAD: 03bhinesley * r45552 10/brlcad/trunk/src/libged/edit.c: oops; db_free_full_path() doesn't free bu_malloc'd space for the db_full_path struct itself, so it must be done manually.
18:39.26CIA-62BRL-CAD: 03bob1961 * r45553 10/brlcad/trunk/src/tclscripts/mged/openw.tcl: This fixes the failed browser launch on windows.
18:56.40CIA-62BRL-CAD: 03brlcad * r45554 10/brlcad/trunk/NEWS: bob fixed a bug in mged where the browser wasn't getting set properly so the browser wouldn't launch. needed to set mged_browser var but was only setting (web_browser)
19:05.57brlcadkunigami_: so my reading through the osl intro last night, it does change a few notions I had of their system
19:06.40brlcadthey are geared towards solving global illumination, which doesn't necessarily mean path tracing, but it does mean that they're not set up for traditional phong-style ray tracing
19:07.33kunigami_does global illumination imples multiple samples?
19:07.37brlcadactually, their docs seemed a little self-contradicting saying they didn't implement phong-style semantics for a shader but then continue to list a phong function as a possible shader evaluation routine
19:07.37kunigami_implies*
19:07.51brlcadyes and no
19:08.06brlcadosl evaluates closures
19:08.27brlcadso you can think of every pixel as representing a complex polynomial equation
19:08.57brlcadif solves the equation as far as it can parametrically, then uses the starting view/ray information to solve the remainder
19:09.08brlcadso in theory, they precompute a lot more than you would otherwise
19:10.28brlcade.g., if you had a lot of reflective shiny surfaces, bright lights but then had a "black-hole sphere" in that scene, then the closure for the pixels of the sphere reduce to .. nothing, black, and there is no need to sample, reshoot, etc
19:10.51brlcadit's not just "absorbed", it figured out that the equation reduced
19:13.16kunigami_I made two renders using their phong function. one using exponent = 0 and the other exponent = 1.
19:13.18brlcadso not calling -Hbig_number and having any OSL-samples happen internally was a better direction
19:15.13kunigami_exp = 0 http://dl.dropbox.com/u/1399996/GSoC/green-phong-e0.png
19:15.24kunigami_exp = 1 http://dl.dropbox.com/u/1399996/GSoC/green-phong-e1.png
19:17.27brlcadmm, too noisy to tell what is going on there
19:20.23*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
19:20.30*** part/#brlcad kunigami_ (~kunigami@201.53.206.27)
19:20.34*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
19:26.14brlcadkunigami_: did you see a performance difference between shooting with -H and since you refactored out the common code from the loop you readded?
19:27.03kunigami_didn't measured. Let me do some tests
19:27.27brlcadwould have expected it to be noticeable
19:32.47kunigami_I was wondering if it's desirable to have another incremental mode view for such shaders. At each sample the framebuffer is updated so the image begins noisy and converges to a noise-free one
20:20.08CIA-62BRL-CAD: 03erikgreenwald * r45555 10/brlcad/trunk/ (include/bu.h src/libbu/simd.c): add support for SSE3, SSE4_1 and SSE4_2. Add a bu_simd_supported function. Minor cleanup and clobberage fixes
20:25.19CIA-62BRL-CAD: 03r_weiss * r45556 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: (log message trimmed)
20:25.19CIA-62BRL-CAD: Updated function nmg_class_pt_s within file nmg_class.c. This change supports
20:25.19CIA-62BRL-CAD: the prototype version of the nmg_triangulate_fu function. Within function
20:25.19CIA-62BRL-CAD: nmg_class_pt_s it uses the raytracer to classify if a point is in, out or on a
20:25.19CIA-62BRL-CAD: shell. During the computations of determining this, line intersection functions
20:25.20CIA-62BRL-CAD: are used where some require finite line segments. To help resolve some of the
20:25.21CIA-62BRL-CAD: computation problems I added a magnitude to the ray direction vector instead of
20:52.34*** join/#brlcad tharis20 (~tharis@bl21-44-216.dsl.telepac.pt)
21:21.23tharis20hi, I'm Francisco from Portugal and I'm applying to SOCIS
21:21.56tharis20I don't know what else I should mention, for now I'm just reading and following the checklist
21:23.32kunigami_brlcad: running with -H 100 and 1 sample per pixel, took 910s. with -H 1 and 100 samples per pixel, took 713s.
21:29.51CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r3020 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ added reports for week 9
21:31.33CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r3021 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 9 (July 18th to July 25) */ added more info to week 9
21:50.20brlcadtharis20: welcome and thanks!
21:50.26brlcadkunigami_: iiiinteresting
21:50.49brlcadI would have expected more of an increase frankly, but maybe osl is just dominating more than I thought
21:51.32tharis20brlcad: to run archer do I need to compile brlcad with opengl?
21:52.18brlcadkunigami_: so now is oslr->QueryColor() deterministic?  does it return the same color every time for a given info?
21:52.25brlcadtharis20: yep
21:52.36brlcadotherwise, you can use 'mged'
21:52.54tharis20I know, but I wanted to run archer to see the differences
21:53.11kunigami_brlcad: no, I still don't know how to use eval_reflect / transmit correcly.
21:53.43tharis20OpenGL is supposed to be shipped with OSX, but I'm getting an error compiling brlcad with it... I'll see if I can fix it, otherwise, I'll ask someone for help
21:54.16brlcadtharis20: it is shipped with osx -- how are you compiling?  
21:54.30brlcadtharis20: give the cmake build a try, you'll need to install cmake
21:55.19tharis20I have cmake installed, but I was using autotools
21:55.27tharis20I'll give it a shot then
21:56.27brlcadotherwise, you can paste an error snippet and usually someone will respond within a while
21:56.40tharis20sure ;) thank you
22:13.26*** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
22:14.06*** join/#brlcad SCD101 (~sam@109.77.120.154)
22:14.07tharis20...
22:52.22tharis20woot 37 minutes, 8 seconds
22:57.59``Erikfor the compile? single core slower machine? o.O nfs over 14.4k modem? :D
22:59.27bhinesleywaits about that long for a clean build on a Core 2 6600 @ 2.4Ghz
23:00.34*** join/#brlcad SCD101 (~sam@109.77.120.154)
23:13.13*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
23:13.20abhi2011hi
23:15.09abhi2011I am trying to write a basic plugin for BRLCAD
23:15.30abhi2011Is there any tutorial similar to http://brlcad.org/wiki/Developing_applications for plugins ?
23:17.10tharis20``Erik: yes, for the compile
23:30.08CIA-62BRL-CAD: 03r_weiss * r45557 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: (log message trimmed)
23:30.08CIA-62BRL-CAD: Updated functions vertex_neighborhood, get_pole_dist_to_face,
23:30.08CIA-62BRL-CAD: guess_class_from_hitlist_min, guess_class_from_hitlist_max,
23:30.08CIA-62BRL-CAD: isect_ray_snurb_face, record_face_hit, edge_hit_ray_state, ray_hit_vertex,
23:30.08CIA-62BRL-CAD: nmg_class_ray_vs_shell within file nmg_rt_isect.c. Many changes are to support
23:30.09CIA-62BRL-CAD: the prototype version of nmg_triangulate_fu. The changes associated with this
23:30.10CIA-62BRL-CAD: prototype are disabled by default. The prototype related changes create a
23:37.15kunigami_To evaluate the contribution of light sources, I'll have to find the light directions for every query point and also if this light is visible or not. For now, I'll just use BRL-CAD lights because this information is already computed
23:58.28kunigami_Seems there's a bug on sh_toon shader. Currently it is : cosi = VDOT(swp->sw_hit.hit_normal, swp->sw_tolight);
23:58.30CIA-62BRL-CAD: 03r_weiss * r45558 10/brlcad/trunk/src/libbn/plane.c:
23:58.30CIA-62BRL-CAD: Updated the protoype function bn_isect_line3_line3_new within file plane.c which
23:58.30CIA-62BRL-CAD: supports the prototype function nmg_triangulate_fu. These changed are disabled
23:58.30CIA-62BRL-CAD: by default. Performed code cleanup and improved some of the logic. More cleanup
23:58.30CIA-62BRL-CAD: is needed. This is a work in progress.
23:59.41kunigami_but since we're iterating on lights, I think it should be: cosi = VDOT(swp->sw_hit.hit_normal, &sh_swp->sw_tolight + 3*i);
IRC log for #brlcad on 20110721

IRC log for #brlcad on 20110721

00:01.09kunigami_If anyone confirm that I'll change it
00:03.16kunigami_oops ignore the operator & there
00:22.42brlcadabhi2011: wanting to "write a basic plugin" can mean many many things to a package as large as brl-cad
00:23.06abhi2011ok
00:23.29brlcadcould be new object type, new shaders, new commands, new tools, ...
00:23.31abhi2011so I am trying to learn how to compile plugins
00:23.41abhi2011i just want to print something
00:23.48abhi2011on the console and exit
00:23.55brlcadfrom what?
00:24.13abhi2011from inside the plugin
00:24.19abhi2011this is for the physics engine
00:24.22brlcadstill, a plugin to *what* :)
00:24.33abhi2011we were discussing in the mailing list
00:24.35brlcadbrl-cad is a suite of applications
00:24.49brlcadokay, so probably a new command
00:24.54abhi2011yes
00:24.58brlcadcommands go into libged
00:25.06abhi2011so something like ged_physics()
00:25.46bhinesleysrc/libged/zap.c is a small example
00:26.57abhi20111 sec i ll ok
00:27.05bhinesleyor version.c
00:27.10abhi2011ok
00:27.14brlcadyeah, there are about 400 examples in there
00:27.30abhi2011ok....is there any doc which discusses how to compile the plugin
00:27.39abhi2011that is after i have setup the tcl code and c code
00:27.48brlcadadd them to src/mged/setup.c and you'll have it available in mged
00:27.59abhi2011ah ok
00:28.08abhi2011well i actually wanted to make a plugin for archer
00:28.47abhi2011the plugin will allow simple physics ultmately
00:28.48brlcadadding to archer is a bit more involved, save that for later
00:28.57abhi2011ok
00:29.11brlcadit's easy, but that's code that's in flux, so no need to waste time
00:29.37abhi2011so to compile the code I guess something like :  cc -I/usr/brlcad/include/brlcad -L/usr/brlcad/lib -o rtexample rtexample.c -lbu -lrt -lm
00:29.42brlcadif a new physics command does what you're proposing it will do, then can look into archer hooks
00:29.43abhi2011should do ?
00:30.06brlcadyou could do that, assumes a brl-cad install but better would be to add it to the build logic
00:30.23abhi2011ok
00:30.34brlcadif you're doing an autotools compile, you edit the Makefile.am; or if you're doing a cmake compile, it's the CMakeLists.txt file
00:30.37brlcadthen just make
00:30.48abhi2011ok
00:30.59brlcad(after running autogen.sh or cmake or configure, depends on which build system you use and your platform)
00:31.08brlcadINSTALL and INSTALL.cmake have details
00:31.16abhi2011ok
00:31.54abhi2011by the way I was trying out the example from http://brlcad.org/w/images/3/3d/Application_Development.pdf
00:32.04abhi2011the rtexample.c file
00:32.06brlcadkunigami_: good find if it is the bug, but I'm not familiar with that shader -- ``Erik wrote it
00:32.15abhi2011if i compile using cc -I/usr/brlcad/include/brlcad -L/usr/brlcad/lib -o rtexample rtexample.c -lbu -lrt -lm
00:32.16brlcadabhi2011: yes?
00:32.20abhi2011then i get
00:32.37abhi2011no bio.h file
00:32.57brlcadneed to also include /usr/brlcad/include
00:33.00abhi2011and this header is indeed not present in /usr/include/brlcad
00:33.33abhi2011ah ok
00:33.43brlcadactually, you're right
00:33.50brlcadbio.h is considered a private header
00:34.06abhi2011yah
00:34.11abhi2011i dont c it there either
00:34.26abhi2011in /usr/brlcad/include i mean
00:34.46abhi2011there is a file called fbio.h
00:35.01abhi2011in /usr/brlcad/include/brlcad
00:35.19abhi2011i popped that in instead :P
00:35.51CIA-62BRL-CAD: 03brlcad * r45559 10/brlcad/trunk/src/rt/rtexample.c: doesn't seem to be a real need for bio.h here. remove it since this is an example application meant to compile outside brl-cad's build system. thx abhi2011 for the catch.
00:36.15abhi2011ok
00:36.18abhi2011np
00:36.40brlcadtechnically, http://brlcad.org/w/images/3/3d/Application_Development.pdf doesn't reference bio.h ;)
00:36.57abhi2011ah ok
00:37.09abhi2011well no tcl.h now
00:37.21abhi2011[abhi@abhi rt]$ cc -I/usr/brlcad/include/brlcad -L/usr/brlcad/lib -o rtexample rtexample.c -lbu -lrt -lm
00:37.22abhi2011In file included from /usr/brlcad/include/brlcad/vmath.h:85:0,
00:37.24abhi2011<PROTECTED>
00:37.25abhi2011/usr/brlcad/include/brlcad/bu.h:216:58: fatal error: tcl.h: No such file or directory
00:37.27abhi2011compilation terminated.
00:37.51brlcadthat's system dependent
00:37.58abhi2011ah ok got it
00:38.00brlcadeither in /usr/brlcad/include or somewhere else on your system
00:38.06abhi2011yes right
00:38.09abhi2011will put it in
00:38.11brlcadthat compile line is just supposed to be notional, no way to make it work for everyone
00:38.20abhi2011right
00:49.20abhi2011ok got rtexample.c compiled with cc -I/usr/brlcad/include/brlcad -I/usr/brlcad/include-L/usr/brlcad/lib -o rtexample rtexample.c -lbu -lrt -lm
00:49.58abhi2011now there is a shared library error with brlcad utility library
00:50.01abhi2011[abhi@abhi rt]$ ./rtexample sphere.g sph1.s
00:50.03abhi2011./rtexample: error while loading shared libraries: libbu.so.19: cannot open shared object file: No such file or directory
00:51.03abhi2011perhaps its not looking in /usr/brlcad/lib
00:51.17abhi2011where i can see the library is present
00:52.29abhi2011hmm....I have given the lib path correctly during compiling though
00:59.35abhi2011probably load library path
00:59.51*** join/#brlcad Stattrav (~Stattrav@117.192.137.87)
00:59.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
01:03.02kunigami_abhi2011:  which OS?
01:03.11abhi2011right finally got rtexample working
01:03.16brlcadyour example line has a typo, before the -L
01:03.18abhi2011fedora 15
01:03.26brlcad(no space)
01:03.48abhi2011yes i corrected that
01:04.25abhi2011the $LD_LIBRARY_PATH was not pointing to /usr/brlcad/lib
01:04.36abhi2011i put that in , now it runs
01:04.53brlcadnot particularly relevant for implementing a physics engine command, but here's a similar example that shows one of the interfaces for creating procedural geometry:  http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/proc-db/wdb_example.c?revision=45559&view=markup
01:05.07brlcadLD_LIBRARY_PATH shouldn't need to point to /usr/brlcad/lib
01:05.13brlcadunless you already had is set
01:05.49brlcadLD_LIBRARY_PATH overrides whatever the binary was compiled to look in, if it was set then the solution was probably to just unset it
01:06.03brlcadunless you have it set due to other apps or something like that
01:06.07abhi2011well ok i ll try unsetting it
01:06.13abhi2011it was blank before
01:06.23brlcadset or blank?
01:06.31brlcader, unset or blank?
01:06.41brlcadempty is not the same as unset
01:06.49abhi2011it was blank...but the program was complaining when it was blank
01:07.12abhi2011hmm....it was printing a blank line when i echoed it
01:07.45brlcadso what are you studying?
01:08.06abhi2011i am doing computer engineering
01:08.17brlcadundergrad or grad?
01:08.22abhi2011grad
01:08.39abhi2011you are studying as well  ?
01:08.52brlcadalways ;)
01:08.58abhi2011hehe
01:09.00brlcadbut not in a university setting any more
01:09.07abhi2011ok
01:09.17abhi2011hmm..same error again
01:09.29abhi2011./rtexample: error while loading shared libraries: libbu.so.19: cannot open shared object file: No such file or directory
01:10.00abhi2011but i think the gcc linker will link it in as a static library
01:10.16brlcadldd rtexample
01:10.26abhi2011yep abt to do tht
01:10.47abhi2011hmm
01:10.52abhi2011[abhi@abhi rt]$ ldd rtexample
01:10.52brlcadthere's no reason it shouldn't work non-static and without LD_LIBRARY_PATH set
01:10.53abhi2011linux-gate.so.1 =>  (0x00339000)
01:10.56abhi2011libbu.so.19 => not found
01:10.57abhi2011librt.so.19 => not found
01:10.58abhi2011libm.so.6 => /lib/libm.so.6 (0x4d18c000)
01:11.00abhi2011libc.so.6 => /lib/libc.so.6 (0x4cfd1000)
01:11.02abhi2011/lib/ld-linux.so.2 (0x4cfb0000)
01:11.54brlcadwhat does it report if you just run this:  cc -I/usr/brlcad/include/brlcad -I/usr/brlcad/include -L/usr/brlcad/lib -o rtexample rtexample.c
01:12.51abhi2011lots of undefined references
01:13.08abhi2011[abhi@abhi rt]$ cc -I/usr/brlcad/include/brlcad -I/usr/brlcad/include -L/usr/brlcad/lib -o rtexample rtexample.c
01:13.10abhi2011/tmp/cchQUtho.o: In function `hit':
01:13.12abhi2011rtexample.c:(.text+0x58): undefined reference to `bu_log'
01:13.13abhi2011rtexample.c:(.text+0x133): undefined reference to `bu_badmagic'
01:13.15abhi2011rtexample.c:(.text+0x1a8): undefined reference to `bu_badmagic'
01:13.17abhi2011rtexample.c:(.text+0x226): undefined reference to `bu_badmagic'
01:13.18abhi2011.....
01:14.04abhi2011hmm the -L flag should be enough to specify the library path
01:14.06brlcadso then: cc -I/usr/brlcad/include/brlcad -I/usr/brlcad/include -L/usr/brlcad/lib -o rtexample rtexample.c -lrt -lbu -lm
01:15.04abhi2011that command compiles successfully
01:15.22brlcadbut then ldd still says not found?
01:15.31abhi2011yep
01:15.33abhi2011[abhi@abhi rt]$ cc -I/usr/brlcad/include/brlcad -I/usr/brlcad/include -L/usr/brlcad/lib -o rtexample rtexample.c -lrt -lbu -lm
01:15.35abhi2011[abhi@abhi rt]$ ldd rtexample
01:15.37abhi2011linux-gate.so.1 =>  (0x00b43000)
01:15.38abhi2011librt.so.19 => not found
01:15.40abhi2011libbu.so.19 => not found
01:15.41abhi2011libm.so.6 => /lib/libm.so.6 (0x4d18c000)
01:15.43abhi2011libc.so.6 => /lib/libc.so.6 (0x4cfd1000)
01:15.44abhi2011/lib/ld-linux.so.2 (0x4cfb0000)
01:15.46abhi2011[abhi@abhi rt]$
01:15.52brlcadthen something with your ld setup doesn't seem standard
01:16.19abhi2011hmm..its a fresh fedora install
01:16.44brlcadset > file
01:16.50brlcadpastebin the file
01:16.56abhi2011ok
01:17.15brlcadcc --version
01:17.43brlcadfwiw, it doesn't really matter (at least in terms of getting work done)
01:18.06brlcadit's something particular to either your setup and system or fedora in general
01:18.16brlcadusual integration is to mod the build system
01:18.26abhi2011ok
01:18.39abhi2011by the way...what do you mean by paste binning the file
01:18.45abhi2011i ll just paste it here ?
01:18.48brlcad~pastebin
01:18.48ibot[~pastebin] A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://bin.cakephp.org/ , http://asterisk.pastey.net/ , or install pastebinit with yum or aptitude.
01:18.57brlcaddon't use the first one
01:19.36abhi2011ok
01:20.33abhi2011http://bin.cakephp.org/view/1242653996
01:23.12abhi2011[abhi@abhi rt]$ cc --version
01:23.14abhi2011cc (GCC) 4.6.0 20110530 (Red Hat 4.6.0-9)
01:23.16abhi2011Copyright (C) 2011 Free Software Foundation, Inc.
01:25.27abhi2011dont try to hack my system :P
01:32.49brlcadwhy would I bother with that? :P
01:33.07brlcadso you DO have LD_LIBRARY_PATH set to empty
01:33.14brlcadtry: unset LD_LIBRARY_PATH
01:33.19brlcadthen ./rtexample
01:36.14abhi2011haha just kidding :)
01:36.27abhi2011ok yah i ll try that
01:38.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
01:42.06abhi2011[abhi@abhi rt]$ unset LD_LIBRARY_PATH
01:42.08abhi2011[abhi@abhi rt]$ ./rtexample
01:42.10abhi2011./rtexample: error while loading shared libraries: librt.so.19: cannot open shared object file: No such file or directory
01:42.12abhi2011[abhi@abhi rt]$ echo $LD_LIBRARY_PATH
01:42.52abhi2011seems that its unable to find the library without the library path being set
01:47.46kunigami_Did you try: export LD_LIBRARY_PATH=/usr/brlcad/lib  ?
01:50.31abhi2011yes that does work of course
01:50.57abhi2011ok so I am trying to add a command to Mged
01:51.28abhi2011i copied src/libged/zap.c to test.c
01:51.37abhi2011and i have modified it to :
01:52.06abhi2011http://bin.cakephp.org/view/118439282
01:52.36abhi2011then in setup.c i added a cmd below the zap command
01:52.47abhi2011<PROTECTED>
01:52.49abhi2011<PROTECTED>
01:52.50abhi2011{"T", cmd_test, GED_FUNC_PTR_NULL},
01:52.52abhi2011<PROTECTED>
01:52.55abhi2011the T command for testing
01:53.17abhi2011now I guess i need to compile these 2 files
01:53.33abhi2011so do I compile like I did for rtexample.c ?
01:54.00CIA-62BRL-CAD: 03bhinesley * r45560 10/brlcad/trunk/src/librt/db_fullpath.c:
01:54.00CIA-62BRL-CAD: db_string_to_path() will trim all leading slashes, but only one trailing slash;
01:54.00CIA-62BRL-CAD: then it fails when more than one trailing slash is given. I can think of no
01:54.00CIA-62BRL-CAD: reason why it shouldn't remove all trailing slashes, so now it does.
01:55.11abhi2011i think the cmd_test still needs to be defined though
01:59.25bhinesleyabhi2011: actually, mged isn't using libged for that one...
02:00.18bhinesleyyou need a better example :)
02:01.36bhinesleyarcher is using ged_zap, while mged is using cmd_zap
02:04.24bhinesleyged_cat in cat.c is another short one
02:05.14bhinesleywhat you'll need is something like {"T", cmd_ged_plain_wrapper, ged_test}
02:13.55brlcadabhi2011: the thing is, the library path is supposed to be set in the binary (unless ld or gcc are configured otherwise)
02:14.35brlcadlike I said, might be a fedora-specific setting or something different with gcc 4.6
02:15.03brlcadeither way, really doesn't matter -- that's not the usual compile method -- we use a build system
02:15.27brlcadso first step is to compile and install all of brl-cad -- there is a checklist on the wiki of things to do
02:15.47brlcadas for the command, everything bhinesley is saying is spot on :)
02:55.58*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
04:26.07*** join/#brlcad Stattrav (~Stattrav@117.202.21.215)
04:26.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
04:31.06*** join/#brlcad Stattrav (~Stattrav@117.202.23.74)
04:31.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
04:58.47*** join/#brlcad Stattrav (~Stattrav@117.202.23.74)
04:58.47*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:39.46CIA-62BRL-CAD: 03bhinesley * r45561 10/brlcad/trunk/src/libged/edit.c: Fixed a bunch of logic bugs. Implemented 'quiet' flagging for edit_str_to_arg, and allowed for conversions to be silently attempted whenever a string *might* contain an arg.
06:54.21*** join/#brlcad merzo (~merzo@193.254.217.44)
07:08.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:17.12CIA-62BRL-CAD: 03bhinesley * r45562 10/brlcad/trunk/src/libbu/bomb.c: "not validating 'write' return value; missed this in r45542"
07:24.37*** join/#brlcad Stattrav (~Stattrav@117.213.184.187)
07:24.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:39.31*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
10:25.26*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
10:28.32*** join/#brlcad merzo (~merzo@193.254.217.44)
10:55.19tharis20brlcad: does fixing a broken link on your wiki count as a useful patch? :p
11:07.40abhi2011brlcad: well i have installed all of brlcad
11:08.44abhi2011and I have setup a new file in src\libged
11:08.54abhi2011src\libged\test.c
11:09.57abhi2011so I want it to be a new command to mged
11:10.29abhi2011i inserted a new command into setup.c
11:10.59abhi2011{"T", cmd_ged_plain_wrapper, ged_test},
11:12.01abhi2011my question is how do I now compile both the files : setup.c and test.c, so that they become available in mged
11:18.59kunigami_add test.c to LIBGED_SOURCES at libged/CMakeLists.txt
11:19.37CIA-62BRL-CAD: 03brlcad * r45563 10/brlcad/trunk/src/libbu/bomb.c: write() returns an ssize_t, simplify test
11:22.55brlcadtharis20: can I apply the fix with the patch command?
11:23.27brlcadabhi2011: did you compile/install using cmake?
11:24.02brlcadif so, then what kunigami_ said, recompile, and test.c should get built
11:24.14brlcadif you used autotool, edit src/libged/Makefile.am, then recompile
11:32.16abhi2011umm no i nstalled brlcad from the rpm
11:32.32abhi2011so should i build brlcad from source ?
11:32.51abhi2011is there no way to compile plugins without compiling all of brlcad ?
11:39.30tharis20in the features request tracker there are some marked open which are already solved
11:41.41brlcadabhi2011: have you ever worked with open source (development) before?
11:42.00brlcadtharis20: yeah, they've not been reviewed in a little while, couple months out of sync
11:42.33brlcadbetter are the BUGS and TODO files in the source code, or run the tools until you encounter an issue
11:44.00tharis20I was reading them so that I could choose one to try to implement and I was always "Ok, I don't understand this... isn't this already implemented? No, otherwise it would be closed. It's probably me not understading..."
11:44.01brlcadabhi2011: you can compile plugins without compiling all of brlcad but if it's not obvious how to do that, then you should build the package from source
11:44.12abhi2011well i have installed open source software before and I know how to compile softwares from source
11:44.27abhi2011but no i havent actually worked on an open source project
11:45.27brlcadwe make compiling brl-cad about as simple as it gets, especially for a package this big, including adding additions -- but yes, you could set up your own build module outside our build system if you wanted using whatever tools you like
11:45.55brlcadit's just a lot easier to explain the integrated approach and socis will be entirely focused on an integrated approach anyways
11:46.16abhi2011ok yes, I am fine with that
11:46.32abhi2011so by the integrated approach you mean using cmake right ?
11:46.40brlcadfwiw, stand-alone development is highly frowned upon around here, we all work together so there should be no hesitation to add to the core
11:46.41abhi2011using cmake to build brlcad from source ?
11:46.51brlcadcmake or autotools
11:46.55brlcadwe have two major build systems
11:47.10brlcadautotools is the older more established, but we're in the process (right now) replacing it with a cmake build
11:47.45abhi2011yes of course..I do not want to do stand-alone development, i want to do this with the community :)
11:47.47brlcadevery major feature we remove, though, goes through a proper deprecation removal process so it's not just yanked out from under our users
11:48.09brlcadso autotools is now considered deprecated, and in a few months there will be only cmake
11:48.16abhi2011ok
11:48.30abhi2011all I want to do is learn how to make plugins in brlcad
11:48.41brlcadbut in the time being, either/both work (and if you make it into socis, you'd be expected to update both)
11:48.42abhi2011so I can move on to real development of the physics
11:48.58abhi2011ok yes i understand
11:49.53brlcadlike I said yesterday, we have at least a dozen different concepts of a plugin and they all get hooked in differently -- for libged commands, it's (not necessary, but) easiest to just add to the existing build
11:50.07brlcadtharis20: which feature?
11:50.38brlcadabhi2011: have you looked over http://brlcad.org/wiki/Summer_of_Code/Checklist ?
11:50.49tharis20brlcad: fbclear, for example
11:51.11brlcadlink?
11:51.38abhi2011ah no not yet. right I ll have a look
11:52.09tharis20http://sourceforge.net/tracker/?func=detail&aid=3238193&group_id=105292&atid=640805
11:52.27tharis20this one also http://sourceforge.net/tracker/?func=detail&aid=3279756&group_id=105292&atid=640805
11:52.41brlcadtharis20: as far as I know, mged doesn't sport an fbclear command still
11:53.27brlcadthe latter for the mater command was a bug and is fixed
11:53.49tharis20I thought it did, in the Introduction to MGED, it mentions this command
11:53.53tharis20let me check again
11:54.27brlcadtheres a gui fbclear button
11:54.29brlcadbut no command
11:56.07tharis20is the function of the wanted command the same of the button?
11:57.14abhi2011ok I have a question about the Application requirements for SOCIS
11:57.39abhi2011so is submitting a patch required for being accepted
12:05.00abhi2011right I have read through the requirements
12:07.33abhi2011To write a successful propsal, I am trying to compile brlcad from source and write a basic plugin
12:09.54abhi2011given the tight timeline for SOCIS, how strictly will the acceptance requirements be followed ?
12:10.24abhi2011especially submitting a patch within the short timeframe would be really tight
12:11.25``Erikthe patch is just to prove that you can compile the code, follow the coding guidelines in the HACKING file and interface with subversion, it doesn't have to be a major change
12:18.29abhi2011ok I understand...right  I ll get on it
12:29.33tharis20if there's an app doing something and I just want to make a command that uses that app, what's the best approach?
12:30.46tharis20system call to that app (I don't think that's a good idea), although the GUI uses it or copying and pasting that part that matters of the code of the original app, or ?
12:37.52*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-187-000.wlan.tudelft.nl)
13:12.56tharis20besides adding a line in setup.c, editing src/libged/Makefile.am, what else do I need to do to compile with a new command? is there anything else I need to update?
13:16.33kunigami_tharis20: I think it's enough. Have you tried compiling with these changes?
13:17.03tharis20yes, and I always get that the function is undeclared
13:19.55kunigami_paste the error in a patebin, http://paste.ubuntu.com/, for example
13:22.15tharis20http://pastebin.com/7pBuvvhJ
13:23.28tharis20I've also noticed that in libged there's no fbclear.o or fbclear.lo
13:53.01*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
13:56.08CIA-62BRL-CAD: 03erikgreenwald * r45564 10/brlcad/trunk/src/libbu/bomb.c: fix signed/unsigned warning
14:06.33*** join/#brlcad tharis20_ (~tharis@bl21-60-39.dsl.telepac.pt)
14:06.57tharis20_brlcad: can you help me? ^
14:48.43brlcadtharis20: if it were, there wouldn't be the need for an fbclear command ;)
14:48.56brlcadit calls through some private api to clear the framebuffer
14:49.46brlcadabhi2011: the patch doesn't have to be related to your project proposal, it can be anything -- the point as ``Erik mentioned is to show competency
14:50.36abhi2011ok yes. I am compiling the brlcad source now from the instructions in INSTALL.cmake file
14:51.18brlcadso the better your patch, the better your proposal, but even a one-line patch that fixes a hard bug can be as amazing or more than a 1000 line patch that implements some new feature
14:51.28tharis20brlcad: so, the button fbclear doesn't do the same as the command of the feature request
14:51.46brlcadtharis20: it does the desired operation
14:52.00brlcadbut you can't use the api that the button uses for the command
14:52.14brlcadthey're in different sections of code
14:52.23tharis20but the command calls the application fbclear through a system call
14:52.38brlcadyes, it eventually gets to that
14:52.39tharis20*the button
14:52.54brlcadthat's kinda lame for a command
14:53.05abhi2011right i understand, thanks brlcad
14:53.37brlcadit's just as much logic to set up a connection to fork/exec the fbclear binary as it is to open a connection to the framebuffer and issue a clear command
14:53.53tharis20exactly, that's why I asked what's the best way, trying to avoid the system call
14:53.53brlcadprobably < 20 lines of code
14:54.13brlcadbasically, the guts to the fbclear command, with some simplification
14:54.21brlcads/command/tool/
14:54.54tharis20ok, I created a fbclear.c in src/libged
14:55.06tharis20and added it to Makefile.am
14:55.29brlcadthe issue in terms of encapsulation is that there "shouldn't" be a direct call into libfb from libged
14:55.44tharis20what else do I need to do so that when I compile, mged will recognize the command?
14:55.49brlcadso you shouldn't just call fb_clear() .. it should get passed in through the struct ged
14:56.10brlcadyou'll need to add a binding for the function in src/mged/setup.c
14:56.22tharis20yes, I also did that
14:58.32brlcadfwiw, calling the binary would be better than calling the libfb api directly if you can't figure out how to get to the framebuffer through the struct ged
14:59.17brlcad(ged_fbsp)
15:00.02brlcadtharis20: pastebin.com is the worst pastebin service out there and inaccessible to many of us (network blocked)
15:00.06tharis20I'm calling the binary src/fb/fbclear
15:00.20brlcadif you have a declaration problem, that means what?
15:00.41tharis20http://pastebin.ubuntu.com/649203/
15:01.10tharis20that means I'm not including something, I guess
15:01.12brlcadso what does that error mean?
15:01.21brlcadnot exactly
15:01.28brlcadit means something isn't declared
15:01.47brlcadand it tells you exactly what's not declared
15:01.56brlcadso you just need to find where declarations go
15:05.46tharis20ok, so now it's the linker giving an error
15:05.56tharis20since fbclear.c was not compiled
15:06.58CIA-62BRL-CAD: 03brlcad * r45565 10/brlcad/trunk/src/libbu/bomb.c: strlen() returns and write() takes a size_t, so keep the higher precision as far as we can even through write() requires the stupid return type
16:32.15*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
17:16.52brlcad``Erik:
17:16.53brlcadsimd.c:29: error: can't find a register in class 'BREG' while reloading 'asm'
17:47.34*** join/#brlcad Stattrav (~Stattrav@117.192.147.252)
17:47.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:31.32kunigami_question on calculating the visibility of the light: if the normal of the surface points in the same "direction" of the light, then that light is not visible. In this case the function light_obs returns early without setting sw_visible to NULL
18:32.18kunigami_I made a test. In the following image, whenever there's a visible light in the given point, I shade it white. look the result
18:32.53kunigami_http://dl.dropbox.com/u/1399996/GSoC/light_obs.png
18:35.21kunigami_this also seem to be the cause of the strange behavior of the toon shader: http://dl.dropbox.com/u/1399996/GSoC/toon_result.png
18:36.00kunigami_look how the blue light seems to be casting a shadow in the portion that should be illuminated by the yellow one
18:36.51kunigami_without the blue light: http://dl.dropbox.com/u/1399996/GSoC/toon_result_2.png
18:42.50*** join/#brlcad Stattrav (~Stattrav@117.192.147.252)
18:42.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:52.40*** join/#brlcad Stattrav (~Stattrav@117.192.147.252)
18:52.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:08.44*** join/#brlcad Stattrav (~Stattrav@117.192.147.252)
19:08.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:12.29*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:09.28kunigami_strange... the result is still this image http://dl.dropbox.com/u/1399996/GSoC/toon_result.png even when I initialize sw_visible to NULL (before calling light_obs).
20:10.03kunigami_the problem is only solved when I replace sw_tolight by sw_tolight + 3*i (as mentioned yesterday)
20:10.59kunigami_http://dl.dropbox.com/u/1399996/GSoC/toon_result_3.png
20:12.13kunigami_I'm not really sure if my changes are the right ones to do. I'll send an email to dev-list asking for a review
20:32.24*** join/#brlcad Stattrav (~Stattrav@117.192.147.252)
20:32.25*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:39.51*** join/#brlcad Stattrav (~Stattrav@117.192.147.252)
20:39.51*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:01.03CIA-62BRL-CAD: 03bhinesley * r45566 10/brlcad/trunk/src/libged/edit.c:
21:01.04CIA-62BRL-CAD: added detection of objects without slashes, nullified dangling
21:01.04CIA-62BRL-CAD: pointers, misc cleanup
21:07.03brlcadkunigami_: the toon shader is very new, might just have some bugs
21:08.21brlcad``Erik wrote it, best to ask him
21:08.53brlcadfrom your images, looks like it is a bug, but not familiar with that shader myself
21:12.03``Erikshould probably eventually finish that shader
21:20.04CIA-62BRL-CAD: 03erikgreenwald * r45567 10/brlcad/trunk/src/libbu/simd.c: ia32 seems to be unhappy about trying to address ebx at all in PIC mode, so simplify by completely duplicating the asm section to contain all the specialisms
21:22.13brlcadbuild succeeded here
21:22.41``Erikyeah, i386 PIC asm code confuses gcc
21:24.58CIA-62BRL-CAD: 03brlcad * r45568 10/brlcad/trunk/TODO: reports of crashes. red with multiple blank lines and illuminate+Z.
21:36.55*** join/#brlcad Elrohir (~kvirc@p5B14A10B.dip.t-dialin.net)
23:10.44*** join/#brlcad Stattrav_ (~Stattrav@117.192.135.247)
23:15.46*** join/#brlcad Stattrav (~Stattrav@117.192.134.79)
23:15.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
23:31.08CIA-62BRL-CAD: 03r_weiss * r45569 10/brlcad/trunk/src/libbn/plane.c:
23:31.09CIA-62BRL-CAD: Updated the prototype version of function bn_isect_line_lseg and
23:31.09CIA-62BRL-CAD: bn_isect_line3_line3_new within the libbn library within file plane.c. These
23:31.09CIA-62BRL-CAD: changes are disabled by default. These functions support the prototype function
23:31.09CIA-62BRL-CAD: nmg_triangulate_fu. Made changes to code logic and performed code cleanup. This
23:31.09CIA-62BRL-CAD: is a work in progress.
23:56.23CIA-62BRL-CAD: 03r_weiss * r45570 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c:
23:56.23CIA-62BRL-CAD: Updated function nmg_radial_build_list within file nmg_fuse.c. These changes
23:56.23CIA-62BRL-CAD: support the prototype version of nmg_triangulate_fu. This change corrects a
23:56.23CIA-62BRL-CAD: problem when the edge radial pointers are not already sorted. These changes are
23:56.23CIA-62BRL-CAD: disabled by default. This is a work in progress.
IRC log for #brlcad on 20110722

IRC log for #brlcad on 20110722

00:04.40CIA-62BRL-CAD: 03r_weiss * r45571 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c:
00:04.40CIA-62BRL-CAD: Updated function class_eu_vs_s within file nmg_class.c. This change supports the
00:04.40CIA-62BRL-CAD: prototype version of nmg_triangulate_fu. Made a logic change which stops the
00:04.40CIA-62BRL-CAD: error message "class_eu_vs_s: classifier found edge midpoint ON, edge topology
00:04.40CIA-62BRL-CAD: should have been shared" when performing nmg boolean operations such as when
00:04.40CIA-62BRL-CAD: running the mged 'facetize' or 'ev' commands. This change is disabled by
00:04.40CIA-62BRL-CAD: default. This is a work in progress.
00:56.45*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
01:26.12*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
01:31.58*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
02:07.24*** join/#brlcad piksi (piksi@pi-xi.net)
02:08.49*** join/#brlcad Stattrav_ (~Stattrav@117.192.152.228)
05:06.09brlcadstarseeker: thanks for the pointer to look at search
05:06.26brlcadit actually doesn't perform group globbing, but it calls a function I'd forgotten about
05:06.48brlcadcalls bu_fnmatch, which is a poorly named function that performs globbing on a single string item
05:07.00brlcadso I can use it while iterating over all items
05:25.10*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
06:42.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:58.18*** join/#brlcad Stattrav_ (~Stattrav@117.192.137.7)
07:46.22*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:59.24CIA-62BRL-CAD: 03bhinesley * r45572 10/brlcad/trunk/src/libged/edit.c: (log message trimmed)
07:59.24CIA-62BRL-CAD: Implemented mechanism for reading multiple subarguments per option and lists of
07:59.24CIA-62BRL-CAD: arguments for edit subcommands. Objects are currently the only type of argument
07:59.24CIA-62BRL-CAD: supported, but the logic to add additional parsing capabilities is in place.
07:59.24CIA-62BRL-CAD: Generic option handling works fairly well now, and provides good feedback to the
07:59.25CIA-62BRL-CAD: user about bad option/argument combinations as well as possible without knowing
07:59.26CIA-62BRL-CAD: the syntax of a given command. The syntax of -k/-a/-r options and -x/-y/-z
08:57.16*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
08:57.49pawleeqhello
09:02.18pawleeqI am trying to compile svn version on Ubuntu 11.04 and I fail with this message: http://pastebin.com/kf4GtZ3T
09:11.54d_rossbergzoom.c was moved recently, maybe you should update your makefiles (configure) or use the cmake build
09:14.49*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:17.33*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
09:17.33pawleeqd_rossberg: I was configuring the build as it is written in instructions (autogen, configure)
09:18.57d_rossbergpawleeq: but when? before or after your last svn update
09:25.18*** join/#brlcad Stattrav (~Stattrav@117.192.132.143)
09:25.18*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:28.52pawleeqd_rossberg: no, after
09:31.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:37.00*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:45.21*** join/#brlcad Stattrav (~Stattrav@117.202.17.197)
09:45.21*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:55.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:08.58*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
10:16.38brlcadpawleeq: but you had a pre-existing checkout, yes?
10:17.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:17.40brlcadthat looks like a message from the automake dependency tracking code, which doesn't get regenerated through autogen/configure
10:18.01pawleeqbrlcad: yeah i had
10:18.02brlcadrm -rf src/libged && svn up src/libged
10:18.14brlcadthen rebuild
10:19.03pawleeqthx, I will let you know
10:21.12*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
10:22.31*** join/#brlcad Stattrav (~Stattrav@117.192.143.98)
10:22.31*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:27.35*** join/#brlcad Stattrav_ (~Stattrav@117.192.144.16)
10:32.41*** join/#brlcad Stattrav (~Stattrav@117.213.185.180)
10:32.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:38.15starseekerbrlcad: I believe the fnmatch name came from http://pubs.opengroup.org/onlinepubs/009695399/functions/fnmatch.html, which is probably what the original find code was calling - it probably is a bad name now that we aren't matching filenames specifically with it anymore
10:38.38starseekerI suspect it was "find code needs this, not on windows, make a libbu version" or some such
10:48.50*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:16.56*** join/#brlcad Stattrav_ (~Stattrav@117.192.136.236)
11:28.32*** join/#brlcad Stattrav (~Stattrav@117.192.144.178)
11:28.32*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:13.01``Erik"test whether a filename or pathname matches a shell-style pattern" sounds awfully korn/posix2 related to me
12:28.36CIA-62BRL-CAD: 03d_rossberg * r45573 10/brlcad/trunk/include/ (config_win.h config_win_cmake.h): S_IRWXU for Windows (MS Visual Studio)
12:51.35*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
13:10.05pawleeqbrlcad: sorry for such a late reply, but it worked all right, thank you again :)
13:30.34*** join/#brlcad abhi2011_ (~chatzilla@wlan-145-94-187-000.wlan.tudelft.nl)
13:32.42*** join/#brlcad abhi2011_ (~chatzilla@wlan-145-94-187-000.wlan.tudelft.nl)
13:41.19CIA-62BRL-CAD: 03erikgreenwald * r45574 10/brlcad/trunk/src/libged/edit.c: GCC 4.1 has a bug where a variable set in every condition of a switch still registers as possibly uninitialized, so set it to 0 on definition (seen on rhel5).
14:01.24*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
16:04.07brlcadstarseeker: I know bu_fnmatch() comes from fnmatch() ... it's an old bsd function, and defined by posix
16:04.26brlcadit's just a bad function name, because it's not actually specific to file names
16:04.47brlcadpawleeq: no problem
16:15.30*** join/#brlcad Stattrav (~Stattrav@122.178.240.221)
16:15.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:40.59CIA-62BRL-CAD: 03bhinesley * r45575 10/brlcad/trunk/src/libged/edit.c: initialize variable to default before switch, rather than setting in every case
17:43.17CIA-62BRL-CAD: 03bhinesley * r45576 10/brlcad/trunk/src/libged/edit.c: var probably still needs to be initialized when defined to prevent compiler warnings
18:33.37*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
18:41.35CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3022 10/wiki/ESA_Summer_of_Code_in_Space:
18:55.13CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3023 10/wiki/Community_Publication_Portal: /* Sean Morrison: ESA Summer of Code in Space */ fill out detail
18:57.19CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3024 10/wiki/Community_Publication_Portal: final review
18:58.20CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3025 10/wiki/Community_Publication_Portal: put in right section, done
19:23.22*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
19:27.02CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3026 10/wiki/Community_Publication_Portal: not really frozen, apparently -- found bugs during post
19:56.40*** join/#brlcad tharis20 (~tharis@bl12-21-147.dsl.telepac.pt)
19:57.25tharis20hello
20:31.02*** join/#brlcad epileg (~epileg@unaffiliated/epileg)
22:30.32*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
IRC log for #brlcad on 20110723

IRC log for #brlcad on 20110723

00:32.04abhi2011hi
00:32.12abhi2011I am trying to compile brlcad
00:32.23abhi2011apparently I do not have many libraries installed
00:32.37abhi2011here is the output after compile
00:33.45abhi2011http://bin.cakephp.org/view/1775318086
00:34.35abhi2011i am trying to install the optimized version , the command is as given in  INSTALL.cmake
00:34.53abhi2011cmake ../brlcad-X.Y.Z -DBRLCAD-ENABLE_OPTIMIZED=ON
00:38.40abhi2011i am installing the packages one by one now
01:04.34kunigami_if you're building from source. probably the dependencies are already there. try using -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON parameter too
01:19.18abhi2011ok
01:20.06abhi2011well i installed and updated quite a few libraries before i saw this :P
01:20.17abhi2011now its finaly succeeded
01:20.25abhi2011will try to make now
01:23.53abhi2011hmm ran into an error while building
01:23.58abhi2011[  3%] Building C object src/libbu/CMakeFiles/libbu.dir/malloc.c.o
01:23.59abhi2011[  3%] Building C object src/libbu/CMakeFiles/libbu.dir/mappedfile.c.o
01:24.00abhi2011/home/abhi/brlcad/src/libbu/mappedfile.c: In function ‘bu_open_mapped_file’:
01:24.02abhi2011/home/abhi/brlcad/src/libbu/mappedfile.c:237:5: error: the comparison will always evaluate as ‘true’ for the address of ‘bu_mapped_file_list’ will never be NULL [-Werror=address]
01:24.04abhi2011cc1: all warnings being treated as errors
01:24.06abhi2011make[2]: *** [src/libbu/CMakeFiles/libbu.dir/mappedfile.c.o] Error 1
01:24.07abhi2011make[1]: *** [src/libbu/CMakeFiles/libbu.dir/all] Error 2
01:24.08abhi2011make: *** [all] Error 2
01:24.16abhi2011this is from code checked out from trunk
01:25.01abhi2011probably have to turn warnings as errors off ?
01:31.52abhi2011here is the build log
01:31.54abhi2011http://bin.cakephp.org/view/1072403513
02:24.18brlcadstarseeker: is the automatic detection not set up in cmake?  e.g., in his build log it fails on termlib (but that's obviously something we provide)
02:26.11brlcadabhi2011: that strictness failure is due to a recent code change.  you can/should turn Werror off (or fix the warning)
02:29.40abhi2011ok
02:31.44brlcadsee if this fixes it
02:32.53CIA-62BRL-CAD: 03brlcad * r45577 10/brlcad/trunk/include/bu.h: cast the BU_ASSERT pointers through void* in order to hopefully get past the compiler (correctly) warning that the comparison will always evaluate as true.
02:40.31*** join/#brlcad tharis20 (~tharis@bl21-50-118.dsl.telepac.pt)
02:46.56abhi2011ok..so I should turn compiler warning off, or should I try to cast the BU_ASSERT pointers through void*
03:00.34abhi2011ok is there a particular cmake file which has the compiler flags ?
03:00.46abhi2011I have been searching in the files but havent found one yet
03:00.49abhi2011i ll try find
03:08.13abhi2011hmm i found it in brlcad/misc/CMake/CompilerFlags.cmake
03:08.45abhi2011seems like I should turn off the BRLCAD-ENABLE_STRICT flag
03:14.30abhi2011ok I set brlcad/CMakeLists.txt , line 708 to OFF
03:14.46abhi2011# Enable/disable strict compiler settings - these are limited to libraries that
03:14.48abhi2011# specifically inform the BRLCAD_ADDLIB macro they can be built with STRICT flags.
03:14.49abhi2011OPTION(BRLCAD-ENABLE_STRICT "Use strict compiler settings on libraries that support them" OFF)
03:15.30abhi2011this should turn off the  warnings as errors
03:16.34abhi2011hmmm...thats didnt work
04:32.40bhinesleyabhi2011: he tried to patch it, the channel just echoed his commit; you should run `svn update` and see if your warning is gone.
04:33.11bhinesleyotherwise, just try something like `cmake -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DBRLCAD-ENABLE_STRICT=OFF`
04:33.15bhinesley`
04:34.22bhinesley(er rather, the bot CIA-62 echoed his commit)
06:42.45*** join/#brlcad colin_ (~colin@114-37-169-197.dynamic.hinet.net)
07:23.29*** part/#brlcad colin_ (~colin@114-37-169-197.dynamic.hinet.net)
11:18.05``Erikhm, fbsd is conservative with setting __SSE__, it wants an -msse3 flag passed... is there cmake fu to make that happen?
11:28.42abhi2011Scanning dependencies of target htester
11:28.44abhi2011[  4%] Building C object src/libbu/CMakeFiles/htester.dir/htester.c.o
11:28.45abhi2011/home/abhi/brlcad/src/libbu/htester.c: In function ‘main’:
11:28.47abhi2011/home/abhi/brlcad/src/libbu/htester.c:68:9: error: variable ‘ret’ set but not used [-Werror=unused-but-set-variable]
11:28.49abhi2011cc1: all warnings being treated as errors
11:28.50abhi2011make[2]: *** [src/libbu/CMakeFiles/htester.dir/htester.c.o] Error 1
11:28.52abhi2011make[1]: *** [src/libbu/CMakeFiles/htester.dir/all] Error 2
11:28.53abhi2011make: *** [all] Error 2
11:28.55abhi2011i ll try the -DBRLCAD-ENABLE_STRICT=OFF`
11:29.15*** part/#brlcad epileg (~epileg@unaffiliated/epileg)
11:58.22*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
12:03.15*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
12:03.29*** join/#brlcad Stattrav (~Stattrav@117.192.150.58)
12:03.29*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:05.35CIA-62BRL-CAD: 03brlcad * r45578 10/brlcad/trunk/src/libbu/htester.c: newer gcc 4.6 is smarter, have to actually use the return value.
14:05.39brlcadabhi2011: that commit should fix htester.c
14:07.07brlcadnewer compiler just came out less than a month ago that is better and producing/detecting more warning issues, so they're new issues that haven't been fixed yet
14:08.00brlcadwe default to not only treating all warnings as errors but having the compiler report almost every error that it's capable of reporting, way more than the default used by others
14:09.19brlcadso you can keep reporting them and someone will fix them or just turn the strictness off with -DBRLCAD-ENABLE_STRICT=OFF
14:10.12brlcadstarseeker: those define sames are like nails on chaulkboard -- can they be all underscores or all dashes?  the mix is just asking for usability woe
14:10.26brlcads/sames/names/
14:22.23abhi2011right ok
14:23.07abhi2011hmm got one more  :) !!
14:23.11abhi2011Linking C executable ../../bin/g-var
14:23.13abhi2011/usr/bin/ld: CMakeFiles/g-var.dir/g-var.c.o: undefined reference to symbol 'sin@@GLIBC_2.0'
14:23.15abhi2011/usr/bin/ld: note: 'sin@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line
14:23.16abhi2011/lib/libm.so.6: could not read symbols: Invalid operation
14:23.18abhi2011collect2: ld returned 1 exit status
14:23.20abhi2011make[2]: *** [bin/g-var] Error 1
14:23.22abhi2011make[1]: *** [src/conv/CMakeFiles/g-var.dir/all] Error 2
14:23.23abhi2011make: *** [all] Error 2
14:24.12abhi2011math library flag
14:24.32abhi2011or something related i think
14:28.38abhi2011about 41% of the build is done
15:37.06CIA-62BRL-CAD: 03brlcad * r45579 10/brlcad/trunk/src/conv/CMakeLists.txt: add to all of the executables that make direct calls to sin()/cos(). report of build failure from abhi2011 via irc on linux, gcc 4.6, where the implicit attempt to add it automatically results in an ld failure.
15:37.28abhi2011cool!
15:37.34abhi2011will try now
15:38.29abhi2011So what exactly got added
15:39.50brlcadwell, exactly http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/conv/CMakeLists.txt?r1=45069&r2=45579
15:39.56brlcadthere's now an explicit link for -lm for those binaries
15:40.34brlcadshould not be needed as it's already prescribed elsewhere, but something appears to be wrong on your system with ld or /lib/libm.so.6
15:41.19abhi2011ok
15:41.28brlcadadding it explicit may just get past whatever that issue is and is harmless in the build file otherwise for others
15:41.38abhi2011right ok
15:49.54abhi2011Scanning dependencies of target enf-g
15:49.56abhi2011[ 41%] Building C object src/conv/CMakeFiles/enf-g.dir/enf-g.c.o
15:49.57abhi2011Linking C executable ../../bin/enf-g
15:49.59abhi2011/usr/bin/ld: CMakeFiles/enf-g.dir/enf-g.c.o: undefined reference to symbol 'sqrt@@GLIBC_2.0'
15:50.00abhi2011/usr/bin/ld: note: 'sqrt@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line
15:50.02abhi2011/lib/libm.so.6: could not read symbols: Invalid operation
15:50.04abhi2011collect2: ld returned 1 exit status
15:50.05abhi2011make[2]: *** [bin/enf-g] Error 1
15:50.07abhi2011make[1]: *** [src/conv/CMakeFiles/enf-g.dir/all] Error 2
15:50.08abhi2011make: *** [all] Error 2
15:50.10abhi2011same issue, different place
16:13.18CIA-62BRL-CAD: 03brlcad * r45580 10/brlcad/trunk/src/conv/CMakeLists.txt: more needed for sqrt()
16:36.39abhi2011[ 17%] Building C object src/rt/CMakeFiles/rtray.dir/viewray.c.o
16:36.41abhi2011Linking C executable ../../bin/rtray
16:36.42abhi2011/usr/bin/ld: CMakeFiles/rtray.dir/worker.c.o: undefined reference to symbol 'sin@@GLIBC_2.0'
16:36.44abhi2011/usr/bin/ld: note: 'sin@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line
16:36.45abhi2011/lib/libm.so.6: could not read symbols: Invalid operation
16:36.47abhi2011collect2: ld returned 1 exit status
16:36.48abhi2011make[2]: *** [bin/rtray] Error 1
16:36.50abhi2011make[1]: *** [src/rt/CMakeFiles/rtray.dir/all] Error 2
16:36.52abhi2011make: *** [all] Error 2
17:13.44*** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net)
17:39.28abhi2011Linking C executable ../../bin/rtray
17:39.29abhi2011/usr/bin/ld: CMakeFiles/rtray.dir/worker.c.o: undefined reference to symbol 'sin@@GLIBC_2.0'
17:39.31abhi2011/usr/bin/ld: note: 'sin@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line
17:39.33abhi2011/lib/libm.so.6: could not read symbols: Invalid operation
17:39.35abhi2011collect2: ld returned 1 exit status
17:39.37abhi2011make[2]: *** [bin/rtray] Error 1
17:39.38abhi2011make[1]: *** [src/rt/CMakeFiles/rtray.dir/all] Error 2
17:39.40abhi2011make: *** [all] Error 2
18:00.11*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
19:35.11CIA-62BRL-CAD: 03brlcad * r45581 10/brlcad/trunk/src/rt/CMakeLists.txt: more ${M_LIBRARY} additions to accommodate some front-end calls to sin()/cos()
19:45.23abhi2011cool!
19:45.42brlcadthere are undoubtedly a lot more places that will need to be propagated
19:48.41abhi2011ok
19:49.12abhi2011cant this be automated
19:49.39abhi2011like for all binaries like the rtray
19:50.10abhi2011ok 42% now
19:50.13abhi2011Linking C shared library ../../lib/libtclcad.so
19:50.15abhi2011[ 42%] Built target libtclcad
19:50.16abhi2011Linking C executable ../../bin/asc2g
19:50.18abhi2011/usr/bin/ld: CMakeFiles/asc2g.dir/asc/asc2g.c.o: undefined reference to symbol 'sqrt@@GLIBC_2.0'
19:50.20abhi2011/usr/bin/ld: note: 'sqrt@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line
19:50.21abhi2011/lib/libm.so.6: could not read symbols: Invalid operation
19:50.23abhi2011collect2: ld returned 1 exit status
19:50.25abhi2011make[2]: *** [bin/asc2g] Error 1
19:50.26abhi2011make[1]: *** [src/conv/CMakeFiles/asc2g.dir/all] Error 2
19:50.27abhi2011make: *** [all] Error 2
19:50.36brlcadonly thing I can think of is you're using some older version of cmake or there is something wrong with your ld setup
19:51.08abhi2011hmm ok
19:51.09brlcadotherwise, there's no way to automate the fix for sure
19:51.28abhi2011its a straight fedora 15 install
19:51.43abhi2011no changes to ld etc
19:51.59brlcadright, but it gets back to the earlier ld fishyness too
19:52.09abhi2011yeah
19:52.14brlcadsomething is still different, whether intentional or not
19:53.12brlcadthere are 400 binaries in brl-cad, so at least that many opportunities to hit this issue
19:53.41brlcadone thing you could do would be to compile with "make -k 2>&1 | tee build.log"
19:54.09brlcadthen you can post that build log up some place, it should get further than one at a time
19:54.58abhi2011ok right I ll do that
19:57.40CIA-62BRL-CAD: 03brlcad * r45582 10/brlcad/trunk/src/conv/ (CMakeLists.txt iges/CMakeLists.txt): more -lm propagation
20:08.36*** join/#brlcad tharis20_ (~tharis@2.82.61.33)
20:43.11*** join/#brlcad Stattrav (~Stattrav@117.192.137.215)
20:43.11*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:48.11*** join/#brlcad Stattrav_ (~Stattrav@117.192.138.138)
20:51.12abhi2011right the build is done
20:53.20abhi2011i ll post the build log in the mailing list
20:53.57brlcadNuuuo
20:54.09brlcadjust post it to some file sharing service
20:54.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:54.25brlcadhow long is it?
21:01.44*** join/#brlcad Stattrav (~Stattrav@117.192.138.89)
21:01.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:01.48abhi201110.6 mb
21:02.00abhi2011when compressed just 400 kb
21:02.54abhi2011sent on the mailing list
21:03.07abhi2011may I know what is the preferred platform for building brlcad
21:03.46abhi2011i would like to finish building brlcad soon and move on development as the ESA SOCIS deadline is coming up fast :)
21:08.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:14.30*** join/#brlcad Stattrav (~Stattrav@117.192.138.89)
21:14.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:24.02*** join/#brlcad Stattrav (~Stattrav@117.192.138.89)
21:24.03*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
21:31.21brlcadabhi2011: there isn't really a preferred platform, we continuously build on a variety of platforms including linux (rh, gentoo, ubuntu, ...), freebsd, mac os x, windows, and occasionally even on haiku, solaris, openbsd, ...
21:31.37brlcadthe issues you're running into are not common, to say the least
21:32.04brlcadthe only other suggestion I could make would be to try the autotools build instead of the cmake build (from a fresh checkout) to see if it works better for you
21:32.23brlcad./autogen.sh && ./configure --enable-all && make
21:33.10abhi2011right ok
21:37.02brlcadmm, 95% of that build log is just src/conv/step blathering warnings for autogenerated code (which we don't care about, won't fix)
21:37.55brlcadthat's more reasonable, 1mb
21:39.33brlcader, not even .. 300k, just 5k lines
21:40.07abhi2011<PROTECTED>
21:40.17abhi201179372 lines
21:41.03brlcadof which about 74300 are completely irrelevant
21:41.42abhi2011ok I ll try the autotools build, see if that resolves the issue
21:41.58brlcadif that log needs to get generated again (say after someone goes through and addresses the warnings), use: cat build.log | grep -v src/conv/step |grep -v src/other/step > build2.log
21:42.51brlcadautotools isn't going to fix the strictness warnings, so need to disable strict there too
21:42.59brlcad./autogen.sh && ./configure --enable-all --disable-strict && make
21:43.37brlcadit detects and links libraries in a very different way, though, so might get past the math library issues
21:44.27*** join/#brlcad Stattrav_ (~Stattrav@117.192.131.139)
21:54.34abhi2011right ok
21:55.31abhi2011and as backup...does brlcad have a smooth build on fedora 10 ?
21:55.57abhi2011like I am looking for any other platform in which brlcad is known to have a smooth build
21:57.03brlcadwhat are your options?
21:57.14abhi2011i can try opensuse various versions
21:57.19abhi2011or fedora 10 to 14
21:57.40abhi2011well any free distro really :)
21:58.10brlcadwell we've certainly built on fedora and opensuse before
21:58.33brlcadthe compilation warnings are a non-issue, because they can be disabled -- and are specific to gcc 4.6
21:58.45abhi2011ok
21:58.57abhi2011yes i am trying with autotools now
21:59.41brlcadthe linker problem is the first I've seen of that so hopefully the autotools build will get past it
22:01.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:11.29*** join/#brlcad Stattrav (~Stattrav@117.192.131.139)
22:11.30*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:21.32*** join/#brlcad Stattrav (~Stattrav@117.192.131.139)
22:21.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:45.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:56.45*** join/#brlcad Stattrav (~Stattrav@117.192.143.63)
22:56.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
23:01.43*** join/#brlcad Stattrav_ (~Stattrav@117.192.138.30)
23:10.17abhi2011well the autotools build is still running, i hope there is a way to just build plugins for mged separately rather than have to build all of brlcad to test them
IRC log for #brlcad on 20110724

IRC log for #brlcad on 20110724

00:37.16abhi2011autotools build succeded - took 1 hour
00:47.52*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
01:41.38*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
01:57.30brlcadabhi2011: glad to hear it, so the latter linkage issue is more likely build system related -- cmake is new
01:57.57brlcadabhi2011: and you don't have to rebuild all of brl-cad to test, you can cd to subdirs and it'll only build/rebuild what you add/change
02:07.17*** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net)
06:46.07*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
08:25.42*** join/#brlcad Calin (~Calin@109.99.20.242)
09:57.01*** join/#brlcad Stattrav (~Stattrav@117.192.132.247)
09:57.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:03.25*** join/#brlcad Stattrav_ (~Stattrav@117.192.130.62)
10:20.31*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:48.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:56.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:05.26*** join/#brlcad Stattrav (~Stattrav@117.202.23.115)
11:05.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:20.10*** join/#brlcad Stattrav_ (~Stattrav@117.192.129.21)
11:25.07*** join/#brlcad Stattrav (~Stattrav@117.192.148.196)
11:25.07*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:30.07*** join/#brlcad Stattrav_ (~Stattrav@117.192.133.68)
11:35.10*** join/#brlcad Stattrav (~Stattrav@117.192.143.229)
11:35.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:36.58*** join/#brlcad CalinPaul (~Calin@109.99.20.242)
11:49.20*** join/#brlcad Stattrav_ (~Stattrav@117.192.156.102)
12:34.54*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:37.57*** join/#brlcad abhi2011__ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:41.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:55.44*** join/#brlcad piksi (piksi@pi-xi.net)
13:24.19*** join/#brlcad Stattrav_ (~Stattrav@117.192.151.88)
13:44.51CIA-62BRL-CAD: 03brlcad * r45583 10/brlcad/trunk/src/conv/iges/iges.c: gcc 4.6 quellage. format specifiers and set but unused vars.
13:49.24CIA-62BRL-CAD: 03brlcad * r45584 10/brlcad/trunk/CMakeLists.txt:
13:49.25CIA-62BRL-CAD: blindly forcing the FS access down to 32-bit is causing build problems for
13:49.25CIA-62BRL-CAD: environments that prescribe a different setting. getting redefinition warnings
13:49.25CIA-62BRL-CAD: aside from it feeling like a non-portable hack to start with. needs a better
13:49.25CIA-62BRL-CAD: test if zlib needs something.
13:52.40``Erikum, when I build on a certain 64b rhel machine with a cat name, it says it's dropping to 32b mode, but actually builds 64b. Between that and the fat binary issue, some serious luvin' is needed for word width
14:10.54CIA-62BRL-CAD: 03erikgreenwald * r45585 10/brlcad/trunk/TODO: add a couple config issues
14:24.34brlcadnods
14:37.05CIA-62BRL-CAD: 03brlcad * r45586 10/brlcad/trunk/src/ (17 files in 17 dirs):
14:37.05CIA-62BRL-CAD: remainder(?) of -lm propagation. used fedora build log failure report to fix
14:37.05CIA-62BRL-CAD: all instances except for libremrt. it's marked as a static lib, so unclear how
14:37.05CIA-62BRL-CAD: to specify the dependency like is done in BRLCAD_ADDLIB (and why can we not just
14:37.05CIA-62BRL-CAD: call that instead?). needs fedora retesting.
14:43.07brlcadstarseeker: these normal? or better question, how to suppress them by default:
14:43.10brlcad-- Could NOT find UTAHRLE (missing:  UTAHRLE_LIBRARY UTAHRLE_INCLUDE_DIR)
14:43.10brlcad-- Could NOT find TCL (missing:  TCL_LIBRARY TCL_TCLSH_EXECUTABLE TCL_TCLSH TCL_LIBRARY TCL_INCLUDE_PATH TCL_STUB_LIBRARY TK_INCLUDE_PATH TCL_TK_LIBRARY TCL_WISH_EXECUTABLE TK_LIBRARY TCL_TK_STUB_LIBRARY TK_STUB_LIBRARY)
14:43.14brlcad-- Could NOT find TK (missing:  TCL_TK_LIBRARY TCL_TCLSH_EXECUTABLE TCL_TCLSH TCL_LIBRARY TCL_INCLUDE_PATH TCL_STUB_LIBRARY TK_INCLUDE_PATH TCL_TK_LIBRARY TCL_WISH_EXECUTABLE TK_LIBRARY TCL_TK_STUB_LIBRARY TK_STUB_LIBRARY TCL_LIBRARY)
14:43.18brlcad-- Could NOT find OPENNURBS (missing:  OPENNURBS_LIBRARY OPENNURBS_INCLUDE_DIR)
14:43.21brlcad-- Could NOT find SCL (missing:  SCL_CORE_LIB SCL_DAI_LIB SCL_UTILS_LIB SCL_EXPRESS_EXECUTABLE)
14:54.29CIA-62BRL-CAD: 03brlcad * r45587 10/brlcad/trunk/src/conv/iges/iges.c: unused i
15:46.51abhi2011yep i got those too
16:22.53*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
17:08.24*** join/#brlcad name (~name@sburn/devel/name)
17:20.43*** join/#brlcad Calin (~Calin@109.99.20.242)
20:32.04CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3027 10/wiki/User:Abhijit: ESA Summer of Code Project Proposal for Abhijit Nandy
20:32.13abhi2011hi
20:32.33abhi2011I am preparing my project proposal for SOCIS
20:32.50abhi2011Will I insert it in my wiki page as given in the guidelines ?
20:46.12brlcadsure, that works great
20:48.11abhi2011cool
21:09.59CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3028 10/wiki/User:Abhijit: SOCIS proposal of Abhijit
21:10.10abhi2011uploaded it for initial review
21:12.16CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3029 10/wiki/User:Abhijit: /* Brief project summary */
21:23.28CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3030 10/wiki/User:Abhijit: /* Detailed project description */
22:00.26CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3031 10/wiki/User:Abhijit: Added background work so far.
22:01.23CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3032 10/wiki/User:Abhijit: /* Background work done and why I will be a good choice for the project :) */
22:15.58LainIwakuraXHello all, I've become interested in development on brlcad...so I picked up one of the tasks here: http://brlcad.org/wiki/Contributor_Quickies and completed it. Who do I talk to about next steps, etc.? This is my first time doing open source stuff, I have no idea how things work.
22:27.52CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3033 10/wiki/User:Abhijit: /* Background work done and why I will be a good choice for the project :) */
23:04.00starseekerbrlcad: yeah, those are normal
23:04.32starseekernot sure if I put a mechanism in to suppress them
23:16.35*** join/#brlcad piksi (piksi@pi-xi.net)
23:27.05abhi2011Hi I am working on moving LIBBN comments from source to header files as given here http://brlcad.org/wiki/Contributor_Quickies#VERY_EASY:_Translate_.22BRL-CAD_Overview.22_document
23:27.46abhi2011So if I understand correctly, a new header file needs to be created for every C file and the functions need to be declared there
23:34.24LainIwakuraXThe way I understood it, the functions in src/libbn/*.c have comments, but those comments should be on the function prototypes
23:34.28LainIwakuraXwhich are in bn.h
23:34.52LainIwakuraXso you shouldn't need to create a new header
23:35.26abhi2011ah ok thanks LainIwakuraX
23:35.40abhi2011so was this the one you completed :)
23:35.47LainIwakuraXno lol
23:36.04LainIwakuraXI did this: http://brlcad.org/wiki/Contributor_Quickies#MEDIUM:_Replace_SCLstring_with_std::string
23:36.08LainIwakuraXso just don't do that one ;)
23:36.34abhi2011ah ok
23:42.08LainIwakuraXI'm out for dinner, if any developer wants to talk w/ me about code review / changes I made just type something here I'll see it soon
IRC log for #brlcad on 20110725

IRC log for #brlcad on 20110725

00:16.40tharis20brlcad: can a person apply for two projects in brlcad?
00:17.10tharis20obviously, one would be working only on one of them, if he got accepted
00:38.24brlcadstarseeker: so the better question was how to suppress them by default?  they don't really convey useful information, misleading even
00:39.48brlcadLainIwakuraX: if you've completed one of them, awesome -- the first steps are generally to post a patch to the brl-cad patches tracker on sourceforge and talk to devs to get it reviewed/applied
00:40.25brlcadLainIwakuraX: the basic high-level project operations are written up in the HACKING file, linked to on the quickies page
00:41.04brlcadLainIwakuraX: and that's pretty impressive if you've replaced all of the SCLstring instances.. nice!
00:41.40abhi2011Hi brlcad, since BRL-CAD uses doxygen for documentation, is there a doxyfile in the source code  already or is one generated when needed
00:41.48brlcadthere's one in misc/
00:41.53abhi2011ok
00:42.11brlcadbut it's easy enough to recreate one as needed too
00:42.20abhi2011right ok
00:42.49brlcadI've been working on a doxyfile specific for libbu that's a little different from what's in nmisc/
00:43.02brlcadas a template for the rest, but it's still a wip
00:43.16abhi2011ok
00:43.51abhi2011regarding moving LIBBN comments from source to header files, I guess the comments on the *.c file need to be moved atop the function declarations in bu.h ?
00:44.46brlcadnope, but close
00:44.49abhi2011i.e. the files in /src/libbn/*.c
00:44.56brlcadatop the decls in bN.h ;)
00:45.05abhi2011oops yes right
00:45.29brlcadhave you ever made a patch before?
00:45.34abhi2011no
00:45.44brlcadthat's fine
00:46.01abhi2011but i understand that making the changes and testing with doxygen should not be done in the checked out svn repository
00:46.13abhi2011otherwise a diff will add the new files as weel
00:46.14brlcadbut then I suggest not attempting all files, migrate just one libbn file to the header and work on submitting it as a patch
00:46.30brlcadthere shouldn't be any new files
00:46.33abhi2011right ok
00:46.54brlcadsvn will make a patch file for you, which is basically just a special format text file
00:47.22abhi2011yes true, the thing is if I test with doxygen in the svn checked out source, then it will produce new files
00:47.34brlcadtry moving one comment from src/libbn to include/bn.h then run svn diff at the top-level -- that will output a diff of any changes you made
00:47.48abhi2011right ok
00:47.57brlcadyou can point doxygen output anywhere
00:48.11abhi2011yes ok
00:48.14brlcadthose files will get ignored by svn unless you specifically add them
00:48.28abhi2011ok cool
00:48.33brlcadthere are lots of tutorials around the net too on creating a patch file with svn
00:49.13abhi2011right. I ll try with 1 file first
00:49.20brlcadbasically, though, it's just "svn diff > my_changes.patch" .. then manually inspect the my_changes.patch file with a text editor to make sure it only includes things you intended to change
00:49.35abhi2011ok
00:49.50brlcadif it includes more, you have to svn revert the files unintentionally edited or undo the edits by hand
00:50.08abhi2011right
00:50.12brlcadthat patch file gets posted to the patches tracker, and then you get a dev to review it (in here and/or on the mailing list)
00:50.51abhi2011ok...the submission is through the web interface i guess
00:51.01abhi2011*the posting
00:51.23brlcadabhi2011: for socis, that will satisfy the "requirement" more than enough but keep in mind that shows only basic competency .. doesn't take any skill to move a comment ;)
00:52.00abhi2011yes  true :)
00:53.43abhi2011well have to start somewhere :P
00:55.06LainIwakuraXbrlcad: How do I make a patch? Like I mentioned this is my first time doing open source stuff =x
00:57.01LainIwakuraXbrlcad: Nevermind, it looks like svn diff > stuff.patch =)
01:12.06starseekerbrlcad: um.  they are conveying information in the sense that tests are actually being run to see if system versions of those libraries are available...
01:12.56starseekernot sure how they're misleading... I could add a note saying local version is being enabled for compilation...
01:19.44brlcadstarseeker: those messages were printed during make, not during cmake (this was a simple "cmake . ; make") and they're the first thing output during make
01:20.24brlcadbasically looks like a bunch of failure messages, which during make implies build failures
01:23.31LainIwakuraXPatch submitted, now I wait =P
01:23.36brlcadthe clarity of the message itself would also help .. "Could NOT find UTAHRLE" isn't true and has overemphasis, maybe "Could not find a usable system Utah Raster Toolkit, building the included one"
01:24.05brlcadLainIwakuraX: outstanding
01:58.22tharis20is there a way not to compile all brlcad stuff when modifying only 1 file?
01:59.15brlcadyes several ways, the easiest is to just cd to the dir where the change was made and make
02:01.43abhi2011submitted my basic patch :P
02:07.39abhi2011regarding the Convert BU_SETJUMP/BU_UNSETJUMP blocks into try/catch layout
02:07.54starseekerbrlcad: are you sure cmake wasn't being run first?
02:08.09starseekerrerun rather...
02:08.51abhi2011i guess a simple grep for BU_SETJUMP in src/**/*.c should reveal all places where the blocks should be replaced with try/catch layout ?
02:09.26LainIwakuraXabhi2011: "grep -H -r "BU_SETJUMP" . | grep -v svn | less"
02:09.42LainIwakuraXin an appropriately high level directory
02:09.56abhi2011nice...thanks
02:10.01abhi2011i ll grep in src
02:10.11LainIwakuraXThat's how I found SCLstring ;) lol
02:10.21abhi2011:)
02:11.31abhi2011i think better to add *.c
02:12.35LainIwakuraXYeah, in my case I had to look in header files too, but whatever works
02:13.37abhi2011right...and do you do the build in the source tree using autotools ?
02:13.48abhi2011or out of tree
02:14.16LainIwakuraXhm, last night I was just using cmake / make in the highest level
02:15.48abhi2011ok, I guess then the object files get produced in the source tree
02:16.14LainIwakuraXyeah, svn will ignore those though unless you svn add them
02:16.20abhi2011ok
02:47.06abhi2011so the code is something like this :
02:47.11abhi2011double result;
02:47.13abhi2011if (!BU_SETJUMP) {
02:47.14abhi2011<PROTECTED>
02:47.16abhi2011<PROTECTED>
02:47.18abhi2011<PROTECTED>
02:47.20abhi2011ret = 1;
02:47.21abhi2011failed_cnt++;
02:47.23abhi2011(void)fprintf(stream, "Failed function %lu test case on line %lu expected = %.15f result = %.15f\n",
02:47.25abhi2011<PROTECTED>
02:47.26abhi2011<PROTECTED>
02:47.28abhi2011success_cnt++;
02:47.30abhi2011<PROTECTED>
02:47.32abhi2011} else {
02:47.34abhi2011<PROTECTED>
02:47.36abhi2011<PROTECTED>
02:47.37abhi2011<PROTECTED>
02:47.39abhi2011<PROTECTED>
02:47.41abhi2011<PROTECTED>
02:47.42abhi2011} BU_UNSETJUMP;
02:47.44abhi2011this may be replaced by code similar to:
02:47.45abhi2011double result;
02:47.47abhi2011try{
02:47.48abhi2011<PROTECTED>
02:47.50abhi2011<PROTECTED>
02:47.51abhi2011<PROTECTED>
02:47.53abhi2011<PROTECTED>
02:47.54abhi2011<PROTECTED>
02:47.56abhi2011<PROTECTED>
02:47.57abhi2011<PROTECTED>
02:47.59abhi2011ret = 1;
02:48.01abhi2011failed_cnt++;
02:48.03abhi2011(void)fprintf(stream, "Failed function %lu test case on line %lu expected = %.15f result = %.15f\n",
02:48.05abhi2011<PROTECTED>
02:48.07abhi2011<PROTECTED>
02:48.08abhi2011success_cnt++;
02:48.10abhi2011<PROTECTED>
02:48.12abhi2011} catch( char *str ) {
02:48.13abhi2011<PROTECTED>
02:48.15abhi2011<PROTECTED>
02:48.17abhi2011<PROTECTED>
02:48.19abhi2011<PROTECTED>
02:48.20abhi2011}
02:48.22abhi2011bu_setjmp_valid=0;
02:52.03LainIwakuraXcodepad.org
02:57.23abhi2011:P.....ok
03:21.57*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
03:28.23brlcadstarseeker: it probably was, but then that is curious in itself in that the exact previous command was "cmake ."
03:28.37brlcadabhi2011: omg, dude pastebin next time
03:28.40brlcad~pastebin
03:28.40ibot[~pastebin] A "pastebin" is a web-based service where you should paste anything over 3 lines so you don't flood the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://bin.cakephp.org/ , http://asterisk.pastey.net/ , or install pastebinit with yum or aptitude.
03:30.41brlcad3 lines is a bit crazy, but more than 5 or so, definitely
03:31.26brlcadthat many lines pretty much halts the channel while it's pasting to everyone (you may see it instantly, but in reality, it ticks off about 1 line a second)
03:32.13brlcadthe task it to structure the jumps into try/catch *style*, not actual try/catch syntax .. lots of examples in the code that are converted already
03:47.12brlcadabhi2011: unless you're already familiar with C jumps (longjmp() and friends), a better use of your time would something that gets you working in libged
03:47.24brlcadlike fixing the 'analyze' command output formatting
03:49.02brlcador related, https://sourceforge.net/tracker/?func=detail&aid=2954409&group_id=105292&atid=640805 albeit a little bit harder than fixing the output formatting
03:51.41brlcador letting the cp command take multiple arguments for simultaneously creating named copies, relatively simple logic mod to a libged command
03:51.58brlcadTODO and BUGS files list dozens of potential things more apropos than the dev quickies
05:16.02*** join/#brlcad Calin (~Calin@109.99.20.242)
06:10.40*** join/#brlcad Stattrav (~Stattrav@122.167.229.132)
06:10.40*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:42.28*** join/#brlcad merzo (~merzo@193.254.217.44)
07:45.35``ErikI don't see those cmake tests run on builds, could it be that you had an ntpdate pump that shifted the time back enough to rerun cmake?
08:08.38*** join/#brlcad tharis20_ (~tharis@bl21-62-152.dsl.telepac.pt)
08:44.55abhi2011right , will take care to pastebin next time
10:09.17abhi2011by the way, I was wondering if my basic patch (id: 3376910) has a usable .diff file
10:29.22CIA-62BRL-CAD: 03Martinpaul 07http://brlcad.org * r3034 10/wiki/Main_Page:
11:04.39*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:33.41brlcadnot very likely, and I've seen it before
12:34.09brlcadabhi2011: hadn't looked yet but that's part of that process, to make sure everything is right
12:36.44starseekercmake will automatically re-run if the CMakeLists.txt files or .cmake files have been changed at all
12:37.38CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3035 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Martinpaul|Martinpaul]] ([[User talk:Martinpaul|Talk]]); changed back to last version by [[User:Sean|Sean]]
12:37.48abhi2011ok thanks brlcad
12:37.53CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Martinpaul]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
12:38.04abhi2011by the way does opengl support need to be turned on specifically for the autotools build
12:38.38abhi2011after ./configure, I always get the Build with OpenGL support as ...no
12:38.57abhi2011consequently after the compile mged does startup
12:39.03abhi2011but archer does not
12:39.47brlcadarcher requires opengl, mged does not
12:40.00starseekerin autotools opengl is off by default
12:40.14brlcadnot it's not, it's autodetect by default :)
12:40.35brlcadah, my bad
12:40.40starseekereh?
12:40.44brlcadit *was* autodetect at some point
12:40.56starseekerah :-)
12:41.08brlcadto many turn on, try, turn off doesn't work everywhere attempts
12:47.49CIA-62BRL-CAD: 03brlcad * r45588 10/brlcad/trunk/include/fb.h: log the exact same thing we tested, print what should be the magic, not a pointer
12:48.35CIA-62BRL-CAD: 03brlcad * r45589 10/brlcad/trunk/src/conv/ (bot_shell-vtk.c iges/add_loop.c): gcc 4.6 warning quellage
12:55.09CIA-62BRL-CAD: 03brlcad * r45590 10/brlcad/trunk/src/other/iwidgets/pkgIndex.tcl: should no longer be keeping pkgIndex.tcl files (and other generated files) in the repo now that the msvc files are gone
13:03.53CIA-62BRL-CAD: 03brlcad * r45591 10/brlcad/trunk/src/ (conv/bot_shell-vtk.c libbu/ptbl.c): call %zu instead of %z to be more consistent with the calls elsewhere
13:19.48CIA-62BRL-CAD: 03brlcad * r45592 10/brlcad/trunk/src/conv/ (6 files in 3 dirs): more warning quellage. use %p instead of x%x, remove unused vars, cast accordingly
13:22.27abhi2011right brlcad, so how do i turn it on in autotools
13:36.26starseeker--with-ogl
13:37.59abhi2011thanks starseeker
13:50.00CIA-62BRL-CAD: 03brlcad * r45593 10/brlcad/trunk/src/conv/dxf/dxf-g.c: remove unused variables, lots of unimplemented functionality apparently stubbed
13:55.16CIA-62BRL-CAD: 03brlcad * r45594 10/brlcad/trunk/src/conv/g-egg.c: pass ncpu down through to db_walk_tree since it's only != 1 if user specifies it. remove unused vars.
13:55.32CIA-62BRL-CAD: 03starseeker * r45595 10/brlcad/trunk/ (3 files in 2 dirs):
13:55.32CIA-62BRL-CAD: CMake will check for third party libraries every time it is run (or rather, the
13:55.32CIA-62BRL-CAD: ThirdParty.cmake macro logic will) but default to being quiet about it on
13:55.32CIA-62BRL-CAD: subsequent runs unless there's actually something to report. By the same token,
13:55.33CIA-62BRL-CAD: don't keep hammering on the build type.
13:55.54starseekerbrlcad: I think that'll take care of the messages you were seeing
14:09.39CIA-62BRL-CAD: 03brlcad * r45596 10/brlcad/trunk/src/ (17 files in 8 dirs): more gcc 4.6 quellage, eliminate set but unused variables, use void* for %p, and use %zu for size_t.
14:11.57abhi2011hmm....some other library seems missing
14:11.59abhi2011http://bin.cakephp.org/view/675147344
14:12.18abhi2011i have installed mesaGL, mesaGLU, freeglut
14:15.20CIA-62BRL-CAD: 03brlcad * r45597 10/brlcad/trunk/src/rt/ (CMakeLists.txt Makefile.am scanline.c scanline.h viewmlt.c):
14:15.20CIA-62BRL-CAD: remove rtmlt. it was never a completed nor working implementation of metropolis
14:15.20CIA-62BRL-CAD: light transport. since it's become a maintenance burden (quellage) and isn't
14:15.20CIA-62BRL-CAD: being worked on by anyone, time for removal. kunigami's progress on the osl
14:15.20CIA-62BRL-CAD: integration is already further along, so renewed interest can be concentrated
14:15.20CIA-62BRL-CAD: there.
14:18.00brlcadabhi2011: if you install new packages, you'll need to delete several cache files before rerunning configure, rm -rf *cache*
14:18.21brlcadthen rerun configure, make sure it says opengl is enabled at the end
14:19.33brlcadif it still fails, pastebin the build failure from the compile line to the end (i.e., including the gcc line), not just the last few lines
14:20.57abhi2011ok
14:21.48brlcadhalfway through your warning log, so should have that retestable in a day or two
14:23.12abhi2011ah ok thanks brlcad :)
15:11.09CIA-62BRL-CAD: 03brlcad * r45598 10/brlcad/trunk/src/rt/CMakeLists.txt: remove trailing ws
15:12.09CIA-62BRL-CAD: 03brlcad * r45599 10/brlcad/trunk/src/rt/ (scanline.c scanline.h): these files are not specific to rtmlt, partially revert r45597 to restore them
15:15.24brlcadstarseeker: have I said how much I really like the subdir rebuilding with cmake, how it rebuilds all deps for a given subdir
15:18.18CIA-62BRL-CAD: 03brlcad * r45600 10/brlcad/trunk/src/rt/viewarea.c: upgrade rtarea to size_t throughout. should help it handle 'massive' 64-bit geometries better than the previous long/int tracking it was using.
15:21.08CIA-62BRL-CAD: 03brlcad * r45601 10/brlcad/trunk/src/rt/viewarea.c: reorder functions to avoid forward decls.
15:28.08CIA-62BRL-CAD: 03brlcad * r45602 10/brlcad/trunk/src/rt/viewcheck.c: do the same for rtcheck, upgrade to counters to size_t
15:33.35CIA-62BRL-CAD: 03brlcad * r45603 10/brlcad/trunk/src/rt/ (viewarea.c viewcheck.c): ws consistency cleanup
15:46.11CIA-62BRL-CAD: 03brlcad * r45604 10/brlcad/trunk/src/rt/ (viewweight.c viewxray.c): use argv0
15:59.27CIA-62BRL-CAD: 03brlcad * r45605 10/brlcad/trunk/src/libicv/rot.c: use argv[0] instead of bu_getprogname() since the command name should still be there. make sure bu_optind is really 1, though.
16:05.04CIA-62BRL-CAD: 03brlcad * r45606 10/brlcad/trunk/src/ (4 files in 2 dirs): quellage, set but unused variables, missing variables for print specifiers (crashy crashy)
16:10.08CIA-62BRL-CAD: 03brlcad * r45607 10/brlcad/trunk/src/bwish/input.c: %S was deprecated a long while back, should be %V for vls
16:27.56CIA-62BRL-CAD: 03brlcad * r45608 10/brlcad/trunk/src/mged/cmd.c: and this ever worked? hard to imagine a lot of people are using the 'lm' command since it seems to have been passing the wrong argv to ls.. there shouldn't be muves-specific commands in brl-cad anyways.
16:37.25CIA-62BRL-CAD: 03brlcad * r45609 10/brlcad/trunk/src/proc-db/breplicator.cpp: heh, %0
16:42.26CIA-62BRL-CAD: 03brlcad * r45610 10/brlcad/trunk/src/shapes/coil.c: someone's editor leaves trailing whitespace turds all over the place
16:53.46CIA-62BRL-CAD: 03brlcad * r45611 10/brlcad/trunk/include/fb.h: they're both uint32_t values, not a pointer
17:12.19starseekerbrlcad: cool, thanks!  glad you're finding something to like with the CMake build, was kinda afraid I was going to make your life miserable for the sake of cross platform building ;-)
17:23.51CIA-62BRL-CAD: 03brlcad * r45612 10/brlcad/trunk/src/other/libz/ (zconf.h zconf.h.in): what if we just yank the whole _LARGEFILE64_SOURCE hack section. shouldn't need to muck with it.
17:24.39brlcadstarseeker: oh, I like it, there's just a lot of polish needed
17:26.04brlcadthe autotools build had many years to carefully tweak messages so that things are nearly as clear as possible (given the build infrastructure) making things as easy as possible for compiling-users, even if it meant more work on our end
17:26.29brlcadsome of that has regressed a little bit, but nothing that can't be fixed and overall a step forward still
17:29.23brlcadothers are just subtle changes here and there
17:29.55CIA-62BRL-CAD: 03starseeker * r45613 10/brlcad/trunk/src/rt/CMakeLists.txt:
17:29.55CIA-62BRL-CAD: Add M_LIBRARY to libremrt. BRLCAD_ADDLIB isn't used here because this library
17:29.55CIA-62BRL-CAD: isn't installed and is only built as a static library - in the (relatively rare)
17:29.55CIA-62BRL-CAD: cases in BRL-CAD where this is true we just use the raw cmake commands for
17:29.55CIA-62BRL-CAD: library building rather than obfuscate the logic with more macros.
17:30.55starseekerbrlcad: um.  if we're going to yank that stuff out of zlib, should we submit a patch back?
17:31.45brlcadsure
17:31.55starseekeradmittedly I've got non-vanilla changes in both libpng and zlib right now, but I've been planning to submit them all back to see if I can get 'em included (I'll probably have to upgrade our libpng version to get that to work so I haven't done it yet, but I need to.)
17:32.15brlcadare we up-to-date with zlib"?
17:32.25brlcadthought they had a new rev
17:32.25starseekerunless they've released a new version, yeah
17:32.28starseekerchecks
17:32.47starseekeryeah - 1.2.5
17:33.00starseekerupgraded a long while back to get the cmake file they included in that version
17:33.15brlcadstill, that snippet seems a little strange, trying to detect if its set so they can unset it... they shouldn't care
17:33.53starseekerthey did a couple odd things in that release - I've seen cases where mixing our zlib with system stuff using a system zlib has caused problems
17:34.12brlcadI'd put a patch into zconf.h to work around a compiler warning, but not into the zconf.h.in file cmake was using
17:34.20brlcadundoubtedly related to erik's later hack
17:35.02starseekerI haven't bugged 'em yet because the zlib CMakeLists.txt change is relatively minor (IIRC) but if we can fix that nonsense and really improve things it becomes worthwhile
17:35.59CIA-62BRL-CAD: 03brlcad * r45614 10/brlcad/trunk/src/ (24 files in 9 dirs): quell majority remainder of gcc 4.6 warnings from user log. mostly pointer casts, print specifier, and set but unused variable warnings. still need to sort out the %V warnings.
17:38.08brlcadhm, so somewhere in the debug/not-debug settings, it's issuing %V warnings with the cmake build ... gets back to an earlier discussion on how that warning was being suppressed
17:39.19brlcadlooks like STRICT_FLAGS isn't being set
17:39.28starseekerum.
17:41.48brlcadI see a snippet in the CMakeLists.txt file, looks like it should be getting set
17:42.16starseekerI may have messed up somewhat with all that... was trying to be clever about having Debug and Release build types "do the right thing" to make life easy
17:42.19brlcadoh, maybe he turned off strict so they got reported...
17:42.44brlcadshakes fist at cmake log for now showing the gcc lines
17:42.49brlcads/now/not!/
17:42.59brlcadI love it and hate it
17:43.25starseekermake VERBOSE=1 ?
17:43.26brlcadthey gotta fix that
17:43.39brlcadthat's not really what I want, though
17:43.43brlcadthat's all or nothing
17:43.51brlcadI want to just see the gcc lines for the compiles that fail
17:45.24brlcadkind of like what autogen.sh does, you run the command, capture the output, check the return value; if succeeded, keep quiet, but if failed, show the actual command and error it produced
17:45.50brlcadshould be pretty trivial
17:46.04brlcadfor some definition of trivial to the cmake devs :)
17:47.01brlcadstarseeker: so refresher understanding just to make sure, turning on warnings just turns on all the -Wwhatever warning flags, yes?  and turning on strict basically adds -Werror so they halt
17:47.11starseekerright
17:47.28brlcadokay, so then that might be a done deal then
17:47.42starseekerexcept that when we add Werror I think we turn off that printf one since we can't comply with it
17:47.42brlcadwe might be gcc 4.6 clean now, or at least very very close to it
17:47.47brlcadright
17:47.54brlcadthat's header logic, though, not build logic
17:48.32starseekerhmm.  I might have gilded the lily there - would need to check
17:48.33brlcadkeys off of the STRICT_FLAGS setting, that's what had me wondering
17:49.14brlcadwonders where bhinesley is
17:50.45brlcaddownloads gcc 4.6
17:51.03starseekerdunno, haven't heard from him today
17:52.39brlcadwow, make clean doesn't give any output?
17:52.52starseekernope - just cleans
17:52.55brlcadouch :)
17:53.14starseekermake clean VERBOSE=1 :-P
17:53.54brlcadsome feedback would be useful for a command that takes several minutes to run, locks up I/O, looks like something stuck in an inf loop
17:54.23starseekerbrlcad: are you subscribed to the CMake email list?  It's usually quite responsive
17:54.33brlcadnot at the moment
17:55.03starseekermost of these sorts of questions I end up going to there to try and answer anyway, so you might as well cut out the middleman :-P
17:55.11brlcadwow, make clean is brining this system to its knees, can't even keep up with typing
17:55.21starseekerthat's... quite odd
17:56.28brlcadhm, not make
17:56.59brlcadlooks like safari went nuts too, maybe the i/o slowness hit some bug
18:09.14*** join/#brlcad Stattrav (~Stattrav@117.192.138.90)
18:09.14*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:14.15*** join/#brlcad Stattrav_ (~Stattrav@117.192.145.200)
18:28.43*** join/#brlcad Stattrav (~Stattrav@117.192.143.204)
18:28.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:31.51abhi2011does brlcad depend on libdm ?
18:32.12abhi2011because the build fails on a file which uses libdm
18:32.28abhi2011dm-ogl.c
18:32.33starseekerlibdm is one of BRL-CAD's libraries
18:32.36starseekerwhat's the error?
18:33.42abhi2011http://bin.cakephp.org/view/1720792653
18:34.15abhi2011i did configure before with ogl
18:34.33starseekerum.  You're building with autotools I take it?
18:34.40abhi2011yes
18:34.45abhi2011i ll try make clean
18:34.50abhi2011and configure again
18:34.53starseekerlibdm built with opengl enabled?
18:35.16starseekerwhat that looks like offhand is that mged is being built with opengl on but libdm was built with it off - odd
18:35.22abhi2011well i havent checked the complete logs yet
18:35.33abhi2011hmmm
18:36.07abhi2011maybe the cache was not clean from the previous builds
18:36.17starseekerI'd try that first - clean build
18:36.28abhi2011yep
18:42.05brlcadabhi2011: you have to clean the cache and, of course, also delete your previous builds....
18:42.25abhi2011right
18:42.36brlcadso not just rm -rf *cache*
18:42.41brlcadbut also make clean
18:43.05brlcadmight be easier for you to just start fresh since the build system seems to be a bit foreign
18:43.19brlcadwith a new checkout
18:48.04CIA-62BRL-CAD: 03starseeker * r45615 10/brlcad/trunk/src/other/iwidgets.dist: Ain't there so don't ignore it anymore.
18:48.07*** join/#brlcad bhinesley (~bhinesley@adsl-99-125-86-110.dsl.bkfd14.sbcglobal.net)
18:48.15starseekerbhinesley: howdy :-)
18:48.33bhinesleystarseeker: hello :)
18:48.37abhi2011right, i ll checkout fresh
18:48.51starseekerbhinesley: how goes the edit.c work?
18:49.18*** join/#brlcad Stattrav (~Stattrav@117.192.143.204)
18:49.18*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
18:49.33bhinesleyit's going good
18:49.43bhinesleytaking a lot longer than I thought
18:49.50bhinesleybut good
18:50.07starseekeryou're working on option parsing still, or is that wrapping up?
18:50.21bhinesleythat's done, more or less
18:50.48starseekercool - so what's your next step?
18:52.04bhinesleyged_edit passes off to edit(), which will build the (point_t) arguments for the subcommands
18:52.42bhinesleyso the next step is edit(); do command specific argument validation, convert objects + offsets to points, and pass off to the subcommands to do the work
18:53.01bhinesleyoh, and edit() handles the batch operations
18:53.23*** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242)
18:53.36bhinesleyso if "." is specified as an object, it will convert that to multiple calls to the subcommand, replacing "." with the next object being operated on
18:53.47starseekerbrlcad: ah-ha http://mail.madler.net/pipermail/zlib-devel_madler.net/2011-June/002581.html
18:54.54bhinesleymisses colored nicks in irssi
18:56.11starseekerbhinesley: cool :-)
18:56.45brlcadbhinesley: were your ears burning?
18:57.09bhinesleybrlcad: my ears?
18:57.22brlcadwas just talking about you a little while ago
18:57.28bhinesleyoh :)
18:58.16bhinesleygood things I hope ;-)
18:58.18starseekergah - zlib doesn't seem to have a public dev repository!
18:58.54brlcadstarseeker: you mean, https://gforge.sci.utah.edu/gf/project/zlib/scmsvn/ ?
18:59.36starseekermutter - how'd I miss that?
18:59.50brlcadstarseeker: doesn't look like cmake even provides what I'd want for make clean
19:00.25brlcadmake clean VERBOSE=1 doesn't really show anything useful, just a bunch of cd calls and sub-make reinvocations (and VERBOSE isn't preserved)
19:00.59starseekerbrlcad: true, but it does at least give you feedback that something is happening
19:01.12brlcadI'd want to see either what files are being deleted, what directories/targets are being processed, or both
19:01.16brlcadactual files
19:01.26starseekernods - yeah, I don't know of any way to get it to do that
19:01.36starseekernever really cared, personally...
19:01.56brlcadusability nitpick
19:02.05brlcadif it was instant, wouldn't care .. but it takes several minutes
19:03.06starseekergrowl.  Looks like vanilla zlib won't be workable at least until they stick 1.2.6 up somewhere
19:03.13brlcadI can't glance at it and tell if it's got 2 seconds or 200 seconds remaining, or if it's just stuck
19:03.58starseekeryou're on a Mac?
19:04.10brlcadsometimes
19:04.23bhinesley's panic subsides; ahh, colored nicks
19:04.24starseekerI mean, the make clean is taking several minutes on a mac?
19:04.49brlcadmy previous build was, yes
19:04.59brlcadcould have been related to safari going nuts
19:04.59starseekertries it on Linux quick...
19:05.06brlcadbut that's the point, there's zero feedback
19:05.39starseekertook < 10 seconds here
19:05.42brlcadif your linux box is thrashing or if you were on an nfs filesystem, the same would affect you there
19:06.36brlcada second pass make clean only takes a few seconds here too, several factors
19:07.31brlcadotherwise by that same logic, I wouldn't need 'top' because well, most of the time everything runs fine
19:08.03starseekernods - oh, I see the logic but that's probably why it wasn't a high priority for them
19:12.02brlcadyeah, even an already cleaned build takes about 20 seconds
19:12.11brlcadproably all of the reinvocations of make for every target
19:12.30brlcadthat and this laptop isn't the quickest
19:14.02starseekertosses together an email to the zlib devs...
19:15.23brlcadstarseeker: how about a simple echo/output line on the clean rule that just says "Deleting build files, please wait..."
19:15.31brlcadwhere would that go?
19:16.18starseekerbrlcad: unfortunately, the clean rule isn't something that can be user-modified yet - IIRC that's one of the issues they most commonly get requested to fix
19:16.25starseekerchecks archives...
19:17.01brlcadah, k
19:17.03starseekerhttp://www.cmake.org/pipermail/cmake/2006-October/011477.html
19:17.26starseekerold email though - don't know what current status is
19:17.33brlcadyeah, quite
19:18.31starseekeryeah, still an issue in 09:  http://www.cmake.org/pipermail/cmake/2009-January/026727.html
19:20.01starseekersomewhat related:  http://www.cmake.org/Bug/view.php?id=10424
19:21.02starseekerah, I think this was the actual issue:  http://www.cmake.org/Bug/view.php?id=6183
19:22.51brlcadit's not clear if that last one is saying that it's not possible or that it is possible given that additional info statemetn
19:23.23starseekeras far as I know it's not possible, but then I haven't really pushed hard to try it
19:23.23brlcador are they just saying "it wouldn't be hard to support adding custom commands"
19:23.37starseekerI think so - I think the guy making the report was making the case that it's a simple change
19:23.58starseekerI've seen other comments on the issue (that I can't scare up right now) that indicated it wasn't quite so simple though
19:24.07brlcadk
19:24.14brlcadI'll suck it up for now
19:24.27starseeker(I suppose patches welcome :-P)
19:43.54bhinesleyis it okay to use SMALL_FASTF/MAX_FASTF as sentinal values?
19:44.16starseekerwhat do you mean by sentinal values?
19:44.38bhinesleyI could use a way to indicate that a particular coordinate of a vector has not been set
19:45.10bhinesleyso could I set, say coord[1] = MAX_FASTF, since it will never be used in practice
19:45.22starseekeroh - I believe that's workable
19:45.25starseekerbrlcad?
19:59.25*** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242)
20:10.37CIA-62BRL-CAD: 03starseeker * r45616 10/brlcad/trunk/src/other/libpng/ (175 files in 21 dirs):
20:10.37CIA-62BRL-CAD: libpng-1.5.x is the current stable libpng series now. Update to libpng 1.5.4,
20:10.37CIA-62BRL-CAD: 'cause that's what all the cool kids are doing. (API cleanup is a good thing,
20:10.37CIA-62BRL-CAD: too...) Starting with a vanilla check-in, will probably need to re-apply
20:10.37CIA-62BRL-CAD: Makefile.am changes and will definitely need to port CMakeLists.txt changes
20:10.38CIA-62BRL-CAD: forward. Will be submitting the CMakeLists.txt changes back to see if we can
20:10.39CIA-62BRL-CAD: get them included in the next version of libpng.
20:12.13CIA-62BRL-CAD: 03starseeker * r45617 10/brlcad/trunk/src/ (fb/fb-png.c libged/png.c other/libpng.dist util/pix-png.c): fix header includes for 1.5 libpng - need explicit zlib.h in a couple places.
20:16.24*** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242)
20:21.57*** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net)
20:22.22brlcadbhinesley: those are terrible sentinal values because they're frequently valid and will match a simple == 0 comparison
20:22.45brlcadusual practice is either a separate set/unset variable flag
20:22.58brlcador use -INFINITY/INFINITY
20:23.22brlcadwhich still isn't full-proof safe, but "good enough" in practice
20:23.34starseekerbrlcad: hmm.  do similar concerns apply to the use of (say) MAX_INT?
20:24.33brlcadpresuming you mean INT_MAX, that's effectively == INFINITY for the int type
20:24.40bhinesleyalright, the flags will work fine; I already have a mechanism for that
20:24.44starseekerah, k
20:25.04brlcadit's harder for integer types, though, since you can interate to infinity pretty easily
20:25.23brlcadso the code has to work harder to make sure you're always < INT_MAX, not <=
20:25.32brlcadbetter is flags ;)
20:29.05LainIwakuraXbrlcad: I'm here for about...2 hours and here again later tonight if you were going to test the patch I made (and want me here for the testing)
20:30.56starseekerLainIwakuraX: are you applying to the ESA Summer of Code?
20:32.12LainIwakuraXstarseeker: No, although I am qualified.
20:32.51starseekerLainIwakuraX: awesome work wading through that SCLString code :-)
20:33.10LainIwakuraXIt wasn't that bad =P
20:33.46LainIwakuraXShould I apply for ESA Summer of Code? The thing stopping me was the proposal...it seems hard =/
20:33.58brlcadLainIwakuraX: maybe not that hard, but editing about 900 lines that have to be manually adapted is still a lot of appreciated effort
20:34.10LainIwakuraXAh
20:34.22LainIwakuraXWhen I got tired
20:34.24LainIwakuraXin vim
20:34.31LainIwakuraX:%s/SCLstring/std::string/g
20:34.34LainIwakuraX>_>
20:34.51brlcad:)
20:35.06brlcadthat's the easy part, then  you had to adapt all of the callers
20:35.10starseekerLainIwakuraX: what seemed hard about the proposal?
20:35.19brlcadof course, still have to see if it actually works ;)
20:36.00LainIwakuraXstarseeker: A lot of the projects being proposed are a bit advanced, I'm only going into my second year of comp sci. at University
20:36.35bhinesleyLainIwakuraX: me too, but I was accepted into GSoC
20:36.36bhinesley:)
20:36.40starseekerLainIwakuraX: http://brlcad.org/wiki/STEP_Libraries
20:36.42starseeker:-P
20:37.06starseekerhttp://brlcad.org/wiki/ESA_Summer_of_Code_in_Space/Project_Ideas, under Geometry Conversion Projects
20:37.17LainIwakuraXuhh
20:37.19LainIwakuraXI see
20:37.27LainIwakuraXI guess I will apply lol
20:37.47bhinesleywell, third actually... but I'm only just now transferring to the university after taking a grand total of 3 programming classes
20:37.53LainIwakuraXah
20:38.31LainIwakuraXI've only taken 1 C++ course..but I had a good teacher =P
20:38.41bhinesleyI thought the same thing that you did though. I saw a bunch of PhD/Masters students and thought that I was out of my leauge, but here I am.
20:38.46brlcadyay, got step-g to crash
20:38.53LainIwakuraXuh oh
20:39.05bhinesleyLainIwakuraX: same here. I've taken Java, C, and C++, but that's it.
20:39.26LainIwakuraXbrlcad: are you treating warnings as errors?
20:39.26brlcadLainIwakuraX: not your patch
20:39.29LainIwakuraXoh
20:39.35LainIwakuraXdon't scare me lol
20:40.18brlcadtest file I fed it was a bit insane
20:41.08starseekerLainIwakuraX: when I saw your patch I actually thought it was your patch submission for the ESA SoC application :-P
20:41.53LainIwakuraXNo, I just wanted to get involved ._.
20:42.01starseekerawesome :-)
20:42.09LainIwakuraXI guess I'll reference the patch on my application though
20:43.09LainIwakuraXWhere do I go to apply? I lost the link
20:43.45starseekerhttp://sophia.estec.esa.int/socis2011/
20:43.55starseekerhttp://brlcad.org/wiki/ESA_Summer_of_Code_in_Space
20:45.17LainIwakuraXHow many hours does this usually take up? I did that SCLstring thing in about 5 hours, but I do have a part-time job in web development
20:48.29LainIwakuraXHm..I guess it'd depend a lot on what you were doing
20:49.14brlcadLainIwakuraX: it's generally expected that the SoC programs constitute full-time 40+ hours effort
20:49.36brlcadif you have another job, might just want to keep it to a hobby .. less pressure, much more fun ;)
20:49.42brlcadscratch your own itches
20:49.53starseekerLainIwakuraX: yeah, definitely the low-pressure way to go
20:50.03LainIwakuraXbrlcad: My other job is pretty...flexible
20:50.12LainIwakuraXI'm applying =P
20:51.28brlcad:)
20:52.31brlcadanother thing to keep in mind, given a space agency is sponsoring this, given two roughly equivalent applicants .. priority will go towards development that is directly space-related
20:52.47LainIwakuraXMhm
20:52.56brlcadhaving two "roughly equivalent" applicants is unlikely, but worth saying nonetheless ;)
20:53.12brlcadwell, no compilation failures with the step patch
20:54.42LainIwakuraX=P I wasn't lying
21:03.00CIA-62BRL-CAD: 03brlcad * r45618 10/brlcad/trunk/src/ (44 files in 10 dirs):
21:03.00CIA-62BRL-CAD: apply sf patch 3376896 (All instances of SCLstring changed to std::string) from
21:03.00CIA-62BRL-CAD: lainiwakurax. patch converts scl converts almost all instances of SCLstring in
21:03.00CIA-62BRL-CAD: SCL to standard STL strings. tested minimally with a few ap203 conversions that
21:03.00CIA-62BRL-CAD: all seemed to parse and convert equivalently. outstanding.
21:03.51LainIwakuraXIt worked?
21:05.18CIA-62BRL-CAD: 03brlcad * r45619 10/brlcad/trunk/AUTHORS: credit Zach Easterbrook (lainiwakurax) as a code contributor with his code patch that converted SCLstring to std::string in src/conv/step and src/other/step. thanks, Zach!
21:05.34brlcadlooks like it
21:05.39LainIwakuraX=D Awesome
21:07.30brlcadyeah, quite
21:08.19LainIwakuraXI'm not surprised there wasn't much of a time difference, their functions were very similar to the ones in std::string
21:08.20CIA-62BRL-CAD: 03brlcad * r45620 10/brlcad/trunk/TODO: lainiwakurax replaced SCLstring with std::string (via sf patch 3376896)
21:08.34brlcadthe implementation of those functions are quite different
21:08.48LainIwakuraXAh
21:09.24brlcadI noticed a few dozen instances of SCLstring still remain, were they problematic?
21:09.33brlcador did you only fix the ones that affected compilation?
21:09.52LainIwakuraXI'd say I fixed 99% of them...there were some in blocks like this:
21:09.58LainIwakuraX#ifdef __OSTORE__
21:10.06LainIwakuraXand they used a function (get_os_typespec)
21:10.11LainIwakuraXand I didn't know what it did
21:10.47LainIwakuraXsoo I focused on the ones where I knew what was going on
21:14.20LainIwakuraXone sec I'm finding the spot where that is
21:14.21brlcadyeah, OSTORE is a bit of a mystery, but looks like a partial interface for automatic serialization for an object store
21:14.52brlcaddon't see anything that turns OSTORE on/off, though
21:15.22LainIwakuraXif you go to errordesc.cc in clutils
21:15.33LainIwakuraXaround line 189 you'll see some spots where it's still SCLstring
21:15.40LainIwakuraXthey're in those blocks
21:15.59brlcadnods
21:16.09brlcadthose OSTORE blocks can probably just be deleted
21:16.22LainIwakuraXwait, there is stuff in else blocks
21:16.35LainIwakuraXthat I didn't catch =/ would those matter?
21:17.18LainIwakuraXhttp://codepad.org/lsTE2mHV
21:17.22brlcadprobably, but apparently they're self-contained
21:17.33brlcadprobably got lucky since they're just used for error reporting
21:18.06brlcadfg
21:18.54LainIwakuraXI'll fix those instances in the else's in a few minutes, to be safe
21:19.10brlcadthe final test will be the removal of the sclstring class
21:19.24LainIwakuraXmhm
21:19.36CIA-62BRL-CAD: 03starseeker * r45621 10/brlcad/trunk/src/other/step/src/clutils/ (CMakeLists.txt scl_string.cc scl_string.h): Doesn't look like scl_string.cc/h are being used - yank
21:20.27brlcadheh
21:20.34brlcadstarseeker: it's still used in a few places
21:20.44starseekerbuilds
21:20.51brlcadmaybe not in a portion enabled in our build
21:24.40starseekerman - no indication in the docs as to what OSTORE is for that I can see
21:25.21LainIwakuraXshould I bother fixing the SCLstring instances in those OSTORE blocks?
21:25.49starseekerbrlcad: what do you think?
21:26.51starseekerLainIwakuraX: I think you can try switching it in errordecs.h to start and see what follows...
21:27.37LainIwakuraXk
21:28.12CIA-62BRL-CAD: 03brlcad * r45622 10/brlcad/trunk/src/other/libpng/ (8 files): remove autogenerated build files. have to play nicely with autotools build until it's obsolete.
21:30.03LainIwakuraXsince you removed those files...I'm getting a cmake error
21:30.14LainIwakuraXCMake Error at misc/CMake/BRLCAD_Util.cmake:214 (MESSAGE): Attempting to ignore non-existent file /home/yuki/bin/brlcad/src/other/step/src/clutils/scl_string.h
21:30.24starseekerLainIwakuraX: er, sorry
21:30.30starseekergot a bit too eager
21:30.34LainIwakuraX=P
21:31.04brlcadignore the OSTORE blocks
21:31.20LainIwakuraXkk
21:31.23brlcador separate patch to remove them
21:32.05CIA-62BRL-CAD: 03starseeker * r45623 10/brlcad/trunk/src/other/step/src/clutils/ (scl_string.cc scl_string.h): Wait until we're sure they're gone.
21:33.00CIA-62BRL-CAD: 03starseeker * r45624 10/brlcad/trunk/src/other/step/src/clutils/CMakeLists.txt: CMakeLists.txt too
21:33.46LainIwakuraXI'm thinking of proposing this: http://brlcad.org/wiki/Density_functions
21:34.07LainIwakuraXthoughts? It seems interesting
21:34.23LainIwakuraXand I like functions..for describing things =P
21:36.37brlcadthoughts as in?
21:36.49starseekerheh - had enough of the SCL code? :-P  Main thing is to pick something you think would interest you and you'd enjoy working on
21:36.56brlcadit's an interesting priority topic, very very closely related to another non-priority topic too: http://brlcad.org/wiki/Material_and_Shader_Objects
21:37.39LainIwakuraXHm, well it's listed as "difficult" but the SCLstring thing was "medium" and I did it in 5 hours
21:38.44LainIwakuraXSo you guys know more about this system =/ do you think it'd be fun and challenging?
21:40.05LainIwakuraXBut still reasonable enough for someone who hasn't worked on BRL-CAD
21:40.07LainIwakuraXI suppose
21:42.50brlcadheh, "medium" in terms of being a quickie
21:43.02starseekerLainIwakuraX: we can't guide you too much - you're the one who will know what is interesting.  I will say that when we say it's "HARD" we generally aren't kidding
21:43.04brlcadthat's on a rough "doable within a couple days" scale
21:43.27brlcadthe summer of code projects are on a doable within a couple months scale"
21:44.11LainIwakuraXAh
21:44.49LainIwakuraXWell, I'll research this a bit and have the submission sometime tonight
21:45.05starseekerthe SCLstring thing basically was a warm up for the Step Library cleanup task
21:45.10starseekerthere's a lot more waiting
21:45.18LainIwakuraXah
21:45.38CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3036 10/wiki/Contributor_Quickies: LainIwakuraX converted scl to stl, sclstring to std::string
21:46.20starseekerLainIwakuraX: notice too that although all of the functional instances of SCLstring were changed, it's still not quite fully purged
21:47.54starseekerbrlcad: I didn't see the ESA task criteria (if any) - did they lay out particular areas they wanted to see worked?
21:49.03brlcadnot in specific detail, similar to gsoc they're mostly hands off but their interest (and the business case to their management) is pretty clear
21:49.19starseekeryeah, looks like the OSTORE stuff involves something called ostore.h, which isn't in the NIST repostory
21:49.32brlcadstarseeker: I wouldn't worry about OSTORE, it's dead code
21:49.37brlcadno way to turn it on means it's dead
21:49.38starseekernods
21:49.51brlcadsounds like something that would be added for CORBA
21:49.56starseekerwinces
21:50.20brlcadso just yank it
21:50.26starseekernods
21:50.46brlcadgoes to coach for a bit
21:52.13LainIwakuraXQuestion about the density functions, it says: "Material objects should be BRL-CAD database objects that can be referenced (by name) by other db objects"
21:52.19LainIwakuraXAre these objects like, structs?
21:52.42starseekerno, that's referring to an object in a BRL-CAD .g database
21:52.51LainIwakuraXAh
21:53.24LainIwakuraXIs there a brief way to describe how these objects are formed?
21:57.45CIA-62BRL-CAD: 03starseeker * r45625 10/brlcad/trunk/src/other/step/src/ (clstepcore/ExpDict.cc clstepcore/sdaiSelect.cc clutils/Str.h): Remove some commented out code containing SCLstring
21:58.23starseekerLainIwakuraX: not really a "brief" way - you can look at the primitives in src/librt/primitives for some examples...
21:59.42LainIwakuraXkk
22:10.18LainIwakuraXI can submitted a link to a google doc document for the proposal, correct?
22:10.30*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
22:10.49starseekerLainIwakuraX: dunno, question for brlcad
22:11.17LainIwakuraXah
22:20.14CIA-62BRL-CAD: 03starseeker * r45626 10/brlcad/trunk/src/other/step/src/ (5 files in 2 dirs): remove remainder of SCLstring uses
22:27.59LainIwakuraXI'm out for a while, see you guys in ~2 hrs
22:43.02abhi2011got archer runnning finally
22:43.26abhi2011got a funny opengl warning as well : OpenGL Warning: No pincher, please call crStateSetCurrentPointers() in your SPU
22:45.49abhi2011wow!!..rt just rox!
22:45.58abhi2011rendered a sphere :P
22:59.59CIA-62BRL-CAD: 03starseeker * r45627 10/brlcad/trunk/src/other/step/src/ (17 files in 3 dirs): Take a stab at removing scl_string altogether.
23:04.46*** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ)
23:05.00starseek1rah, fudge - step-g isn't working for me
23:11.13starseekerhappened after the initial application of the patch (on Linux)
23:11.31starseekerLainIwakuraX: can you build BRL-CAD as a whole?
23:11.47starseekerI'm getting the following error:  
23:11.48starseekerterminate called after throwing an instance of 'std::logic_error' what():  basic_string::_S_construct NULL not valid
23:11.51starseekerAborted
23:14.44starseekerrunning the command ./bin/step-g -o test.g ../brlcad/src/other/step/data/ap203/cube1.p21
IRC log for #brlcad on 20110726

IRC log for #brlcad on 20110726

00:46.55*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
01:39.59LainIwakuraXstarseeker: I can build BRL-CAD as a whole, if you check my patch it's the environment
01:40.28starseekerLainIwakuraX: what behavior do you see if you try the above?
01:40.43LainIwakuraX1 sec
01:41.00LainIwakuraXyeah I get that too
01:41.19starseekerhrm
01:42.12LainIwakuraXhow do I track down that sort of thing? =/
01:42.26starseekerLainIwakuraX: gdb to start with
01:42.52starseekerfigure out which call is producing the error, examine the data being fed in and why it's wiping out
01:43.41LainIwakuraXah okay..first time working with gdb, I'll try to get this sorted
01:43.56starseekerit's a good skill to have :-)
01:44.05starseekerbt (backtrace) is quite useful
01:44.44LainIwakuraXah I think I know what may be causing this bug, I can go fix it in source
01:59.29LainIwakuraXIt looks like somewhere a std::string is being assigned to NULL when it probably should be ""
01:59.43LainIwakuraXthis might take a few minutes to hunt down
02:00.00starseekeryeah, I thought it might be something like this:  http://stackoverflow.com/questions/2407711/avoiding-improper-stdstring-initialization-with-null-const-char-using-g
02:00.15starseekerpossibly SCLstring tolerated NULL as an initialization input...
02:01.13LainIwakuraXmhm. I found a few spots where I said "new std::string" and I changed those to initialize with "" for sure...but that didn't fix it
02:01.29LainIwakuraXI'll look around
02:01.33starseekerLainIwakuraX: I probably added a few of those myself...
02:01.45LainIwakuraX=x
02:06.12CIA-62BRL-CAD: 03bhinesley * r45628 10/brlcad/trunk/src/libged/edit.c:
02:06.12CIA-62BRL-CAD: Tracked down an issue where the last object wasn't being added, and the last
02:06.12CIA-62BRL-CAD: node in the linked list was empty. Added support for numeric args (as abs coord,
02:06.12CIA-62BRL-CAD: rel pos, or obj offset). Added/renamed constants for specifying coordinates, so
02:06.12CIA-62BRL-CAD: that significance goes from left to right:
02:06.13CIA-62BRL-CAD: '%s/EDIT\([[:upper:]]\)_COORD/EDIT_COORD_\1/g'. Several smaller,
02:06.14CIA-62BRL-CAD: formatting/comment corrections.
02:20.07LainIwakuraXstarseeker: If you find the spot where it's being initialized to null let me know, I haven't found it yet =(
02:21.08starseekerLainIwakuraX: it might even be a function of what it's parsing... my C++ foo is a bit weak, unfortunately
02:21.38starseekerprobably very simple once we figure it out
02:22.43LainIwakuraXyeah, I know that when I see it I'll know it lol it's just finding it
02:23.04LainIwakuraXgdb gives me some info..
02:23.14LainIwakuraXSTEPWrapper::load(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) ()
02:23.28LainIwakuraXI can't find STEPWrapper::load anywhere though
02:24.42starseekerwonders if ddd might be helpful...
02:25.51bhinesleyspent about a hour wrestling ddd crashes today
02:26.57bhinesleyLainIwakuraX: when in doubt: `find . -name "*.cpp" -exec grep "STEPWrapper::load" --with-filename {} \;`
02:28.26bhinesleyor use ctags (even better)
02:31.00LainIwakuraXdoesn't bring up anything =(
02:31.22LainIwakuraXI usually use: grep -H -r "<thing to search for>" . | grep -v svn | less
02:32.42LainIwakuraXoho...may have found it
02:33.17LainIwakuraXugh it was in a different directory! I forgot two were involved in my editing process...this should be easier now
02:43.36LainIwakuraXstarseeker: I've found the offending code I'm in the process of debugging it
02:45.27starseekerRegistry::AddType, clstepcore/Registry.inline.cc:221 ?
02:45.33LainIwakuraXNo
02:45.44starseekernmm
02:45.53LainIwakuraXconv/step/STEPWrapper.cpp
02:45.56LainIwakuraXthe load function
02:45.57starseekerah
03:15.06LainIwakuraXokay the "offending" code was sort of offending, after travelling to 4 different functions I found the real offending code =P working on it..
03:36.04LainIwakuraXstarseeker: I fixed that bug, but now we get a segfault
03:36.13LainIwakuraXReading Data from ../brlcad/src/other/step/data/ap203/cube1.p21...
03:36.16LainIwakuraXsegfault
03:38.20brlcadstarseeker, probably a little premature on the cross-post, no? :)
03:39.00brlcadbest when collaborating to announce after we've fully vetted/tested ourselves
03:41.04brlcadinteresting that I didn't run into a failure on my test
03:41.27brlcadtests that particular p21 file
03:41.31LainIwakuraXyes, it is curious but the bug I found would have indeed failed on something eventually =P
03:41.35LainIwakuraXthe line said
03:41.43LainIwakuraXstd::string schmn = NULL
03:41.53LainIwakuraXthat won't work
03:44.16brlcadnods
03:44.22brlcadhm, BAD cmake rebuild
03:48.55LainIwakuraXUhh
03:49.05LainIwakuraXI got it to work without a segfault
03:49.20LainIwakuraXit says Reading Data from ../brlcad/src/other/step/data/ap203/cube1.p21...
03:49.33LainIwakuraXThen it says basic_string::_S_construct null not valid
03:49.38LainIwakuraXthen the program exits normally...
03:49.45LainIwakuraX(according to gdb)
03:53.34bhinesleybrlcad: what gcc do most devs use?
03:53.51brlcadyeah, my test of the patch was quite flawed, two build systems got in the way of each other
03:53.54bhinesleyI figured I'd install a lower version so I can use strict
03:54.12brlcadbhinesley: a pretty wide variety, actually
03:54.20brlcadjust nobody on gcc 4.6 yet (except you ;)
03:54.26bhinesleyheh
03:54.35``Erikuses 4.2 (fbsd standard) and 4.1 (apple standard) mostly
03:54.36brlcadit's been out for about a month
03:54.54brlcadbhinesley: have you rebuilt lately?
03:55.15bhinesleydoing so now, but strict is off
03:55.20brlcadI fixed a slew of the ones abhit reported over the weekend, about a thousand issues
03:55.27bhinesleynice
03:55.28brlcadsave a full build log
03:55.46brlcadmake 2>&1 | tee build.log
03:56.02bhinesleyokay, in just a bit
03:56.29bhinesleyI just did a svn update... you guys were busy over the weekend :)
03:56.38brlcadI'm sure I didn't get everything since I don't have the compiler warning if I missed anything, but it should be far better
03:56.51bhinesleynods
03:56.57``Erikbrlcad: I put gcc4.7 on crit if you get the urge to play
03:56.59bhinesleyI saw the logs
03:57.09brlcadmost oft he things it's warning about are really trivial to fix
03:57.26brlcadvars not being used, print specifier consistency
03:57.37brlcad``Erik: good to know, thanks
03:57.51brlcadreproduces the step-g failure
03:58.23LainIwakuraXbrlcad: I have that fixed to not crash, cleaning up some things and submitting a patch
04:01.44brlcadLainIwakuraX: okay, great .. so I shouldn't go debugging
04:08.36LainIwakuraXbrlcad: Patch is submitted...like I said in the notes though even though there isn't a crash I still don't know if it "works"
04:08.54LainIwakuraXIf you could test that it'd be great =) I haven't used this program before, I don't know what to expect from it
04:11.32brlcadLainIwakuraX: what was the issue with STEPWrapper::load() ?
04:12.06brlcadchanging from a std::string& to a std::string merely makes it make a copy (alloc)
04:12.27brlcadif that fixes a crash, some further investigating is probably warranted
04:12.35LainIwakuraXbrlcad: Uh, that shouldn't have been changed- that was a test
04:12.46brlcadstarseeker: debugging is not enabled by default?
04:13.30brlcadpatch files are text, you should review them before posting .. just like you should review the diff before a commit too
04:13.42brlcadsvn revert will restore a file to an unedited state
04:14.09brlcad"svn diff | less" and you can manually inspect what changes are getting included
04:14.41LainIwakuraXbrlcad: if you give me two seconds I'll upload a better patch file
04:14.45brlcadk
04:15.20brlcadalso make sure you're up-to-date (svn up) so the line offsets are correct
04:17.20LainIwakuraXhm
04:17.36LainIwakuraXI put my &'s on string, not the variable name..
04:18.05LainIwakuraXit was string &step_file but now it's string& step_file..that's fine though
04:18.20brlcadthey are equivalent
04:18.24LainIwakuraXI know
04:18.31LainIwakuraXthat's why I said it's fine =P
04:18.36brlcadheh
04:19.22brlcadconvention is usually to bind the type together with c++ but separate them for c
04:19.34brlcadso string& is peachy for scl
04:19.39LainIwakuraXah
04:19.48LainIwakuraXk the better patch is up there
04:20.06brlcadgets
04:21.54LainIwakuraXI'll brb in ~10 mins, let me know how it goes
04:22.25brlcadtesting now
04:23.18brlcadso it no longer hard-crashes, but it still exits due to a NULL string
04:24.06brlcadlooks like it's maybe on a static
04:25.46brlcadwill have to debug more tomorrow.. because *somebody* thought defaulting to no debug symbol compilation was a good idea  *ahem* :)
04:26.41brlcadbasically, every place a std::string is instantiated, it needs to be initialized to be compatible with what it was assuming
04:32.02CIA-62BRL-CAD: 03brlcad * r45629 10/brlcad/trunk/src/other/step/src/ (5 files in 2 dirs):
04:32.02CIA-62BRL-CAD: apply sf patch 3377904 (fixed a bug with step-g and null strings) from Zach
04:32.02CIA-62BRL-CAD: Easterbrook ( lainiwakurax ) which indeed fixes the step-g crash, but still
04:32.02CIA-62BRL-CAD: doesn't restore it to a functional status. aborts with a message about a NULL
04:32.02CIA-62BRL-CAD: std::string.
04:32.23LainIwakuraXI'm back
04:32.59LainIwakuraXbrlcad: How can we test this if it's failing without...uh, any issues?
04:33.09LainIwakuraXI can't do a backtrace in gdb
04:33.51brlcadfor one, step-g produces a ton of output when it's working correctly ;)
04:34.31brlcadyou can put a breakpoint on main (b main) and step forward ('n' command for "next instruction")
04:34.51brlcador "b whatever" to break on any arbitrary function
04:35.08brlcadit'll take me a while to get a rebuild with debugging enabled myself
04:36.43LainIwakuraXbrlcad: Is it cool if we tackle this tomorrow then? It's 12:30a.m here and I have a few more things to do before bed =x
04:37.55brlcadwe're apparently on the same coast, sounds good to me
04:38.50LainIwakuraXk, see you then. I'm usually awake in the afternoon lol
04:42.03*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
04:55.02bhinesleybrlcad: build.log http://paste.pocoo.org/show/446487/
04:56.03bhinesleyer, you probably wanted me to use 'make -k'
05:00.42bhinesley'make -k' build log: http://paste.pocoo.org/show/446495/
05:34.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:26.18*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:10.26*** join/#brlcad merzo (~merzo@193.254.217.44)
08:47.51CIA-62BRL-CAD: 03Abby Moss 07http://brlcad.org * r3037 10/wiki/Main_Page:
08:47.59CIA-62BRL-CAD: 03d_rossberg * r45630 10/brlcad/trunk/src/libbu/CMakeLists.txt: Windows MSVC: because of GetMappedFileName() in fchmod.c link with psapi.lib
08:50.13*** join/#brlcad Stattrav (~Stattrav@122.167.229.132)
08:50.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:33.19*** join/#brlcad DarkCalf (DC@173.231.40.98)
11:42.12starseekerbrlcad: yeah, premature.  Was going on your initial report that it worked
11:47.55starseekerstarseeker: I'll hold off until we have it working next time
11:47.59starseekerer brlcad rather
11:48.05starseekeris talking to himself
11:58.57brlcadmm, you sent the message before I'd even started testing :)
12:01.07brlcad2pm, didn't test and commit till 5pm .. but even if if it was golden, I'd suggest we send them revision numbers at stepping points
12:01.17brlcadbhinesley: thanks
12:20.58CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3038 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Abby Moss|Abby Moss]] ([[User talk:Abby Moss|Talk]]); changed back to last version by [[User:Sean|Sean]]
12:21.20CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Abby Moss]] with an expiry time of infinite (account creation disabled, e-mail blocked)
12:27.48CIA-62BRL-CAD: 03brlcad * r45631 10/brlcad/trunk/src/ (CMakeLists.txt libbu/CMakeLists.txt): set PSAPI_LIB variable so we can consolidate into the same since MSVC block
12:30.28d_rossbergbrlcad: setting of the MSVC libraries isn't very consistent in the cmake files, see e.g. librt
12:34.54brlcadnods
12:35.57CIA-62BRL-CAD: 03brlcad * r45632 10/brlcad/trunk/src/other/step/src/ (62 files in 7 dirs):
12:35.57CIA-62BRL-CAD: eliminate all of the __OSTORE__ sections. considered dead code because there
12:35.57CIA-62BRL-CAD: was no managed way to enable those code sections. appears to be a binding to a
12:35.57CIA-62BRL-CAD: commercial API (Progress Software Corp's ObjectStore product), so remove in
12:35.57CIA-62BRL-CAD: favor of simplified code maintenance and reduced complexity. removes almost 3k
12:35.58CIA-62BRL-CAD: lines of code.
12:36.08brlcadd_rossberg: I know, the evils of letting a "platform" identifier in for a few things makes it really easy to abuse/reuse in more places than it should
12:36.51*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
12:41.00CIA-62BRL-CAD: 03brlcad * r45633 10/brlcad/trunk/src/ (CMakeLists.txt librt/CMakeLists.txt): similar to libbu, consolidate the msvc library settings into the same place where winsock gets set, consistently just use library names in ADDLIB
12:49.09brlcadI'm sure the intention was to go back one day, some day, and fix them proper when they were first written... ;)
12:53.18CIA-62BRL-CAD: 03brlcad * r45634 10/brlcad/trunk/CMakeLists.txt: typo?
12:54.10d_rossbergOK
13:00.31CIA-62BRL-CAD: 03brlcad * r45635 10/brlcad/trunk/CMakeLists.txt:
13:00.31CIA-62BRL-CAD: consistently default all builds (particularly fresh svn checkouts) to a system
13:00.32CIA-62BRL-CAD: install into /usr/brlcad using rel- for releases and dev- for developer builds.
13:00.32CIA-62BRL-CAD: could probably even just key off of the patch number but leave as-is for now.
13:00.32CIA-62BRL-CAD: this will probably require windows to set the install prefix given there usually
13:00.32CIA-62BRL-CAD: is no /usr path but that is needed for windows anyways for release builds.
13:01.29*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:01.46CIA-62BRL-CAD: 03brlcad * r45636 10/brlcad/trunk/TODO: remove all of the MSVC platform sections in the CMakeLists.txt files
13:01.49brlcadabhi2011: application received!
13:08.44CIA-62BRL-CAD: 03brlcad * r45637 10/brlcad/trunk/TODO: demote a lot of tasks that won't likely be completed by next month. leave most of the build-related tasks since we're moving towards eventual autotools removal.
13:09.37CIA-62BRL-CAD: 03brlcad * r45638 10/brlcad/trunk/TODO: cp command now redraws once again, along with a slew of other ged commands. if one of the argv parameters is displayed, it gets redrawn.
13:14.57CIA-62BRL-CAD: 03brlcad * r45639 10/brlcad/trunk/BUGS: rt displays output once again, button bindings should be fixed, and rt after cd in mged on windows should work once again
13:34.45CIA-62BRL-CAD: 03brlcad * r45640 10/brlcad/trunk/src/conv/step/step-g.cpp: ws style
13:39.02CIA-62BRL-CAD: 03brlcad * r45641 10/brlcad/trunk/src/conv/step/ (6 files):
13:39.02CIA-62BRL-CAD: got step-g to crash with a couple input test files, one crashing on Surface.h:48
13:39.02CIA-62BRL-CAD: implying some stack corruption or memory issue. so add protections all the way
13:39.02CIA-62BRL-CAD: up the stack to make sure we didn't run out of memory or dereference a null
13:39.02CIA-62BRL-CAD: pointer at some point. probably doesn't get to the heart of the crash, but
13:39.02CIA-62BRL-CAD: should help isolate it and help halt sooner (and hopefully more gracefully than
13:39.03CIA-62BRL-CAD: a crash).
13:40.34CIA-62BRL-CAD: 03brlcad * r45642 10/brlcad/trunk/src/other/libpng/depcomp: depcomp is generated, remove from checkin
13:42.35CIA-62BRL-CAD: 03brlcad * r45643 10/brlcad/trunk/src/other/libpng/config.h.in: autoheader made config.h.in, also remove
13:42.44abhi2011thanks brlcad :)
13:50.51CIA-62BRL-CAD: 03brlcad * r45644 10/brlcad/trunk/TODO: libpng needs backported fixes for autotools
14:30.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:35.28starseekerbrlcad: ah, right - I thought they might want to play with the patch at that point.  Was hoping they might do some of the work for us :-P
14:36.48starseekerbrlcad: you really want to go into /usr/brlcad for dev builds by default?
14:36.57starseekerwas very intentionally staying out of system dirs
14:47.00CIA-62BRL-CAD: 03starseeker * r45645 10/brlcad/trunk/CMakeLists.txt: Wasn't a typo - to do what that previous edit looked like it wanted to do, ELSEIF (I think) is what is needed. Instead of that, just turn on DEBUG_BUILD for everything except Release
14:47.26starseekerisn't even sure how to test for Microsoft system libraries...
14:49.16CIA-62BRL-CAD: 03starseeker * r45646 10/brlcad/trunk/misc/enigma/enigma.c: clang didn't like argc not having a type
14:52.13starseekerisn't sure he agrees with making the MSVC specific stuff into tests - that'll just lengthen the configure process even further, and the probability is very high that those options will be useless everywhere else (or even worse, might mean something altogether different, given how foreign MSVC is to other environments)
14:58.22*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
15:04.02CIA-62BRL-CAD: 03starseeker * r45647 10/brlcad/trunk/src/other/libpng/CMakeLists.txt: Add the new, improved libpng CMakeLists.txt macros from our 1.4.x build - this is what should go back to libpng as a proposed patch.
15:21.22CIA-62BRL-CAD: 03starseeker * r45648 10/brlcad/trunk/src/other/ (3 files in 2 dirs): OK, I think we've gotten rid of 'em now - try again to remove scl_string
15:33.24brlcadstarseeker: having a default checkout that doesn't perform a system install breaks convention in itself, /usr/local is usually the default which is where our /usr/brlcad becomes preferred so we're protected
15:35.50brlcadthere's also a portability issue for some platforms (like aix, hpux, some linux, and few others) where binaries are not relocatable by default, so if you installed into your home directory, you can't just copy that (e.g., into /usr/brlcad) and have it work, have to set library paths and our brlcad root/data paths in the environment
15:36.57starseekerright, but I had figured when doing a debug (e.g. development) build installing in /usr/brlcad was less likely to be important (I personally never install there while doing development)
15:36.59brlcadplus it matches our project history, we consistently install into /usr/brlcad by default -- others can set a prefix
15:37.40brlcadto a user checking out from svn, there is a surprise that I just did a checkout, compile, install ... and it's not installed
15:37.57brlcadat least not where I'd expect it, not in a system location
15:38.26starseekerwell... I suppose I could go back to defaulting to /usr/brlcad if CMAKE_BUILD_TYPE is not set...
15:38.38brlcadand you should be installing into /usr/brlcad ... else we end up with mysterious path problems when mged is attempting to load :)
15:39.11starseeker<snort> I would have thought installing somewhere other than /usr/brlcad would be MORE likely to highlight path problems, not less
15:39.31brlcadrelease going to /usr/brlcad/rel-VERSION and non-release going to /usr/brlcad/dev-VERSION is actually a nice consistency
15:40.10brlcadit did highlight problems.. the /usr/brlcad one didn't work :)
15:40.16starseekernods - I can live with it, I just liked the idea of doing a checkout/build/install for development purposes without having to worry about system permissions
15:41.39brlcadend-user convenience should always take priority over developer convenience
15:41.48brlcadi'm a stout believer in that stance
15:42.03starseekerend users use RPMs or package managers :-P
15:42.05brlcadusers get the shaft WAY too often in open source
15:42.14brlcadend users include anyone that's not a developer
15:43.57brlcadwhich includes users that checkout from the repository, or that would pick up a nightly source tarball...
15:44.47brlcadstill, it's more just about not *intentionally* making things more difficult or compilicated when it's just a matter of convention or a few keystrokes more or a few more lines in build files to help make it easier
15:48.34starseekershrugs. OK, I can live with dev-VERSION.
15:49.29brlcadso next topic? :)
15:49.41brlcadI'd expect microsoft system libs are tested for like any other library, no?
15:49.49starseekerhmm... idea.  If I look for a BRL-CAD_build_settings.cmake file early in the CMakeLists.txt and load it if found, that would provide a way for a developer to customize things without disturbing end-users - would that be OK?
15:50.35starseekerbrlcad: I suppose there might be a way to test for Microsoft librarys - I have no idea if the standard CMake mechanisms will do it though.
15:51.12starseekerMaybe we can wrap that set of tests in in MSVC conditional in the toplevel so we don't waste time with them on Mac/Linux at least?
15:51.28brlcadthe issue is really what happens to a default user -- if someone actively sets up their config, that's akin to setting -Dvar=val or --prefix options and it's peachy keen
15:51.54starseekerawesome - I mainly want a way to minimize the number of config options/flags I have to pass over and over
15:52.01brlcadnods
15:52.06brlcadperfectly reasonable
15:52.18brlcadwhen was the last time you built the linux kernel (by hand)?
15:52.24starseekerthe configure wrapper helps some there, but not really enough
15:52.46brlcadthey had a pretty neat setup
15:52.46starseekerbrlcad: define by hand - using their grapical config tool, or item-by-item?
15:52.55brlcadeither really
15:53.00brlcadso you config the kernel, right?
15:53.07brlcadit ends up with a config file with all your settings
15:53.16starseekeryeah - usually whenever I get a new machine, so the gentoo kernel has the right modules
15:53.20starseekerright
15:53.23brlcadso even after config is done, you can go in, edit it, and run with those new settings
15:53.37brlcadsomething like that would be awesome
15:53.58starseekernods - CMakeCache.txt does some of that, but not "up front" before a configure is run
15:54.13brlcad"cmake path" resulting in a .GLOBAL would be fun :)
15:54.43starseekerbrlcad: in case I haven't mentioned it - you can hand edit the CMakeCache.txt file in the toplevel build to change options
15:54.44brlcadI think linux uses .CONFIG?
15:55.20brlcadit's configurable iirc, but defaults to something like that
15:55.23starseekerfor post configure settings caching, CMakeCache.txt should have everything you could want
15:56.03brlcadso common use case that comes to mind .. we have all these tests for opengl
15:56.12brlcaduser runs cmake, it fails the test
15:56.16brlcadbut they know they have it
15:56.58brlcadsure enough, "make" just skips our ogl code; so they go in and edit the build config file, turn ogl on, re-run make .. and it builds
15:57.04brlcadsomething like that doable?
15:57.21starseekeryeah - that's what I usually do if I forget to turn something on
15:57.44brlcadso maybe just a better name than CMakeCache.txt :)
15:58.01brlcador is that literally every function/header/feature test?
15:58.37starseekerbrlcad: heh - hardwired, I think.  But my point wasn't that I want that ability AFTER running cmake - I want to always pass (say) BRLCAD-ENABLE_ALL_LOCAL_LIBS=ON without having to type it every time, and without having to edit the cache file
15:59.01brlcadblocking the MSVC-only tests would be fine -- that's what I was thinking -- it's more that they should still be tested for like any other feature since they're just as ephemeral as any of the other libs
15:59.25brlcadwinsock2, for example, is one of several incarnations of the windows networking interface
16:00.41brlcadstarseeker: right, I got that -- but I figured that should just be a matter of (re-)loading it during cmake for defaults as well as during make to drive compilation
16:01.08brlcadso if CMakeCache.txt is hardwired, maybe we could output just the high-level options we care about to a different config file
16:01.15starseekernods
16:01.16brlcadbasically, the summary items
16:01.21starseekerlet me experiment a bit
16:01.59brlcadlikes the .GLOBAL/_GLOBAL inside "joke"
16:02.02starseekerthis is over and above anything autotools ever provided (unless you count storing a configure line in a .sh file) so it's probably not a high priority - I'm just lazy about typing options :-P
16:02.18brlcadit is above it
16:02.27brlcadsomething I thought about adding a few times, though
16:02.29starseekerwinces a little - maybe BRL-CAD_CONFIG.GLOBAL
16:03.15brlcadusers already know they're in a brl-cad checkout, no need to remind them in all the file names :)
16:03.38brlcadeven just CONFIG would probably be fine
16:03.59starseekerhadn't envisioned putting it in the checkout or even the build dir - this would be something that could be stored (optionally) in the parent directory
16:04.28brlcadI didn't mean put it in checkout
16:04.40brlcadfile generated by cmake, reused by cmake and make
16:05.00starseekershakes his head - I want to be able to use this to set options before I ever run CMake at all
16:05.36brlcadnothing I've said precludes that  ???
16:06.00starseekercmake can't generate a file in the parent directory - oh, wait
16:06.08starseekerhmm.  
16:06.30brlcadI presume by parent you mean user's home dir or something?
16:06.35starseekerbasically
16:06.49starseekerone config file to rule them all :-P
16:07.14starseekerI guess we can check for and read that in, then generate something in the build directory for subsequent use in that run
16:07.23brlcadhm, that's a little odd
16:07.45starseekerbrlcad: might be odd, but it would be completely harmless unless someone specifically sought it out and set it up
16:08.08brlcadsure, but it can be turned into a proper feature and achieve the same result
16:08.48starseekeruh... I guess I'm not following
16:09.13brlcadstill thinking to the linux kernel as a model to follow
16:09.44brlcadI can craft up my own CONFIG file and specify it to the build (from wherever really)
16:10.01brlcador I can run the interactive build (cmake .) and it'll dump out a CONFIG file for me
16:10.15brlcadwhich I can subsequently reuse if I wanted (from anywhere)
16:10.21brlcadedit to heart's content
16:10.32brlcador ignore and the build just uses it for settings
16:11.12brlcadfamiliar, time tested, pretty simple
16:16.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:26.45*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:34.55*** join/#brlcad Stattrav_ (~Stattrav@117.192.146.20)
17:09.59*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
17:34.55CIA-62BRL-CAD: 03starseeker * r45649 10/brlcad/trunk/CMakeLists.txt:
17:34.55CIA-62BRL-CAD: Add a dirt-simple way to allow developers to inject their own default settings
17:34.55CIA-62BRL-CAD: into the CMake process - eventually we may want to do something more
17:34.55CIA-62BRL-CAD: sophisticated, but this is a simple way to do things like enable all local
17:34.55CIA-62BRL-CAD: libraries by default.
18:34.40brlcadstarseeker: what does it mean to be a release build?
18:35.03brlcadis that merely synonymous with non-debug? .. or what if I wanted a debuggable release build?
19:30.47brlcadstarseeker: so unexpected behavior .. cd brlcad ; mkdir .cmake ; cd .cmake ; cmake .. ; echo "why aren't there any build files output here?"
19:56.43*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
20:08.40*** join/#brlcad tharis20_ (~tharis@2.83.244.20)
21:10.19starseekerstarseeker: right now it's mostly /usr/brlcad/rel* paths and turning on optimization by default
21:11.20starseekerformally acknowledges not outputing build files in expected directory if there is a CMakeCache.txt file in the source dir is Not Good
21:11.33starseekerbrlcad: right now it's mostly /usr/brlcad/rel* paths and turning on optimization by default
21:11.38starseekeris talking to himself again
23:29.45*** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net)
23:32.42LainIwakuraXbrlcad: I see a lot of updates to step stuff in the latest rev. sorry I wasn't here in the afternoon to help =(
23:46.28tharis20brlcad: in the expectations it is said that it is expected students to work 40 hours a week, the same as a full-time job
23:46.50tharis20but SOCIS extends until the end of October and classes begin in mid-September
IRC log for #brlcad on 20110727

IRC log for #brlcad on 20110727

00:04.25LainIwakuraXstarseeker, brlcad, whenever you guys see this- I checked the SOCIS project timeline and about 2 months of it overlaps with University, I can't comfortably commit to school, the project, and my part-time work. I'm staying here as a regular contributor though =)
00:20.34``Eriklooks like most of europe starts school in early-mid september, I wonder if they're aware of that O.o unfortunate that there's such a huge overlap
00:21.37LainIwakuraXYeah Canada too, I wish I could apply but it's not feasible or fair =(
00:21.51LainIwakuraX(to the project + me)
00:22.27``Erikbrlcad: since you're the point of contact with them, are you going to contact them to see what's up? http://en.wikipedia.org/wiki/Summer_vacation lists the 'common' dates for most countries
00:22.58``Erikassumed that EU nations had a longer or later break, but it doesn't seem so
00:23.45``Erikand a 40hr job plus school can be pretty brutal, did it to pay my tuition 'n books O.o
00:25.37LainIwakuraXheh, I'd like to be superman =P but 40hr SOCIS, 5 Full time courses in school, and a part-time job
00:25.39``Erikheh, of course esa is part of the cern blocks, so only students from cern nations can participate :/
00:25.42LainIwakuraXToo crazy lol
00:26.56tharis20exactly, with school, available time reduces significantly
00:28.04tharis20and although, in the beginning, there's not much work to do, in Portugal (where I live) there's a tradition for sophomores to participate in activities with freshmen, a thing called "Praxe"
00:28.28tharis20http://en.wikipedia.org/wiki/Praxe
00:29.22LainIwakuraXIn Canada we get homework =(
00:30.30tharis20LOL In Portugal it depends on the Univ. there are some that send mandatory homework. Mine sends homework for those who want to do homework. :x
00:30.55``ErikI have to scoot, awesome if you're willing to continue contributing regardless... hopefully something will get sorted out :) later
00:31.32LainIwakuraXYeah this project has piqued my interest =P definitely sticking around
00:31.51tharis20I'd like to know if even with school one is expected to work as a full-time job
00:32.21tharis20but regardless of SOCIS, I think I will contribute to this project
00:32.52tharis20been looking for an open-source project to work that he really likes
00:33.07LainIwakuraX^
00:37.22tharis20oh man, I don't know how I'm going to wake up early tomorrow...
03:36.56brlcadLainIwakuraX: it's alright, happens ... and more importantly great to hear you're still interested in dev ;)
03:37.39brlcad``Erik: yeah, they wanted to start earlier (part of why the schedule is so tight already) .. but didn't get management approval till late
03:38.45brlcadfrom the mailing list discussions, their familiarity and decision processes sound almost exactly like how I imagined arl dealing with running a gsoc-style program
03:56.08LainIwakuraXbrlcad: I did an svn update and a lot of STEP stuff changed but I still get the same error that silently crashes step-g
03:56.24brlcadLainIwakuraX: yeah, the crash hasn't been fixed yet
03:57.44LainIwakuraXkk, I won't be able to get to it tonight but tomorrow / thursday I can probably spend a good while on it
03:57.53LainIwakuraXI don't really know what's still causing it though =/
04:17.27CIA-62BRL-CAD: 03brlcad * r45650 10/brlcad/trunk/src/other/step/src/ (8 files in 2 dirs): std::string are declared in <string>, not <string.h>; fix r45627.
04:24.24LainIwakuraXI'm out for the night
05:32.40starseekerbrlcad: er, oops - sorry about that
07:07.15*** join/#brlcad merzo (~merzo@193.254.217.44)
08:27.09*** join/#brlcad CalinPaulAlexand (524f464d@gateway/web/freenode/ip.82.79.70.77)
08:29.01*** join/#brlcad Stattrav (~Stattrav@122.178.209.201)
08:29.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
09:00.40*** join/#brlcad archivist_emc (~archivist@host81-149-189-98.in-addr.btopenworld.com)
09:55.09*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
10:25.37*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:42.23CIA-62BRL-CAD: 03indianlarry * r45651 10/brlcad/trunk/src/other/step/src/clstepcore/ (ExpDict.h ExpDict.inline.cc sdaiApplication_instance.cc): Changed parameter 'schnm' back to 'const char *' for functions SchRename::rename() and TypeDescriptor::Name().
14:38.30*** join/#brlcad merzo (~merzo@193.254.217.44)
15:30.37brlcadstarseeker: revisiting yesterday's discussion .. turns out the cache behavior is actually not a bug, just bad design
15:31.02brlcadthe path parameter specifies EITHER a source dir or a build dir
15:32.02brlcadthat actually seems a bit asinine to me since all it avoids is a 'cd' but introduces the unexpected behavior since they flip the meaning of the path argument
16:17.34brlcadlooks like r45651 fixed step-g for me
17:22.28brlcadaha fixed!
17:22.37brlcad(a different subtle bug)
17:30.55CIA-62BRL-CAD: 03brlcad * r45652 10/brlcad/trunk/src/other/step/src/clstepcore/read_func.cc: ws consistency
17:37.30CIA-62BRL-CAD: 03brlcad * r45653 10/brlcad/trunk/src/other/step/src/clstepcore/ (README sdaiString.cc): update the README to reflect the current directory contents. was referring to files and classes that were renamed/refactored and/or no longer exist.
17:41.02CIA-62BRL-CAD: 03brlcad * r45654 10/brlcad/trunk/src/other/step/src/clstepcore/ (README sdaiString.cc): revert r45653, unintentional inclusion of a bug fix that begs documenting
17:42.06CIA-62BRL-CAD: 03brlcad * r45655 10/brlcad/trunk/src/other/step/src/clstepcore/README: update the README to reflect the current directory contents. was referring to files and classes that were renamed/refactored and/or no longer exist.
17:50.40CIA-62BRL-CAD: 03brlcad * r45656 10/brlcad/trunk/src/other/step/src/clstepcore/sdaiString.cc: (log message trimmed)
17:50.40CIA-62BRL-CAD: fix a bug introduced with the conversion of SCL's string management to using
17:50.40CIA-62BRL-CAD: STL's std::string. null values were getting injected into the parsing output
17:50.40CIA-62BRL-CAD: since std::string will happily record a zero-character and keep track of how
17:50.40CIA-62BRL-CAD: long the c-string buffer is independent of null-termination. the streams
17:50.40CIA-62BRL-CAD: happily print the entire buffer (i.e., not relying on null termination) causing
17:50.41CIA-62BRL-CAD: literal '\0' values to get output. fix was simple, don't append '\0' values.
17:50.46brlcadthat took a while to find/fix!
17:57.44starseekerbrlcad: nicely done!
18:15.16brlcadnow to profile
18:17.16brlcadinitial test showed a speedup
20:14.00CIA-62BRL-CAD: 03brlcad * r45657 10/brlcad/trunk/src/conv/step/step-g.cpp: make sure we can read the input step file before stubbing in an empty .g file that gets in the way on follow-up invocations. stub in support for stdin piped input too.
20:14.41CIA-62BRL-CAD: 03brlcad * r45658 10/brlcad/trunk/src/conv/step/STEPWrapper.h: use std:: prefix on stl types
20:15.00CIA-62BRL-CAD: 03brlcad * r45659 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp: ws indent consistency cleanup
20:27.35*** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net)
20:35.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:35.24CIA-62BRL-CAD: 03erikgreenwald * r45660 10/brlcad/trunk/src/libgcv/bottess.c: do vertex/plane throwaway on triangle intersection test
20:37.47*** join/#brlcad Stattrav_ (~Stattrav@117.192.134.140)
20:46.08*** join/#brlcad Stattrav (~Stattrav@117.192.140.17)
20:46.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:48.49CIA-62BRL-CAD: 03brlcad * r45661 10/brlcad/trunk/src/conv/step/step-g.cpp: print status when writing the output file
21:08.24CIA-62BRL-CAD: 03brlcad * r45662 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp: trim a little so the summary will usually fit within 80 columns, let user know if input came from stdin
21:11.56CIA-62BRL-CAD: 03brlcad * r45663 10/brlcad/trunk/src/other/step/src/cleditor/ (STEPfile.cc STEPfile.inline.cc): add support for reading exchange/express/step input from standard input. if the filename provided is a '-', it will be treated special to imply standard input.
21:25.22LainIwakuraXbrlcad: It looks like that step-g crash has been fixed! awesome =)
21:27.34brlcadLainIwakuraX: yeah, mostly due to indianlarry -- looks like you were passing std::string as a char* in a few places
21:28.38brlcadon a positive note, I'm seeing a rough 20% performance increase on (smallish) step models
21:28.56brlcadunfortunately, diminishes towards 0% increase as the models get bigger and more realistic
21:29.07brlcaddominated by other processing time
21:33.05LainIwakuraXahh I thought I had those spots worked out
21:33.27LainIwakuraXit was tricky because SCLstring appears to behave similar to regular C strings =/
21:33.49LainIwakuraXWell at least it's all good now
21:53.49CIA-62BRL-CAD: 03erikgreenwald * r45664 10/brlcad/trunk/src/libgcv/bottess.c: Fast test for coplanar triangles. Find direction vector of intersecting line and projection direction. Make noise-code compile time switchable.
22:10.23*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
22:12.06brlcadLainIwakuraX: it's *hopefully* all good for now -- our importer only exercises a small portion of scl :/
22:12.36brlcadthe other bug was in Sdai_String where you inherited from std::string
22:12.53brlcadit was manually appending '\0' values, which caused a bit of a mess in the output
22:13.20brlcadbecause std::string will happily append and print null values, where c-strings halt on null-termination
23:55.23*** join/#brlcad ibot (~ibot@rikers.org)
23:55.23*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
23:57.52CIA-62BRL-CAD: 03bhinesley * r45667 10/brlcad/trunk/src/libged/edit.c:
23:57.53CIA-62BRL-CAD: Laid out additional subcommand functions, and added pointers to them into the
23:57.53CIA-62BRL-CAD: array of edit_cmd structs. This will help keep subcommands separate from the
23:57.53CIA-62BRL-CAD: edit routines, so adding/modifying commands will be more isolated/simpler than I
23:57.53CIA-62BRL-CAD: had originally planned. Started on edit(). None of this is not tested very well
23:57.53CIA-62BRL-CAD: yet. WIP
23:58.58bhinesleyhm, r45678 coming up
23:59.01bhinesleyputs on party hat
23:59.16brlcadhehe
23:59.26brlcadgoes to get sparklers
IRC log for #brlcad on 20110728

IRC log for #brlcad on 20110728

00:00.00LainIwakuraXlol
00:11.21CIA-62BRL-CAD: 03brlcad * r45668 10/brlcad/trunk/src/conv/step/step-g.cpp: always tear down the factory
00:13.42CIA-62BRL-CAD: 03brlcad * r45669 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp: dotg != dot_g
00:49.48*** join/#brlcad tharis20 (~tharis@dyn896-219.eduroam.ic.ac.uk)
00:50.57LainIwakuraXOut for the night
00:57.55*** join/#brlcad tharis20 (~tharis@dyn896-219.eduroam.ic.ac.uk)
01:54.26CIA-62BRL-CAD: 03kunigami * r45670 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): added support for vector/normal/point and matrix shader parameters
03:07.52CIA-62BRL-CAD: 03brlcad * r45671 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp: sanity, abort if we encounter a null
03:08.07CIA-62BRL-CAD: 03brlcad * r45672 10/brlcad/trunk/src/conv/step/ (5 files): ws
04:22.17CIA-62BRL-CAD: 03brlcad * r45673 10/brlcad/trunk/configure.ac: PNG libtool library is now libpng15.la
04:27.20CIA-62BRL-CAD: 03brlcad * r45674 10/brlcad/trunk/src/libbn/plane.c: parallel is set but unused, kill it
04:34.05CIA-62BRL-CAD: 03brlcad * r45675 10/brlcad/trunk/src/libbn/plot3.c: more variable set-but-unused warnings from gcc 4.7 (prerelease), but these are actually needed. check the ret value and perror if we didn't write all that was expected.
04:38.20*** join/#brlcad DarkCalf (DC@173.231.40.98)
04:40.45CIA-62BRL-CAD: 03brlcad * r45676 10/brlcad/trunk/src/librt/bundle.c: status is unused, remove
04:52.42CIA-62BRL-CAD: 03brlcad * r45677 10/brlcad/trunk/src/conv/step/ (STEPWrapper.cpp STEPWrapper.h): convert InstMgr from an embedded class to a pointer with allocation on the heap
05:15.31CIA-62BRL-CAD: 03brlcad * r45678 10/brlcad/trunk/src/librt/prep.c: yet another example why strict compilation is a "good thing" (tm). quell warning about old_max being set but unused. turns out this was a bug introduced several years ago in r36723 after a simple refactoring.
05:17.46CIA-62BRL-CAD: 03brlcad * r45679 10/brlcad/trunk/src/other/step/src/cleditor/instmgr.cc: plug a memory leak accounting for almost a half MB. delete the InstMgr master and sorted master manager node arrays.
05:34.37CIA-62BRL-CAD: 03brlcad * r45680 10/brlcad/trunk/src/librt/primitives/ (bot/btgf.c dsp/dsp.c): remove unused var
05:36.15CIA-62BRL-CAD: 03brlcad * r45681 10/brlcad/trunk/src/librt/primitives/bspline/bspline.cpp: and again, strictness catches a bug -- this one affects being able to dbupgrade/dbopen incompatible v4 files. it basically was reading in old bpline objects without applying a properly byte-flipped matrix.
05:38.13CIA-62BRL-CAD: 03brlcad * r45682 10/brlcad/trunk/src/other/step/src/cleditor/STEPfile.inline.cc: delete the instances before deleting the container, don't just clear them. plugs memory leak (though there is still lots to go for scl)
05:41.30CIA-62BRL-CAD: 03brlcad * r45683 10/brlcad/trunk/src/other/step/TODO: leaking something nasty
06:50.59*** join/#brlcad merzo (~merzo@193.254.217.44)
07:00.34CIA-62BRL-CAD: 03brlcad * r45684 10/brlcad/trunk/src/librt/ (13 files in 9 dirs): quell a slew of gcc 4.7 detections of variables being set but weren't being used. one of the nmg routines, nmg_eval_linear_trim_to_tol(), is a little suspect but the rest were mostly benign.
09:59.59CIA-62BRL-CAD: 03bhinesley * r45685 10/brlcad/trunk/src/libged/edit.c: (log message trimmed)
09:59.59CIA-62BRL-CAD: Renamed stupid "*_concise" functions to "*_wrapper". Added functions to get the
09:59.59CIA-62BRL-CAD: next argument "head" in the union edit_cmd. Not too happy about adding yet
09:59.59CIA-62BRL-CAD: another command-specific function; but it seems necessary to keep separation,
09:59.59CIA-62BRL-CAD: while still having an intuitive way to build arguments (id est union edit_cmd).
10:00.00CIA-62BRL-CAD: With these functions, we'll be able to pass over all of a command's arguments,
10:00.01CIA-62BRL-CAD: without being aware of the union edit_cmd layout. The new plan is to keep edit()
11:00.10*** join/#brlcad Stattrav (~Stattrav@122.178.209.201)
11:00.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:04.06*** join/#brlcad Stattrav_ (~Stattrav@111.93.134.142)
11:12.08*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
11:12.08*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:10.46*** join/#brlcad Stattrav (~Stattrav@111.93.134.142)
12:10.46*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:08.16CIA-62BRL-CAD: 03brlcad * r45686 10/brlcad/trunk/src/libfb/ (if_X.c if_X24.c): quell set-but-unused warnings
13:11.30CIA-62BRL-CAD: 03brlcad * r45687 10/brlcad/trunk/src/libgcv/bottess.c: dir unused
13:14.02CIA-62BRL-CAD: 03brlcad * r45688 10/brlcad/trunk/src/libgcv/bottess.c: actually, build just wasn't up to date -- dir is used now, but i is not. quellage.
13:17.41CIA-62BRL-CAD: 03brlcad * r45689 10/brlcad/trunk/src/libged/ (bo.c bot_dump.c): remove slew of set-yet-unused vars
13:22.29CIA-62BRL-CAD: 03brlcad * r45690 10/brlcad/trunk/src/libged/edit.c: gcc 4.7 no longer considers these constant/computable at compile-time. so, meh, set them at runtime.
13:26.55CIA-62BRL-CAD: 03brlcad * r45691 10/brlcad/trunk/src/libged/ (glob.c human.c): more set-and-unused var elimination
13:30.22CIA-62BRL-CAD: 03brlcad * r45692 10/brlcad/trunk/src/libpc/pcVariable.h: j unused
13:31.59CIA-62BRL-CAD: 03brlcad * r45693 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: points a and b are unused, remove
13:32.46brlcadi'm liking this new version of the compiler .. the warnings have actually caught a slew of bugs, some minor, some not-so-minor
13:40.31CIA-62BRL-CAD: 03brlcad * r45694 10/brlcad/trunk/include/bu.h: the pointer!=NULL comparison is always true for variables on the stack. cast through void so the compiler will shut it.
13:42.25CIA-62BRL-CAD: 03brlcad * r45695 10/brlcad/trunk/src/libged/ (png.c ps.c red.c screengrab.c tire.c): remainder of libged set-and-unused warnings
13:51.54CIA-62BRL-CAD: 03brlcad * r45696 10/brlcad/trunk/src/liboptical/photonmap.c: unused due to commented code
13:52.56CIA-62BRL-CAD: 03brlcad * r45697 10/brlcad/trunk/src/libdm/labels.c: we dont' do anything with id, so don't bother saving it from rt_db_get_internal()
13:54.42CIA-62BRL-CAD: 03brlcad * r45698 10/brlcad/trunk/src/conv/ (3dm/3dm-g.cpp dxf/dxf-g.c step/OpenNurbsInterfaces.cpp): set-and-unused quellage
13:56.17CIA-62BRL-CAD: 03brlcad * r45699 10/brlcad/trunk/src/librtserver/rtserver.c: idx and los are unused, so get rid of them
13:58.53CIA-62BRL-CAD: 03brlcad * r45700 10/brlcad/trunk/NEWS:
13:58.53CIA-62BRL-CAD: preliminary testing of the conversion from SCLstring to std::string is showing a
13:58.53CIA-62BRL-CAD: consistent speed improvement in step-g for relatively small models. Models
13:58.53CIA-62BRL-CAD: taking less than a few minutes to convert are now taking approximately 10-30%
13:58.53CIA-62BRL-CAD: less time. Unfortunately, models that take more than 10-20 minutes still take
13:58.53CIA-62BRL-CAD: 10-20 minutes implying that some other processing dominates as the files get
13:58.53CIA-62BRL-CAD: bigger.
14:10.19CIA-62BRL-CAD: 03brlcad * r45701 10/brlcad/trunk/src/lgt/ (do_options.c screen.h):
14:10.19CIA-62BRL-CAD: let TEMPLATE_COLS represent the number of chars not including null, so we're
14:10.19CIA-62BRL-CAD: protected on both ends of printing. more tricky, gcc detected that the
14:10.19CIA-62BRL-CAD: snprintf() range provided was too much since IR_AUTO_MAP_PTR already indexes far
14:10.19CIA-62BRL-CAD: into template.
14:12.47brlcadand with that, we have our first clean strict pass on 4.7
14:13.43brlcadstill have to test optimized and 32-bit
14:14.05brlcadhits the road
14:15.31CIA-62BRL-CAD: 03erikgreenwald * r45702 10/brlcad/trunk/src/libgcv/bottess.c: put the i's back, they're necessary for the next step
14:23.05brlcad``Erik: I figured that was a work-in-progress .. but the newer compiler builds now halt on incomplete code that's enabled
14:24.18brlcadwe'll have to #if-wrap works in progress that get committed (that i var is actually the only one that was active code, surprisingly)
14:24.54brlcadrather like it actually, encourages coding complete (and committing complete) instead of stubbed functionality
14:38.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:39.00``Erik<PROTECTED>
14:39.34``Erikwould rather not do a 2000 line commit O.o
14:45.21*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
15:28.23brlcad``Erik: I think it's smart enough to recognize that's a no-op and the var is still unused now
15:32.38brlcadstarseeker: so there are just two or three files that keep getting edited in the source directory
15:32.42brlcadcmake is building built in a separate build dir
15:32.50CIA-62BRL-CAD: 03r_weiss * r45703 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
15:32.51CIA-62BRL-CAD: Added two new functions to support the prototype version of nmg_triangulate_fu.
15:32.51CIA-62BRL-CAD: These functions are 'nmg_tri_kill_accordions' and 'validate_tbl2d'. The first
15:32.51CIA-62BRL-CAD: function is a specialized version of the 'nmg_kill_accordions' function which
15:32.51CIA-62BRL-CAD: allows killed vertexuse to be removed (nulled out) from the tbl2d table. The
15:32.51CIA-62BRL-CAD: second function verifies that all vertexuse within a faceuse is stored in the
15:32.52CIA-62BRL-CAD: tbl2d table. These functions are a work in progress and are disabled by default.
15:32.52brlcadzconf.h
15:33.41brlcadcssprop.tcl, tokenlist.txt
15:34.00``Erikcommits and runs O.O
15:34.00CIA-62BRL-CAD: 03erikgreenwald * r45704 10/brlcad/trunk/src/libgcv/bottess.c: gut stuff and use straight moller97, modified for BRL-CAD types
15:48.13CIA-62BRL-CAD: 03r_weiss * r45705 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: Rewrote the 'nmg_kill_accordions' function within file 'nmg_mod.c'. The new version has cleaner logic and will continue to remove all accordions from a loopuse.
15:54.33*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
15:59.31CIA-62BRL-CAD: 03r_weiss * r45706 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
15:59.31CIA-62BRL-CAD: Updated function 'find_pt2d' within file 'nmg_tri.c'. This change allows this
15:59.31CIA-62BRL-CAD: function to receive a null vertexuse pointer without crashing. In addition, when
15:59.31CIA-62BRL-CAD: passed a null vertexuse pointer, this function will return the first entry in
15:59.31CIA-62BRL-CAD: the table which contains a null vertexuse pointer. This is useful for finding
15:59.32CIA-62BRL-CAD: entries in the table which can be reused instead of allocating a new table
15:59.33CIA-62BRL-CAD: entry.
16:16.07brlcadbhinesley: looks like a strict 4.6 build should work just fine now
16:46.28CIA-62BRL-CAD: 03r_weiss * r45707 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
16:46.29CIA-62BRL-CAD: Updated function 'join_mapped_loops' within file 'nmg_tri.c'. Added more error
16:46.29CIA-62BRL-CAD: checking and did some code cleanup and improved the existing error messages.
16:46.29CIA-62BRL-CAD: Changed some of the logic to support the prototype version of the
16:46.29CIA-62BRL-CAD: 'nmg_triangulate_fu' function. Under certain conditions a new vertexuse can be
16:46.29CIA-62BRL-CAD: created and it was not adding this to the tbl2d table. The logic changes are a
16:46.30CIA-62BRL-CAD: work in progress and are disabled by default.
17:41.31CIA-62BRL-CAD: 03brlcad * r45708 10/brlcad/trunk/src/conv/step/BRLCADWrapper.cpp: close the database on destruction, null out the pointer just in case
17:43.52bhinesleybrlcad, sorry, there are still some issues: http://paste.pocoo.org/show/448279/
17:44.23CIA-62BRL-CAD: 03brlcad * r45709 10/brlcad/trunk/src/conv/step/step-g.cpp: so there is definitely some funky stack corruption going on. deleting the step wrapper crashes, investigating.
17:44.55bhinesleyI cut out the middle of the file around 337, because it was too big to upload. The lines I cut out were similar to the ones directly before it.
17:45.26brlcadbhinesley: no need to be sorry, that's good
17:45.54brlcadstrictness almost always requires multi-platform compilation to get all the issues ironed out
17:49.59CIA-62BRL-CAD: 03brlcad * r45710 10/brlcad/trunk/src/conv/step/STEPWrapper.cpp: my bad, STEPWrapper doesn't get to own the dotg instance, they're stashing it for future use. was causing double-delete badness.
17:50.50CIA-62BRL-CAD: 03brlcad * r45711 10/brlcad/trunk/src/conv/step/step-g.cpp: safe to delete stepwrapper again
17:54.08bhinesleybrlcad: that trimmed it down enough so that I can upload the whole file now: http://paste.pocoo.org/show/448285/
17:54.18brlcadcool, thx
17:54.28bhinesleynp
17:54.43bhinesleyoops, wait... that was the old one
17:54.58brlcadso in actuality, only a dozen or so issues remaining
17:55.17brlcadall the SdaiCONFIG_CONTROL_DESIGN ones aren't fatal (that's auto-generated code)
17:56.33bhinesleynods
17:57.01bhinesleywgetpaste is playing tricks on me... uploading the old version of a file that has been overwritten (!)
17:59.40bhinesleyahh, n/m, it's a problem with my primary selection/clipboard. The link in here is good, the link getting pasted into my browser is old.
18:03.32bhinesleycounts about 50 errors, probably only a dozen or so unique as brlcad mentioned
18:45.51CIA-62BRL-CAD: 03r_weiss * r45712 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
18:45.51CIA-62BRL-CAD: Changed the function 'join_mapped_loops' within file 'nmg_tri.c'. I disabled one
18:45.51CIA-62BRL-CAD: of the error checks which was causing some problems. The error check is now only
18:45.51CIA-62BRL-CAD: enabled when the prototype version of function 'nmg_triangulate_fu' is enabled.
18:46.30CIA-62BRL-CAD: 03brlcad * r45713 10/brlcad/trunk/src/conv/step/SdaiCONFIG_CONTROL_DESIGN.cc: delete debug code
18:47.29abhi2011hi
18:47.43abhi2011I am trying to add a command to mged
18:48.03abhi2011its to learn how to add commands basically
18:48.21abhi2011so I have copied out the tire.c file to a new file physics.c
18:48.28abhi2011and made some changes
18:49.04abhi2011the command will be simply called runphysics and has no parameters
18:49.19abhi2011so apart from making a new source file, are there any other changes needed
18:49.33abhi2011to compile it as part of libged
18:53.25brlcadof course :)
18:53.46abhi2011in the CMakeLists.txt i guess
18:53.47brlcadotherwise how would libged know your new file from thesis.doc
18:54.09abhi2011haha
18:54.12abhi2011:)
18:54.12brlcadCMakeLists.txt and Makefile.am
18:54.17abhi2011ok
18:54.26brlcadwe have two build systems being maintained at the moment
18:54.29brlcadso two files
18:54.45abhi2011ok, and the specific CMakeLists.txt to be edited is the top level one in the brlcad directory i guess
18:54.49brlcadonce added, that will compile the file
18:55.13brlcadthen you'll either want to add a command binding to mged or create a stand-alone application wrapper
18:55.30abhi2011ah yes the command binding
18:55.34brlcadmged bindings are in src/mged/setup.c
18:55.37abhi2011there wqa a specific c file for that
18:55.38abhi2011right
18:55.53brlcadstand-alone wrapper would be writing a small binary like src/shapes/tire.c
18:56.05abhi2011ok
18:56.18abhi2011yah i ll try with the command binding first
18:56.24abhi2011though it makes more sense
18:56.31abhi2011to have it as a binary wrapper
18:56.53abhi2011I have an interesting question though
18:56.55brlcadmakes more sense as an mged command, but a binary wrapper will be easier for initial testing
18:57.03abhi2011yes exactly
18:57.21abhi2011and most physics engines
18:57.28abhi2011can launch an opengl render window
18:57.38abhi2011and show whats happening in the physics world
18:57.55abhi2011which can help at times
18:58.11brlcadwell, that would be mged
18:58.34abhi2011yes right, mged already shows an opengl windows
18:58.37brlcadwriting opengl or windowing code for a standalone binary would be undesirable, waste of time frankly
18:58.39abhi2011*window
18:58.47abhi2011yes right
18:59.11brlcadstandalone binary would be just to run the simulation, console debug printing, simplified testing
18:59.46abhi2011yes
19:00.31abhi2011I understand your point of course. Bullet already comes with accurate rendering code though :) so there is no need to write it :)
19:01.01brlcadBRL-CAD already comes with rendering code too, so there's no need to bind to a new 3rd party interface
19:01.11abhi2011hehe :) yes true
19:03.40CIA-62BRL-CAD: 03brlcad * r45714 10/brlcad/trunk/src/libdm/dm-ogl.c: quellage, remove set-but-not-used variables
19:06.45brlcadbhinesley: grep -E '(CURSES|TERM|TINFO)' include/brlcad_config.h
19:06.49brlcad(in your build dir)
19:07.00brlcad/home/bhinesley/brlcad-trunk/src/libcursor/cursor.c looks like a cmake detection failure
19:07.17brlcadnot testing for termcap or curses correctly
19:07.42brlcadsame thing with the burst too (Sc.c)
19:08.43brlcadso those look like the only three problems, dm-ogl.c which I just fixed and those two files (cursor.c and Sc.c) which have the same termcap detection problem
19:10.51abhi2011so I have added a new command just after rtweight
19:10.58abhi2011{"rtweight", cmd_rt, GED_FUNC_PTR_NULL},
19:10.59CIA-62BRL-CAD: 03brlcad * r45715 10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: debug code tracing down stack corruption accidentally got committed. re-enable advanced brep entity loading.
19:10.59abhi2011{"runphysics", cmd_rt, GED_FUNC_PTR_NULL},
19:12.39brlcaddoesn't look right
19:12.54brlcadyou were following the tire command, that's your example -- not rtweight
19:13.11brlcadat least in terms of what that line should look like, doesn't matter where it's at
19:17.29abhi2011ok yah the tire command is a wrapper ...right i ll change it
19:18.51abhi2011right this should be ok
19:18.54abhi2011<PROTECTED>
19:18.56abhi2011<PROTECTED>
19:18.57abhi2011<PROTECTED>
19:19.16abhi2011i changed the c function name of course in the .c file
19:24.10brlcadkunigami_: just to be sure, you have seen http://code.google.com/p/openshadinglanguage/w/list y es?
19:24.54bhinesleybrlcad: #define HAVE_TERMIO_H 1\n#define HAVE_TERMIOS_H 1
19:26.52kunigamibrlcad: yup. I didn't read the light path expression because I thought that was not a feature that would be useful for brlcad, or am I wrong?
19:29.28abhi2011brlcad: hmm I went through the CMakeLists.txt file in the brlcad top level directory, there does not appear to be a place to add a mged command there
19:29.38abhi2011for example I dont see tire anywhere
19:29.58abhi2011*mged application wrapper i mean, not a command
19:36.29brlcadabhi2011: not following
19:36.35brlcadyou add it to libged's file
19:36.35CIA-62BRL-CAD: 03brlcad * r45716 10/brlcad/trunk/src/other/ (CMakeLists.txt libz/CMakeLists.txt): test to see what breaks. leave the zconf.h file alone, don't abort if it exists.
19:37.43bhinesleyabhi2011: I think you're looking for libged/CMakeList.txt
19:38.46abhi2011ah yes,
19:38.57brlcadstarseeker: I'll give that a go with some testing, but that should be a pretty safe/easy change
19:39.07abhi2011I have added it to setup.c in src/mged/
19:39.17abhi2011and now I want to add it to the build logic
19:39.27brlcadbecause zconf.h isn't "actually" autogenerated .. at least zconf.h.in doesn't have any substitution patterns, so it's just a copy
19:39.49brlcadwhich means there could be a million copies in a million include dirs and it won't affect build in the least
19:40.01brlcadtesting now though
19:40.31abhi2011so I guess the right place to add the the new c file that implements runphysics  (i.e. src/libged/runphysics.c), to the build logic is libged/CMakeList.txt
19:42.06CIA-62BRL-CAD: 03brlcad * r45717 10/brlcad/trunk/src/other/libz/zconf.h.cmakein: remove the _LARGEFILE64_SOURCE hack from the cmake template too. causes build problems with system headers that also define it.
19:46.30abhi2011ok thats done, now the autotools build has to know about the new c file as well
19:46.50abhi2011So I guess the new filename should go into Makefile.am
19:46.58abhi2011in the top level directory
19:47.11bhinesleynope, in libged/Makefile.am
19:47.30abhi2011ah yes there is one there too...right of course
19:47.37bhinesleyhaha
19:47.44abhi2011:P
19:48.20abhi2011these make files and cmake files are all over the place !
19:49.13``Erikhm, cmake seems to do everything in it's power to prevent a profiling build
20:00.09starseekerbrlcad: yeah, I actually have added the two define options in the cmakein file in the CMakeLists.txt file as definitons, which means we don't need that file at all.
20:00.56CIA-62BRL-CAD: 03starseeker * r45718 10/brlcad/trunk/src/other/ (libz/CMakeLists.txt libz/zconf.h.cmakein libz.dist): Eliminate the need for a separate zconf.h.cmakein file by simply adding the definitions at the CMakeLists.txt level if they are needed.
20:03.53starseekerlooks at cssprop.tcl, tokenlist.txt to see if he can get them to change
20:11.12CIA-62BRL-CAD: 03r_weiss * r45719 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
20:11.12CIA-62BRL-CAD: Updated the prototype version of function 'cut_unimonotone' within file
20:11.12CIA-62BRL-CAD: 'nmg_tri.c'. This function supports the prototype version of function
20:11.12CIA-62BRL-CAD: 'nmg_triangulate_fu'. Improved the error checking and the logic to cleanup
20:11.12CIA-62BRL-CAD: problem loopuse. Also did some code cleanup. This change is disabled by default.
20:11.12CIA-62BRL-CAD: This is a work in progress.
20:19.07starseeker``Erik: here's a good quote for you:
20:19.11starseeker"You don't make a good language by smashing a bunch of "projects" together. If you do that, you end up with C++."
20:21.36CIA-62BRL-CAD: 03bhinesley * r45720 10/brlcad/trunk/src/libged/edit.c: Changed all union edit_cmd args to pointers. Kinda liked the idea of them being automatic, as it would simplify building commands, but we need to be able to shuffle them around easily for the *_add_arg functions.
20:22.57CIA-62BRL-CAD: 03bhinesley * r45721 10/brlcad/trunk/src/ (libdm/dm-ogl.c libtclcad/tclcad_obj.c): Quiet some compiler warnings about unused variables.
21:04.42CIA-62BRL-CAD: 03starseeker * r45722 10/brlcad/trunk/src/other/libpng/configure.ac: autogen failed - add back in what seem to be the related differences from the previous libpng configure.ac
21:06.33starseekerin case anyone else wants profiling w/cmake, it's BRLCAD-ENABLE_PROFILING
21:09.00``Erikyeh, srry, found that var earlier, only mentioned it to starseeker in person
21:17.32CIA-62BRL-CAD: 03starseeker * r45723 10/brlcad/trunk/src/other/libpng/configure.ac: whoops, typo
21:21.41starseekercool - with that zconf.h change, in principle the CMake build should now leave behind a pristine source tree
21:33.23CIA-62BRL-CAD: 03starseeker * r45724 10/brlcad/trunk/configure.ac: need both source and build dirs as includes now for libpng
21:35.44CIA-62BRL-CAD: 03starseeker * r45725 10/brlcad/trunk/NEWS: Upgraded libpng to 1.5.4
21:36.53starseekerbrlcad: yeah, I'm not seeing any changes to the tkhtml files here doing both an autotools and cmake out of dir build...
21:37.14starseekerguess the next thing to try is in dir...
21:50.59``Erikstarseeker: the slashdot comments on java7 release?
21:53.08starseekerheh - yeah
21:54.50CIA-62BRL-CAD: 03erikgreenwald * r45726 10/brlcad/trunk/src/libgcv/bottess.c: cleanup, more style normalization, removal of some dead code
21:55.38starseekerthat should take care of libpng, unless another platform exposes some issue - working on Linux now
22:01.44CIA-62BRL-CAD: 03starseeker * r45727 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Don't add omit-frame-pointer if we're profiling - things are Not Happy.
22:53.28CIA-62BRL-CAD: 03r_weiss * r45728 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: Updated the prototype version of function 'nmg_triangulate_fu' within file 'nmg_tri.c'. The logic was simplified and code cleanup was done. This change is disabled by default. This is a work in progress.
23:41.10*** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net)
IRC log for #brlcad on 20110729

IRC log for #brlcad on 20110729

00:25.36CIA-62BRL-CAD: 03bhinesley * r45729 10/brlcad/trunk/src/libged/edit.c: (log message trimmed)
00:25.36CIA-62BRL-CAD: Started on command-specific argument handling for translate, fixed some minor
00:25.36CIA-62BRL-CAD: problems, and simplified some things. Need to have edit() add appropriate flags
00:25.36CIA-62BRL-CAD: to command line args and remove command line character options from each arg's
00:25.36CIA-62BRL-CAD: cl_options[] before I can continue. Tried to add this functionality in
00:25.36CIA-62BRL-CAD: ged_edit() as it is originally adding the args, but it really needs to be done
00:25.37CIA-62BRL-CAD: on a second loop, since the arguments before and after the current arg make a
01:08.49CIA-62BRL-CAD: 03kunigami * r45730 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): started coding the (supposely) raytracer using OSL. the results are not correct
01:09.12kunigami_http://dl.dropbox.com/u/1399996/GSoC/Refraction-Weight.png
01:09.43kunigami_I still didn't find out how to get the colors from the shaders :(
01:11.25kunigami_What I'm currently doing is to traverse each light and call eval_reflect (I didn't understand why there exists eval_transmit) and get the average weight
03:04.46brlcadsomeone needs to tell r_weiss that he doesn't really need to mention the file name in his commit messages... kinda blatently redundant
03:05.40brlcadkunigami_: so what is that picture?
05:52.41*** join/#brlcad Stattrav (~Stattrav@122.178.209.201)
05:52.41*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:08.34*** join/#brlcad kanzure (~kanzure@131.252.130.248)
08:54.43*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
08:54.51abhi2011hi
08:55.09abhi2011So I was trying to add a new command yesterday to mged
08:55.18abhi2011I get this error during the build
08:56.03abhi2011http://bin.cakephp.org/view/276195617
08:56.29abhi2011seems after adding the implementing c function to setup.c, it has to be also declared somewhere
08:59.07bhinesleyabhi2011: lets see your setup.c line again
08:59.32abhi2011{"tire", cmd_ged_plain_wrapper, ged_tire},
08:59.34abhi2011<PROTECTED>
08:59.36abhi2011<PROTECTED>
08:59.53abhi2011the 2nd lie was added by me
09:00.39abhi2011i think ged_runphysics has to be declared in libged somewhere
09:01.14abhi2011maybe after i changed the implementation name in the c file
09:01.27abhi2011I have to declare it in a related header
09:02.28bhinesleythere are a ton of places for new commands to be "declared", for various uses. It's kind of a dark art. Try adding a line to the cmd_tab in src/libtclcad/tclcad_obj.c
09:03.31bhinesleynot sure if that will do you any good since you're trying to add it to mged only
09:03.47abhi2011ok i will try that
09:04.49abhi2011but are you sure there is no header file like src/libged/runphysics.h required for the newly added src/libged/runphysics.c
09:05.17bhinesleyyes, actually, I just recalled what it is you probably need: include/ged.h
09:05.31abhi2011i do have it included
09:05.38abhi2011let me paste the code 1 sec
09:06.21abhi2011http://bin.cakephp.org/view/1016518663
09:08.03bhinesleyOh, right... I meant that you probably need to add a ged_runphysics declaration to the file include/ged.h
09:08.04abhi2011but ged.h does not have a declaration of the new function in runphysics.c ,
09:08.05abhi2011int
09:08.06abhi2011ged_runphysics(struct ged *gedp, int argc, const char *argv[])
09:08.11bhinesleynods
09:08.13abhi2011ok
09:11.09abhi2011by the way, what does wdb routine mean
09:11.14abhi2011came across them in ged.h
09:12.21bhinesleysearch HACKING for libwdb
09:12.35abhi2011right :)
09:13.57abhi2011cool the build resumed again
09:14.14bhinesleycool
09:33.20CIA-62BRL-CAD: 03bhinesley * r45731 10/brlcad/trunk/src/libged/edit.c:
09:33.20CIA-62BRL-CAD: Updated several helper functions to work with a recent change from automatic
09:33.20CIA-62BRL-CAD: arguments in union edit_cmd to pointers. Added command-specific functions to
09:33.20CIA-62BRL-CAD: initialize the needed argument pointers. Fixed a problem with the help
09:33.20CIA-62BRL-CAD: subsystem, and eliminated a bit of redundancy. More edit() testing, but not a
09:33.20CIA-62BRL-CAD: whole heck of lot of foreward progress yet.
09:50.45kunigami_brlcad: it's the average weight returned by eval_reflect
11:46.25*** join/#brlcad Stattrav (~Stattrav@122.178.209.201)
11:46.25*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
12:18.36abhi2011success!!
12:18.41abhi2011new command added :P
12:22.10abhi2011I was wondering, regarding mged application wrappers
12:22.32abhi2011so suppose i have written a simple application that say just prints hello world
12:22.45abhi2011now I want to integrate it into mged
12:23.48abhi2011so I would insert code in libged like
12:23.50abhi2011int
12:23.51abhi2011ged_runphysics(struct ged *gedp, int argc, const char *argv[])
12:24.51abhi2011so i guess i would need to migrate the c code to the wrapper c file inside libged
12:25.29abhi2011it would not be possible for mged to call my precompiled program and direct its output to its own output in the mged window ?
12:26.51abhi2011and also provide it input through the argc, argv[] arguments that is generally used to receive command line parameters by c programs ?
12:29.30abhi2011hmm I guess not, such a thing would need to be done by the wrapper function if at all required
13:21.05*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
13:53.47brlcadkunigami_: ah, that makes a lot more sense!
13:55.27brlcadlooks like there's a curious bias, though -- I'd expect surface reflectivity to be fairly constant for the flat surfaces
13:56.10brlcadlooks more like it's showing the relative amount of energy reflected
13:57.58brlcadabhi2011: you could call a preompiled program and direct output to the mged window (several mged commands do exactly that) ... it's just bad design
13:58.20brlcadand for a physics engine integration, you really don't want unnecessary overhead
13:58.53brlcadneeds to be tight and fast so you could call it 20 times a second without delay
14:52.44*** join/#brlcad ibot (~ibot@rikers.org)
14:52.44*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
15:14.06abhi2011right i ll insert it as a command in mged
15:14.51abhi2011right now I am checking with a checked out copy of brlcad, whether i can compile and install bullet with it and start the physics through a command
15:15.11abhi2011so bullet has it own sources of course
15:15.31abhi2011where would you generally place the sources for an external library, in the src tree i mean
17:35.02``Eriksrc/other/ usually... but until it's end user ready, it might be better to say "hey, developers, you need bullet installed to use it"
18:37.01abhi2011right ok
18:37.10abhi2011so i have got bullet installed and running now
18:37.39abhi2011will proceed to write add it to the runphysics command
18:37.42abhi2011but before that
18:38.11abhi2011is there any command or app wrapper that access the list of objects  in mged
18:38.17abhi2011i want to se how its done
18:38.50abhi2011because say the user has drawn a sphere, then I would need its dimensions to insert it in the physics world and run a simulation
18:49.52abhi2011hmm...I am using the autotools build, I have included a new Bullet header now to the new command I had added to mged earlier (by modifying tire.c in src/libged)
18:50.52abhi2011the new header is #include <btBulletDynamicsCommon.h> , and its already been placed in /usr/local/include/bullet during Bullet installation
18:51.05abhi2011but apparently bullet does not look here for headers
18:51.19abhi2011have to modify the build logic to make sure it does
18:55.33abhi2011any idea where exactly can add this so it appears as a -I/usr/local/include/bullet compiler option during the build
19:03.20CIA-62BRL-CAD: 03starseeker * r45732 10/brlcad/trunk/CMakeLists.txt: Provide an option to allow RPMS to have a version-specific unique name, to make it simpler to allow for installing multiple versions of BRL-CAD on one system.
20:11.58*** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242)
21:46.12*** join/#brlcad DarkCalff (DC@173.231.40.98)
22:17.43bhinesleyyay, clean build time went from 37min -> 16min when I switched out my 7200RPM drive for an SSD
22:49.44*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
22:51.24abhi2011hi
22:51.35abhi2011I have a question regarding adding new headers
IRC log for #brlcad on 20110730

IRC log for #brlcad on 20110730

00:09.02CIA-62BRL-CAD: 03bhinesley * r45733 10/brlcad/trunk/src/libged/edit.c: Fixed crash due to use of uninitialized pointers; command union wasn't being initialized early enough.
01:57.36starseekermakes a note to investigate CMake's FeatureSummary.cmake
01:58.13starseekerrather an interesting survey here - someone went through KDE's cmake logic, covers a lot of interesting points:  http://community.kde.org/index.php?title=KDE_Core/Platform_11/Buildsystem/FindFilesSurvey
02:16.07*** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br)
02:17.06*** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net)
02:17.06*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
03:04.34*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
06:38.02CIA-62BRL-CAD: 03bhinesley * r45734 10/brlcad/trunk/src/libged/edit.c:
06:38.03CIA-62BRL-CAD: Finished the edit_translate_add_cl_args() function (previously *_add_args()), so
06:38.03CIA-62BRL-CAD: the logic of unique cmd-line args for that cmd are validated (needed 1 done to
06:38.03CIA-62BRL-CAD: proceed with edit()). Added flagging of common options to ged_edt(); now, only
06:38.03CIA-62BRL-CAD: cmd-specific options are recorded as chars. Since bug fix in r45733, I was able
06:38.03CIA-62BRL-CAD: to start enabling/testing '.' batch operator(WIP). Also, made an alias of '--'.
06:38.04CIA-62BRL-CAD: Trimmed long lines/comments. Removed dead code.
07:07.25*** join/#brlcad Stattrav (~Stattrav@117.213.188.221)
07:07.25*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:14.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:37.34*** join/#brlcad Stattrav_ (~Stattrav@117.192.139.9)
08:59.23CIA-62BRL-CAD: 03bhinesley * r45735 10/brlcad/trunk/src/libged/edit.c: (log message trimmed)
08:59.24CIA-62BRL-CAD: Due to some previous changes, an edit_arg was set to point at to something
08:59.24CIA-62BRL-CAD: before being 'initialized' to NULL, which was causing crashes later on. Also,
08:59.24CIA-62BRL-CAD: the natural origin option was still being saved as a character, and the target
08:59.24CIA-62BRL-CAD: object flag was not being set. Enabled support for multiple target object
08:59.24CIA-62BRL-CAD: arguments. Added helper function to free last arg in a list, broke common
08:59.25CIA-62BRL-CAD: functionality out to reduce redundancy. edit_translate_add_cl_args() is
09:40.37*** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242)
10:17.57abhi2011hi
10:19.31abhi2011I am trying to add a new header, for an external library
10:20.59abhi2011the header is located in /usr/local/include/bullet and I need to add this to the brlcad include paths. But I am not very sure where exactly I need to add it (I am using autotools build)
10:21.58abhi2011i think it should be the pkgincludedir = $(includedir)/brlcad variable
17:02.06*** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242)
17:54.55*** join/#brlcad CalinPaulAlexand (~Calin@109.99.20.242)
18:05.43*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
18:15.48*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
23:42.19*** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net)
IRC log for #brlcad on 20110731

IRC log for #brlcad on 20110731

06:01.21``Erikhm
09:55.10abhi2011ok figured out the build system, seems like i have to add all include directories to the configure script with checks
10:54.11abhi2011hi
10:54.46abhi2011I have inserted some headers from the bullet library into brlcad and I have modified the build logic to look in the include library
10:55.19abhi2011however the compile stops when it sees the 'class' c++ keyword  in one of the bullet headers
10:55.53abhi2011i think perhaps libged is not being compiled with some c++ compiler flag being appropriately set
11:08.05abhi2011http://bin.cakephp.org/view/1255993858
13:05.08abhi2011Generally successful compiles with Bullet go as follows : g++ -I/usr/local/include/bullet main.cpp -L/usr/local/lib -lBulletDynamics -lBulletCollision -lLinearMath
13:20.26brlcadabhi2011: you can't include a c++ header into a .c file
13:20.58brlcadyou'll have to layer the interface so that the c++ is encapsulated
13:21.48brlcadone way would be to have the src/libged/yourfile.c call functions from a src/libged/implfile.cpp (which includes the bullet header)
13:28.04abhi2011right
13:28.30abhi2011and the libraries need to be added to the configure script as well ?
14:01.51``Erikwhen the symbols are needed, they will need to be linked against the library or binary, yes... (might be better to use cmake instead of automake at this point)
14:12.39CIA-62BRL-CAD: 03kunigami * r45736 10/brlcad/trunk/src/liboptical/liboslrend.cpp: discovered how to get the object color from the closures. the next step is how to make the closure tell me to perform reflection
14:37.59CIA-62BRL-CAD: 03brlcad * r45737 10/brlcad/trunk/CMakeLists.txt: CAD_VERSION was only needed to bridge an m4 variable to a shell variable, cmake can just set BRLCAD_VERSION. on that note, use it where triplets are called for and keeping with our naming guidelines.
15:21.55abhi2011right, thanks brlcad and Erik
15:22.28abhi2011yah I would use cmake as soon as the issues with gcc 4.6.0 are resolved
16:56.48brlcadabhi2011: most if not all of the issues should be resolved now
16:56.56brlcadas of a couple days ago
16:58.03abhi2011cool, i will give it a try :)
17:33.01*** join/#brlcad Stattrav (~Stattrav@117.192.137.213)
17:33.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:38.29*** join/#brlcad Stattrav_ (~Stattrav@117.192.139.18)
17:40.09*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:32.53brlcadstarseeker: ``Erik: ping
22:04.58brlcad~seen tharis20
22:05.08ibottharis20 <~tharis@2.83.244.20> was last seen on IRC in channel #brlcad, 4d 21h 27m 46s ago, saying: 'oh man, I don't know how I'm going to wake up early tomorrow...'.
22:17.11*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
22:29.39CIA-62BRL-CAD: 03brlcad * r45738 10/brlcad/trunk/TODO: document initial thoughts on a 'simulate' command syntax
22:55.25CIA-62BRL-CAD: 03brlcad * r45739 10/brlcad/trunk/TODO: options for applying or not applying standard gravity in a simplified form (-g being default)
IRC log for #brlcad on 20110801

IRC log for #brlcad on 20110801

00:38.03*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
01:48.10*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:02.49*** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net)
02:23.20CIA-62BRL-CAD: 03kunigami * r45740 10/brlcad/trunk/src/rt/do.c: added a experimental mode to call do_run several times. by now each run is independent, but my next step is to sum the colors in scanline array instead of just setting them.
07:12.08*** join/#brlcad merzo (~merzo@193.254.217.44)
09:42.34*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
10:06.41*** join/#brlcad kunigami (~kunigami@201.53.206.27)
10:29.27*** join/#brlcad Stattrav (~Stattrav@117.192.147.9)
10:29.27*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:49.30*** join/#brlcad merzo (~merzo@193.254.217.44)
11:41.36*** join/#brlcad Stattrav (~Stattrav@117.202.26.38)
11:41.36*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:50.04*** join/#brlcad Elrohir (~kvirc@p5B14B46A.dip.t-dialin.net)
11:58.20*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:35.09*** join/#brlcad Stattrav_ (~Stattrav@117.192.159.229)
12:52.02*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:53.42*** join/#brlcad Stattrav (~Stattrav@117.202.31.56)
12:53.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
13:03.53*** join/#brlcad Stattrav_ (~Stattrav@117.192.145.237)
13:19.26*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:25.52CIA-62BRL-CAD: 03r_weiss * r45741 10/brlcad/trunk/src/libged/edit.c: Updated file 'edit.c' within the libged library. Fixed some compile warnings/errors.
14:26.30*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
14:27.26*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
14:48.30*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
14:49.30brlcadyawns
15:11.00d_rossberglast change in libged/edit.c (r45741): shouldn't there be a bu_free()? or #define the array sizes?
16:49.33brlcadbhinesley: d_rossberg's question is directed towards you ;)
16:51.46bhinesleybrlcad: oh okay. I was just looking at it and trying to figure out why those changes were made
16:52.15*** join/#brlcad kunigami (~kunigami@201.53.206.27)
16:52.25bhinesleybut yes, d_rossberg, it needs to be freed at the least
16:55.37bhinesleyI don't understand why "struct edit_arg *arg_heads[len];" was changed to "struct edit_arg **arg_heads;"
16:56.06bhinesleyI mean, why coudn't it be automatic
17:05.23brlcadhe's not here right now
17:06.01bhinesleyah
17:06.06brlcadbhinesley: c90 prohibits dynamic array sizes based on runtime variable values
17:06.22brlcadc++ allows it
17:07.07brlcadc99 might even allow it, but it's more portable to allocate your size as needed if the size can't be known at compile-time
17:07.37bhinesleyoh okay, so I can probably just use a #define, since I do know the size at compile-time
17:08.16brlcadnods
17:08.30*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
17:19.23*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
17:37.39CIA-62BRL-CAD: 03bhinesley * r45742 10/brlcad/trunk/src/libged/edit.c:
17:37.39CIA-62BRL-CAD: Compiler warnings because of dynamically sized arrays based on runtime variable
17:37.39CIA-62BRL-CAD: were resolved by allocating memory in r45741 (which was not subsequently being
17:37.39CIA-62BRL-CAD: freed). Since these sizes are known at compile time, we can instead size the
17:37.39CIA-62BRL-CAD: arrays using preprocessor macros. Also resolved, were 3 warnings about printf
17:37.40CIA-62BRL-CAD: format specifiers; the pointers needed to be dereferenced.
17:40.10*** join/#brlcad Stattrav (~Stattrav@117.192.134.200)
17:40.10*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:51.05*** join/#brlcad Stattrav (~Stattrav@117.192.134.200)
17:51.05*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:55.49*** join/#brlcad kunigami (~kunigami@201.53.206.27)
18:00.32*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:10.14brlcadcongratulations abhi2011
18:10.31abhi2011Thanks brlcad
18:10.46abhi2011didnt expect it :P
18:11.00brlcadso this will be pretty exciting, can't wait to see some objects responding to gravity :)
18:11.29abhi2011hehe yes :)
18:11.38brlcadit's going to be a lot of work, but I think you'll manage if you work hard at it and put a lot of time into figuring things out
18:11.41abhi2011by the way about yesterday's code
18:12.00abhi2011so the gedp structure was something I could not get rid of
18:12.06brlcadso that's pretty exemplary, yesterday's code exercise
18:12.25abhi2011ok
18:12.27brlcadshouldn't really take more than an hour, and you got stuck :)
18:12.40abhi2011ya i wasted 45 mins on the linking issue :P
18:12.47abhi2011coding took much less time
18:12.56brlcadyet coding is incomplete too :)
18:13.03abhi2011hehe :P
18:13.19brlcadso you really do need to figure out how to get that to work
18:13.21abhi2011yah the gedp structure was something i COULD NOT GET RID OF
18:13.25abhi2011oops no caps
18:13.27brlcadit's actually directly related to your task
18:13.29abhi2011sorry
18:13.43abhi2011yes
18:14.10abhi2011so a question
18:14.17brlcadyou'll need to read that code over and over until you understand what it's doing and figure out how the bounding box is actually calculated
18:14.25brlcadwithout libged, naturally :)
18:14.49abhi2011ah ok, I was thinking there is a function in libged that directly takes an object extracted from the .g file
18:14.50brlcador with it -- frankly doesn't matter, it's just not necessary
18:15.04abhi2011yes exactly, no point rebuilding the wheel
18:15.27brlcadthere is a function in libged that directly takes an object extracted from the .g file
18:15.32abhi2011right
18:15.37abhi2011was looking for that :)
18:15.50brlcadyou need to read the code
18:16.02brlcadbecause you already sort of found it, or at least found the direct pointers to it
18:16.27brlcadif it's not obvious, you should review that code line by line until you understand it ;)
18:16.33abhi2011yes i will look through the functions defined in libged and make that program work
18:17.27abhi2011ok be right back in few mins
18:46.12CIA-62BRL-CAD: 03bhinesley * r45743 10/brlcad/trunk/src/libged/edit.c: fixed off by one error in a function that frees linked list of args; was causing crashes in some cases
18:58.56*** join/#brlcad Stattrav (~Stattrav@117.192.134.200)
18:58.56*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:10.37abhi2011back
20:02.53*** join/#brlcad Stattrav (~Stattrav@117.192.134.200)
20:02.53*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:09.34CIA-62BRL-CAD: 03bhinesley * r45744 10/brlcad/trunk/src/libged/edit.c: (log message trimmed)
20:09.34CIA-62BRL-CAD: One of the translate cmd's functions was not detecting missing "TO" args, which
20:09.34CIA-62BRL-CAD: ged_edit() intentionally doesn't detect if the -k option isn't given. A function
20:09.34CIA-62BRL-CAD: to free edit_cmd obj's was only partially working since args were changed from
20:09.34CIA-62BRL-CAD: being automatic to malloc'd. Fixed several related/unrelated problems with
20:09.35CIA-62BRL-CAD: regard to freeing and allocating memory. Added a helper function to only free
20:09.36CIA-62BRL-CAD: args if they are unused, which saved some checks/vars later on. There were some
20:19.24*** join/#brlcad kunigami (~kunigami@201.53.206.27)
20:22.35CIA-62BRL-CAD: 03r_weiss * r45745 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
20:22.35CIA-62BRL-CAD: Updated the prototype version of function 'cut_unimonotone' within file
20:22.35CIA-62BRL-CAD: 'nmg_tri.c'. This change adds a check for null edgeuse. This prototype function
20:22.35CIA-62BRL-CAD: supports the prototype version of 'nmg_triangulate_fu'. These changes are
20:22.35CIA-62BRL-CAD: disabled by default. These changes are a work in progress.
20:29.18CIA-62BRL-CAD: 03r_weiss * r45746 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c:
20:29.18CIA-62BRL-CAD: Updated functions 'nmg_class_pt_e', 'nmg_class_pt_l', 'class_vu_vs_s',
20:29.18CIA-62BRL-CAD: 'nmg_class_pt_s', 'class_eu_vs_s' and 'class_lu_vs_s' within file 'nmg_class.c'.
20:29.18CIA-62BRL-CAD: Most of the updates were changes to support the prototype version of function
20:29.18CIA-62BRL-CAD: 'nmg_triangulate_fu'. The remainer of the changes were code cleanup. The logic
20:29.18CIA-62BRL-CAD: changes are disabled by default and are a work in progress. These changes are
20:29.19CIA-62BRL-CAD: related to classification of nmg objects during boolean operations.
20:29.28CIA-62BRL-CAD: 03starseeker * r45747 10/brlcad/branches/STABLE/src/ (libged/erase.c libged/mater.c librt/primitives/ars/ars.c): Add a few bugfix patches to STABLE.
20:38.03CIA-62BRL-CAD: 03r_weiss * r45748 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: (log message trimmed)
20:38.04CIA-62BRL-CAD: Updated functions 'vertex_neighborhood', 'ray_hit_vertex', 'isect_ray_faceuse',
20:38.04CIA-62BRL-CAD: 'guess_class_from_hitlist_max', 'guess_class_from_hitlist_min' and
20:38.04CIA-62BRL-CAD: 'nmg_class_ray_vs_shell' within file 'nmg_rt_isect.c'. Most of the changes
20:38.04CIA-62BRL-CAD: support the prototype version of the function 'nmg_triangulate_fu'. The
20:38.04CIA-62BRL-CAD: remaining changes are code cleanup. The logic changes are disabled by default
20:38.05CIA-62BRL-CAD: and are a work in progress. These changes are related to classification of nmg
20:45.26CIA-62BRL-CAD: 03r_weiss * r45749 10/brlcad/trunk/src/librt/primitives/nmg/nmg_pt_fu.c: Updated function 'nmg_class_pt_eu' within file 'nmg_pt_fu.c'. Changed a floating point compare to 0.0 to using SMALL_FASTF.
22:13.06CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r3039 10/wiki/User:Kunigami/GSoc2011/Reports: added log for past week
22:13.50CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r3040 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ corrected formatting error
22:14.09CIA-62BRL-CAD: 03bhinesley * r45750 10/brlcad/trunk/src/libged/edit.c: Improved detection/alerts of translate command syntax-error.
22:15.19bhinesleykunigami: bah, you just reminded me that I've been forgetting that again :-/
22:15.31kunigamibhinesley: :)
22:24.50abhi2011brlcad I found the reason for the linking errors yesterday
22:25.38abhi2011I was using fedora from virtual box and I had placed the main.c file in a mounted partition
22:25.48abhi2011the partition is a windows partition
22:26.32abhi2011once I copied the file into the /home its having no problem finding librt
22:32.11abhi2011hmm no thats not the reason
22:32.34abhi2011well anyway am using a native installation now so it should be fine
22:45.54brlcadbhinesley: kunigami: you guys have been fantastic at updating your reports (completely unprompted) .. seriously I think you're both a couple of the best I've seen at announcing your activities
22:45.58brlcadkudos
22:46.49kunigamibrlcad: thanks!
22:47.07bhinesleycool... I worry about these things ;-)
23:15.25``Erik(btw, great job on passing the midpoint, too)
23:15.52bhinesleythank you
23:17.58*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
23:18.03CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3041 10/wiki/User:Abhijit: /* Development timeline */
23:52.30*** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net)
IRC log for #brlcad on 20110802

IRC log for #brlcad on 20110802

01:50.14CIA-62BRL-CAD: 03kunigami * r45751 10/brlcad/trunk/src/rt/ (do.c ext.h opt.c view.c):
01:50.14CIA-62BRL-CAD: added simple support for the multi-sample framebuffer. I'm currently using the
01:50.14CIA-62BRL-CAD: scanline array to hold the partial averages, but this is not good since it is a
01:50.14CIA-62BRL-CAD: char array and many values will be truncated when I compute the next average. I
01:50.14CIA-62BRL-CAD: think we must use a dedicated buffer to hold these averages. To test this mode,
01:50.15CIA-62BRL-CAD: compile with -DEXPERIMENTAL_MODE
01:51.13CIA-62BRL-CAD: 03kunigami * r45752 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp sh_osl.cpp): the experimental mode should be used with path-tracing, turning off ray-tracing on sh_osl...
03:43.59brlcadkunigami: what do you mean by "turning off ray-tracing on sh_osl"?
03:44.48brlcadah, you mean your single-ray test?
03:46.28brlcadmm, looks like it
03:47.29brlcadso question about that for loop at the end of sh_osl.cpp .. it looks like it's basically calling rt_shootray() over and over again unless it's a refraction ray
03:52.12brlcadah, but only if reflection is being performed, hmm
03:57.49*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
04:37.24CIA-62BRL-CAD: 03bhinesley * r45753 10/brlcad/trunk/src/libged/edit.c:
04:37.24CIA-62BRL-CAD: edit() will now "expand" batch operation args, by performing a deep copy of
04:37.24CIA-62BRL-CAD: every target obj's edit_arg struct, consolidating option flags between the two
04:37.24CIA-62BRL-CAD: as necessary. Added detection of keypoints missing their matching 'TO' arg,
04:37.24CIA-62BRL-CAD: since every cmd should have that behavior. Replaced edit_arg_free_if_empty()
04:37.25CIA-62BRL-CAD: with edit_arg_is_empty; a bit more versatile that way.
05:07.03Stattravcan i compile the source on my computer by suppressing the "treating warnings as errors" notification ?
05:07.15Stattravfor a dev machine for brlcad ?
06:35.16*** join/#brlcad Stattrav (~Stattrav@117.213.184.103)
06:35.16*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:40.15*** join/#brlcad Stattrav_ (~Stattrav@117.202.27.11)
06:52.32*** join/#brlcad Stattrav (~Stattrav@117.192.131.187)
06:52.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
07:09.33bhinesleyStattrav, if you're using autotools, use "--disable-strict". If you're using cmake, you can use -DBRLCAD-ENABLE_STRICT=OFF
07:10.41Stattravbhinesley: aah compiled by removing -Werror :) thanks. i shall make a note of it for the next time
07:11.17bhinesleyno problem
11:27.57*** join/#brlcad ibot (~ibot@rikers.org)
11:27.57*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
11:38.30*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
11:38.43*** join/#brlcad Stattrav (~Stattrav@117.192.129.74)
11:38.43*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
11:57.13CIA-62BRL-CAD: 03starseeker * r45754 10/brlcad/branches/STABLE/src/libfft/CMakeLists.txt: Add the libfft CMakeLists.txt tweak to STABLE.
12:18.58brlcadthere were probably a hundred places that needed M_LIBRARY
12:46.25starseekerbrlcad: that one specifically fell out of a particular compile
12:48.42starseekerit was when I tossed in the -Wl,--no-undefined line to CMAKE_SHARED_LINKER_FLAGS - that one, and only that one, failed (IIRC)
13:28.02CIA-62BRL-CAD: 03starseeker * r45755 10/brlcad/trunk/CMakeLists.txt: CMake doesn't currently work with umask settings, so there's no point in setting it ahead of time.
14:06.34*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
14:34.31*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
14:46.10abhi2011Hi, while using the cmake build is there a flag to stop treating warnings as errors
14:46.36abhi2011just as with the autotools build there is ./configure --enable-all --disable-strict --with-ogl
14:55.18abhi2011ah its just a simple flag :P :  cmake ../brlcad -DBRLCAD-ENABLE_OPTIMIZED=ON -DBRLCAD-ENABLE_STRICT=OFF
15:01.22brlcadstarseeker: ah, the issue is that for some platforms, no-undefined is the system default for ld
15:01.35brlcadthere were two users in here that run into that problem (with fedora, I believe)
15:23.42*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
15:32.19CIA-62BRL-CAD: 03brlcad * r45756 10/brlcad/trunk/src/rt/view.c: quell variable type warnings, stub in code for displaying progress during raytrace ... which unfortunately kills render performance.
15:33.33CIA-62BRL-CAD: 03brlcad * r45757 10/brlcad/trunk/src/rt/do.c: more type quellage (someone needs to compile strict) .. use bu_log() instead of fprintf(). only bu_log() supports %z for size_t types (with c90).
17:04.47*** join/#brlcad Stattrav (~Stattrav@117.192.146.245)
17:04.47*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:38.07abhi2011brlcad compiled and ran successfully with cmake under opensuse 11.4, though the gcc is old (gcc 4.5.1)
17:38.32brlcadthat's not really an old gcc
17:38.44brlcad4.0 is old, 4.2 is a little old
17:41.16brlcaddang .. something still doesn't seem right with cmake debug builds .. no debugging symbols in the binary
17:41.28brlcadCMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING=
17:41.45brlcadthat doesn't look right, need -g during compilation and linking
17:41.55brlcadCMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING=
17:41.57brlcadtoo
17:48.26``Erikheh, rhel5 ships with 4.1.2, fbsd8 is 4.2.2, osX xcode3 is 4.2.1 O.o 4.5 sounds pretty new to me :D
17:49.12abhi2011yes true, i meant since 4.6.0 is out now :P
17:49.27abhi2011the CMAKE_MODULE_LINKER_FLAGS_DEBUG is not one of the cmake flags is it ?
17:49.44abhi2011i dont see it in CMakeLists.txt
17:58.02brlcadno worries, that was more a directed inquiry towards starseeker
17:59.31starseekerbrlcad: I haven't been doing much in the way of setting linker flags thus far
18:00.07starseekerso yeah, there are probably some we'll need to add
18:00.09brlcadso you've not been working in gdb very much I take it then? :)
18:00.28starseekernot too much lately, but I have done so before...
18:01.09starseekernever noticed anything amiss, which probably means I wasn't doing something right...
18:01.31brlcadI think that's the crux of the issue, debug/cflags used for compile aren't being used during linking
18:02.06starseekerum... which issue?
18:02.46starseekernow remembers why he loathed the tcl build system so much... gah
18:02.52brlcadI have binaries getting linked without debug symbols
18:03.09brlcadand sure enough, if I make VERBOSE=1, there is no -g on the linker line
18:04.24brlcad/vld/other/morrison/Applications/bin/gcc   -pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99 -m64  -pedantic -Wall -Wextra -Wundef -Wfloat-equal -Wshadow -Winline -Wno-long-long  -Werror   -m64 CMakeFiles/myapp.dir/myapp.c.o  -o ../../bin/myapp -rdynamic ../../lib/libwdb.so.19.0.1 -lm ../../lib/librt.so.19.0.1 ../../lib/libbn.so.19.0.1 ../../lib/libbu.so.19.0.1 -lpthread -lpng ../../lib/libsysv.so.19.0.1 ../../lib/libtcl.so.8.5.9 -lm -ldl ../../lib/
18:04.50``Erikhuh, mysql went cmake
18:04.52brlcadso it's passing a whole variety of flags, but not -g
18:05.19starseekerk - that's probably a missing line in CMake/CompilerFlags.cmake
18:08.17CIA-62BRL-CAD: 03starseeker * r45758 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Add the debug flag to the shared library linker line - may need to fix more than this, but it's a start
18:10.03brlcadwhat is CMAKE_SHARED_LINKER_FLAGS_${CFG_TYPE} ?
18:10.10brlcadother flags don't set that...
18:10.51CIA-62BRL-CAD: 03starseeker * r45759 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: key off of the debug option, not build type, since we might be turning on debug flags even in a release build.
18:11.13CIA-62BRL-CAD: 03brlcad * r45760 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: setting cflags/cxxflags is insufficient (or cmake is wrong to not apply cflags during linking), the linker needs to have debug flags for executables too
18:11.28starseekerbrlcad: that's CMAKE_SHARED_LINKER_FLAGS_DEBUG for a debug build, CMAKE_SHARED_LINKER_FLAGS_RELEASE build
18:12.09brlcadbut then what purpose does CMAKE_SHARED_LINKER_FLAGS serve?
18:12.28starseekerif you have no build type at all set, it falls back on that one (if I understand correctly)
18:13.03starseekerI'm currently making people work to NOT have a build type set, but that's relatively recent
18:13.04brlcaderr, I thought I saw a message during cmake saying "build profile not set, using Debug" ?
18:13.47starseekeryeah - that's me turning it on if it's not set - you can force it to stay off by specifying NONE (I think) but the assumption is you want the build type set
18:15.15brlcadcmake doesn't use LD_FLAGS?
18:15.41starseekerum - you mean if you specify it on the command line?  not sure
18:15.49brlcadno, I mean internally
18:16.04brlcadC_FLAGS and CXX_FLAGS variables get set
18:16.07starseekeroh - no, I think it uses the SHARED_LINKER_FLAGS stuff
18:16.20brlcadbut curiously no LD_FLAGS, which would be the pairing
18:16.37brlcadis C_FLAGS a var you came up with or cmake?
18:17.07starseekerI believe that one is CMake
18:17.25starseekerhttp://cmake.org/Wiki/CMake_Useful_Variables
18:18.20brlcadCFLAGS/CXXFLAGS/CPPFLAGS/LDFLAGS are the historic var names
18:18.51brlcader, they list CMAKE_C_FLAGS .. that's not the same as C_FLAGS
18:19.06starseekeroh, yeah - sorry
18:19.31starseekerI've found that list to be very useful, seems to be fairly accurate
18:20.55brlcadso you set C_FLAGS, and presumably down the line, CMAKE_C_FLAGS is set to your C_FLAGS
18:22.10starseekerright
18:25.24starseekerhmm... actually, I can probably clean up that logic some
18:26.52CIA-62BRL-CAD: 03brlcad * r45761 10/brlcad/trunk/src/libbu/getopt.c: style cleanup
18:27.56CIA-62BRL-CAD: 03brlcad * r45762 10/brlcad/trunk/src/libbu/getopt.c: no place for you
18:28.11starseekerI was using a lot of my own variables in the earlier days, before I got a handle on what variables were used for what
18:36.50starseekerbrlcad: ah, right - I remember now.  C_FLAGS is actually a variable holding the name of the correct CMAKE_C_FLAGS_* variable for the build type
18:45.38brlcadhm, neat trick, but sounds potentially problematic
18:46.11brlcadsince for some of the output targets, cmake generates all build profiles into the output (e.g., studio or xcode)
18:50.51starseekerdoes it?  I was under the impression you had to specify Debug or Release at CMake time, but I could be wrong
18:51.26brlcadpossibly, but those build systems do support multiple configurations
18:52.10brlcadMSVC pretty much came up with the concept of separate Debug and Release build configurations (named as such)
18:53.22starseekernods - the question though is whether CMake actually generates both configurations in valid form from a single CMake run
18:53.27brlcadyep
18:58.19brlcadthis makes it sound like it does:  http://www.cmake.org/pipermail/cmake/2010-January/034365.html
19:05.53starseekerhmm... mutter...
19:13.06*** join/#brlcad Stattrav (~Stattrav@117.192.146.245)
19:13.06*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:15.07CIA-62BRL-CAD: 03starseeker * r45763 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake): More refinement of the compiler flags logic. May have to go one step further for MSVC project files...
19:22.34*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
19:51.16CIA-62BRL-CAD: 03starseeker * r45764 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Have a go at setting compiler flags for all configurations.
19:51.28starseekerbrlcad: that might do it
19:52.39CIA-62BRL-CAD: 03starseeker * r45765 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: whoops, typo
20:05.16CIA-62BRL-CAD: 03starseeker * r45766 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Some cleanup and typo fixes, make the ADD_NEW_FLAG macro a bit more flexible
20:07.25starseekerhuh, cool:  http://chiselapp.com/user/andreas_kupries/repository/crimp/home
21:28.07*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
IRC log for #brlcad on 20110803

IRC log for #brlcad on 20110803

06:18.08*** join/#brlcad ibot (~ibot@rikers.org)
06:18.08*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
06:58.40*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
07:03.34*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
09:35.41d_rossbergstarseeker: the STRICT_FLAGS is a little bit disturbing to MSVC
09:54.36*** join/#brlcad Stattrav (~Stattrav@122.178.209.201)
09:54.42*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
10:12.24abhi2011ok thanks bhinesly and brlcad
10:41.07abhi2011bhinesley: db_lookup(dbip, argv[2], 1)  is correct then as db_lookup works on objects inside the database, and sph1.s is an object inside the sphere.g database
10:41.54abhi2011however it seems that ged_bb() treats the command line differently from what I expect
10:42.32abhi2011so I give the db name first and the object name 2nd  which is argv[1] and argv[2] respectively
10:43.35abhi2011but it treats argv[1] also as an object name in the currently open db, so I modified the code to pass argv+1 instead and argc =1, so that only 1 object name (sph1.s) gets passed
10:44.13abhi2011like this : if ( ged_bb(gedp, 1, argv+1) == GED_OK){....
10:45.26abhi2011ged_bb() still doesnt return GED_OK though, so I am checking if something else is going wrong
11:08.43*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:19.11abhi2011ok I got the bb now !
12:19.27abhi2011but it seems I cant print the bound by just printing the gedp result string
12:19.53abhi2011so if i try  printf("%s\n", gedp->ged_result_str);
12:20.09abhi2011then i get �;3�     !!
12:20.44abhi2011I ll check if its actually a char*
12:37.46*** join/#brlcad kunigami (~kunigami@201.53.206.27)
12:49.35*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:08.57abhi2011ah ok its a variable length string to save memory
13:13.12abhi2011YES!!!...finally got the bb printed :P
13:13.20abhi2011printf("%s\n", ( ((gedp->ged_result_str)->vls_str) + ((gedp->ged_result_str)->vls_offset) ) );
13:13.38abhi2011output is same as in archer for a unit sphere centred at the origin
13:15.39abhi2011perhaps not the most efficient but works : http://bin.cakephp.org/view/1085618267
13:46.31starseekerd_rossberg: "disturbing?"
13:52.21d_rossbergMSVC does not know how to handle a "STRICT_FLAGS" compiler switch, so it tries to open a file with this name
13:53.24d_rossbergprobable a problem in cmake: not STRICT_FLAGS is meant but its value
13:55.44*** join/#brlcad DarkCalff (DC@173.231.40.98)
14:56.59*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
15:12.18brlcadabhi2011: so this is going to be a learning experience, but good work figuring out how to print the bb
15:13.21brlcadyour end result uses the libged API, which is a very high-level interface
15:13.32brlcada few "mistakes", one being what you did with ged_result_str
15:13.57brlcadit's a struct bu_vls ... and accessing  the internal vls_str and vls_offset is a no-no
15:14.16brlcadthere are printing routines for that
15:14.32brlcadyou'd either use bu_log() instead of printf() where you can use %V to print them
15:15.11brlcador you'd call printf() with bu_vls_addr(dedp->ged_result_str) to get the underlying char *
15:16.22brlcadabhi2011: so then the next useful step is to compute the bounding box without calling ged_open() or ged_bb(), using the lower level librt API that libged is using
15:24.05CIA-62BRL-CAD: 03kunigami * r45767 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h sh_osl.cpp): changed the field reflection by ray_type so that it can also represent transmission rays. I hope this way the logic gets clearer
15:40.28abhi2011brlcad : right will try that
15:43.44brlcadso, db_open(), and other db_*() and rt_*() api calls, no ged_*() functions
15:44.03brlcadthat will be what your physics command will need to do
15:44.10abhi2011yes, that was my other option if libged were not to work, but chose the easy way out first :P
15:44.23abhi2011yes right
15:44.47brlcadnothing wrong with that approach
15:45.08brlcadand in most other contexts, calling libged would be fine too
15:45.26abhi2011umm so why not in this case too
15:45.33brlcadif anything, you can read the source for ged_bb() and follow the functions to see how it computes the bb
15:45.42abhi2011yes i did that
15:45.52abhi2011i know how to use the librt functions now
15:46.01brlcadso then it should be very clear and trivial to convert ;)
15:46.09abhi2011yep :)
15:46.25brlcadthis case is different because you're also implementing a libged function
15:46.49abhi2011so we cannot use other libged functions ?
15:47.04abhi2011that are exported...just curious
15:47.04brlcadged functions shouldn't be built on other ged functions when the common functionality has already been refactored into librt
15:47.10brlcadit just adds layered complexity
15:47.11abhi2011ah ok
15:47.22abhi2011and will introduce delays
15:47.23brlcadas well as slows things down
15:47.25brlcadnods
15:47.27abhi2011yep
15:47.55brlcadthe slow down in negligible for interactive use, but is significant for programmatic use
15:48.14abhi2011yah...we want real time motion..yay !
15:48.18abhi2011:)
15:49.16abhi2011by the way I was wondering, brl cad was used before my usmil right
15:49.35abhi2011so they moved on to other software and open sourced this ?
15:50.40abhi2011I was looking for some of the full forms of the primitives like tgc in google and I came across this : http://www.digitaldogma.org/archive/MikeMuuss/papers/brlcad5.0/html/mged/tableofcontents2_1.html
16:16.49*** join/#brlcad survery (~thomas@dslb-178-007-120-202.pools.arcor-ip.net)
16:17.05*** part/#brlcad survery (~thomas@dslb-178-007-120-202.pools.arcor-ip.net)
16:21.16bhinesleyabhi2011: that makes sense. I was looking for calls directly to db_lookup in your pastbin; I didn't catch that. Glad you got it working.
16:24.39abhi2011bhinesley: yep, converting to use only rt now
17:22.49CIA-62BRL-CAD: 03starseeker * r45768 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Was getting too clever for my own good. If ADD_NEW_FLAG comes in empty, don't do anything - should avoid the error on Windows
17:28.03CIA-62BRL-CAD: 03r_weiss * r45769 10/brlcad/trunk/include/raytrace.h:
17:28.03CIA-62BRL-CAD: Added an entry into the 'raytrace.h' header for a new function 'nmg_keu_zl'
17:28.03CIA-62BRL-CAD: which removes all zero length edgeuse from an nmg shell. This function is
17:28.03CIA-62BRL-CAD: disabled by default and is a work in progress. This function supports the
17:28.03CIA-62BRL-CAD: prototype version of 'nmg_triangulate_fu'.
17:31.08CIA-62BRL-CAD: 03r_weiss * r45770 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mk.c:
17:31.08CIA-62BRL-CAD: Added a new function 'nmg_keu_zl' which removes all zero length edgeuse from an
17:31.08CIA-62BRL-CAD: nmg shell. This was added into file 'nmg_mk.c'. This function is disabled by
17:31.08CIA-62BRL-CAD: default and supports the prototype version of 'nmg_triangulate_fu'. This is a
17:31.08CIA-62BRL-CAD: work in progress.
17:42.59CIA-62BRL-CAD: 03r_weiss * r45771 10/brlcad/trunk/src/librt/primitives/tor/tor.c: (log message trimmed)
17:42.59CIA-62BRL-CAD: Updated function 'rt_tor_tess' within file 'src/librt/primitives/tor/tor.c' by
17:42.59CIA-62BRL-CAD: adding a call to function 'nmg_keu_zl' which removes all zero length edgeuse.
17:42.59CIA-62BRL-CAD: Under certain conditions the function 'rt_tor_tess' will create a tessellated
17:42.59CIA-62BRL-CAD: torus which contains zero length edgeuse which is invalid and causes a crash in
17:43.00CIA-62BRL-CAD: later functions. An example of a torus which causes a crash during 'facetize' is
17:43.00CIA-62BRL-CAD: object 'old.s82' within the 'm35.g' sample model. This change is disabled by
18:18.57CIA-62BRL-CAD: 03kunigami * r45772 10/brlcad/trunk/src/rt/view.c: added a dedicated buffer to keep partial sums on multi-sample modes
18:24.54CIA-62BRL-CAD: 03kunigami * r45773 10/brlcad/trunk/src/rt/view.c: had left behind a debug message
18:27.20``Erikmysql removed from osX.7, nice
19:04.33CIA-62BRL-CAD: 03brlcad * r45774 10/brlcad/trunk/include/vmath.h: add missing zero macros, HNEAR_ZERO(), VZERO(), V2ZERO(), & HZERO()
19:04.43CIA-62BRL-CAD: 03r_weiss * r45775 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: (log message trimmed)
19:04.43CIA-62BRL-CAD: Added new functions 'print_loopuse_tree', 'nmg_classify_pt_loop_new',
19:04.43CIA-62BRL-CAD: 'nmg_classify_lu_lu_new', 'insert_above', 'insert_node' and
19:04.43CIA-62BRL-CAD: 'nmg_build_loopuse_tree' to file 'nmg_tri.c'. These function are prototype
19:04.44CIA-62BRL-CAD: functions which support the prototype version of 'nmg_triangulate_fu'. Some of
19:04.44CIA-62BRL-CAD: these functions may have their names changed or moved to a more appropriate
19:04.45CIA-62BRL-CAD: location within the code. These functions are the beginning of code which
19:05.34*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:20.56brlcadkunigami: it might be beneficial in the long run to use a long or floating point accumulation buffer
19:21.31kunigamiyup I'm using long
19:21.47brlcadawesome, missed that ;)
19:24.41brlcadthat means we'll be able to accumulate about 16M passes before the buffer is "full" (at 32-bit) .. that's a lot of hypersampling ;)
19:25.59*** join/#brlcad piksi (piksi@pi-xi.net)
19:27.04kunigamiwhen adding inside sh_osl, I could have values greater than 1.0, but with averages bellow 1.0. Thus, it was not "clamped". now, if I have any component greater than 1.0, it will be clamped and the average will be near 0 if the other components are 0. I have a test Scenesthat relies on strong brightnes. It was rendered nicely before, but now it is too dark. Would be wrong if I avoid clamping the components of the sum, but only the sum itself?
19:38.58brlcadkunigami: if I understand you correctly (and I'm not 100% sure that I do), then yes.. you can use the buffer as an accumulation buffer and clamp/average/downsample at some later processing stage
19:42.24brlcadfor hypersampling, for example, instead of accumulating "value/#rays" for each hypersample ray (i.e. val/#rays * #rays => final_value), it would accumulate "value" as-is (resulting in "value * #rays" in the buffer), then divide by the #rays at the end or scale to 255 or whatever
19:45.46CIA-62BRL-CAD: 03brlcad * r45776 10/brlcad/trunk/BUGS: a torus with a zero sized inner diameter results in zero-length edges during tessellation. nmg_keu_zl() could remove them, but it implies there is a flaw in the rt_tor_tess() logic not accounting for the edge case.
19:46.43brlcadkunigami: did my response make sense about the two different options?
19:50.42kunigamibrlcad: yes, that makes sense. I'll do the same way as hypersampling, thanks
20:40.49*** join/#brlcad merzo (~merzo@59-47-132-95.pool.ukrtel.net)
21:26.36*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
21:46.33CIA-62BRL-CAD: 03kunigami * r45777 10/brlcad/trunk/src/rt/ (do.c view.c): changed the accumulator buffer to float so that it saves the raw components of ap.a_color before theyre clamped. We only expand and clamp it when moving the partial sums to scanline
22:01.47*** join/#brlcad Yoshi477 (~jan@d72-39-60-53.home1.cgocable.net)
22:14.43abhi2011so I am trying to get the bb now using librt only
22:14.52abhi2011here is the code so far : http://bin.cakephp.org/view/570066725
22:15.12abhi2011I run it as ./a.out dome.g sph2.s rcc2.s
22:15.34abhi2011the objects are present in the dome.g database file as I can see them in archer
22:15.58abhi2011yet : db_lookup(sph2.s) failed: sph2.s does not exist
22:16.07abhi2011so I am debugging with gdb now
22:16.53abhi2011and I saw that inside db_lookup there is a line that tries to hash the name 'sph2.s'   (when its being looked up)
22:17.56abhi2011line 230 : dp = dbip->dbi_Head[db_dirhash(name)];
22:18.38abhi2011the hash for 'sph2.s' is 747 which is why dbip->dbi_Head[db_dirhash(name)]; returns null and consequently the lookup fails
22:23.15abhi2011probably the hash value can be anything, but perhaps its out of range in this case of the array dbi_Head[]
22:31.29abhi2011perhaps its because the objects sph2.s and rcc2.s are leaves, that is they are not children of higher levels groups
23:01.48abhi2011probaly the directory is not built up already as in the rtexample.c
23:13.24abhi2011ok easier to use rtip = rt_dirbuild(argv[1], title, sizeof(title));
23:13.47abhi2011and rt_gettree(rtip, argv[2]) with bb calculated using rt_prep_parallel(rtip, 1);
23:24.19``Erik*reads he pastebin* yeah, you do need an rt_prep somewhere in there, that's where the bb gets set
23:25.28abhi2011well yes, but I did not reach that far in that code, the db_lookup() called from db_string_to_path() in line 50, barfed well before that !
23:25.40abhi2011I guess cause there was no directory built up
23:26.14abhi2011this command would normally get called from inside mged when rtip would have a valid directory setup containing the structure of the model
23:26.44abhi2011but for the command line program its probably not so, so I have to start by calling rt_dirbuild()
23:27.36``Erikhm, yeah (not too familiar with the very early stages of opening/parsing a .g, myself), I think you're right
23:28.23``Eriksome of the src/conv/ programs use prepared geometry and are quite a bit simpler than the src/rt stuff... might be worth poking around in there for examples
23:28.49CIA-62BRL-CAD: 03bhinesley * r45778 10/brlcad/trunk/src/libged/edit.c:
23:28.49CIA-62BRL-CAD: Started on functions that convert db_full_path objects to points (natural
23:28.49CIA-62BRL-CAD: origin/bounding box center); WIP. edit() was getting a bit difficult to read,
23:28.49CIA-62BRL-CAD: which has led to several bugs, so I broke out batch expansion code into
23:28.49CIA-62BRL-CAD: edit_arg_expand(). There are still some problems preventing this from working,
23:28.50CIA-62BRL-CAD: but I haven't commited in a while and need to. Several changes to struct
23:28.51CIA-62BRL-CAD: edit_arg helper functions; needed more versatility
23:29.07abhi2011ah ok, umm why the 'conv' are they converted from some other library or something ?
23:30.05``Erikconverting between formats
23:30.38bhinesleyabhi2011, the HACKING file tells you what the major directories are for
23:31.05``Erikg-shell-rect.c fires rays to solve new geometry
23:31.35``Erikum, also; the rtcmp toplevel project has an rt directory with a VERY minimal and simple example of how to get rt firing rays at geometry
23:33.09abhi2011ah yes right thanks Erik and bhinesley
23:33.13``Erikwhich is rt_dirbuild(); rt_gettree(); rt_prep_parallel();
23:34.45abhi2011the rtcmp sounds interesting,  will have a look
23:36.01``Erikit's minimal and hackish, was to compare performance/correctness between 3 raytracing engines
23:36.14``Eriknot "production" code :)
23:36.57abhi2011ok, yah I just need a quick intro to raytracing using brlcad
23:40.13``Erikhttp://brlcad.svn.sourceforge.net/viewvc/brlcad/rtcmp/trunk/rt/rt.c?revision=34030&view=markup
23:40.52``Erikthat's about as simple as it gets... the hit() function is a bit more than you might need, but the rest... :)
23:47.00abhi2011hmm I understand most of it except the hit function
23:47.22abhi2011seems its partitioning the 3d space around the point where the ray hit some geometry
23:47.46abhi2011and calculating the outward pointing normal at that point on its surface....wild guess
23:48.45``Erikyeah, rt_shootray() needs hit and miss callbacks set in the application structure and calls one of them depending on what happened
23:49.00``Erikthe hit function gets fed a boolean evaluated "partition list"
23:49.28``Erikmy hit() function there is solving normals and repacking the results into a different partition list format (for comparison)
23:50.00``Erikif a_onehit is set, it'll only fill the first partition, useful for visual raytracing
23:50.36abhi2011ok so these partitions represent cubiodal regions in 3d space ?
23:51.29abhi2011i am thinking in terms of partitioning of the 3d space into 8 different regions around a point
23:51.47abhi2011around the 3 axes
23:52.06``Erikno, they're segments along the ray where it intersects geometry
23:52.26abhi2011ah ok
23:52.41abhi2011so some segments will be inside the geomtry and some outside
23:53.06abhi2011which can be decided using the equation of a sphere for example if a sphere is the geometry
23:53.28``Erikit does boolean evaluation before generating the partition list (using the boolweave() function in rt), so that's actual solid geometry in those partitions
23:54.02abhi2011ok
23:54.36``Erikif you have a 1 radius sphere at the origin and subtract an arb8 that's across an origin plane and shoot perpendicular to that plane, you'll see a partition that says "I hit a sphere from 1,0,0 to 0,0,0"
23:54.47``Erikis that confusing enough? :D
23:56.02abhi2011no I am getting it slowly :P, but I am familiar with all the short forms of the primitves yet, so arb8 is a rectangle or a plane ?
23:56.19abhi2011*not familiar
23:56.19``Erikarb8 is a box
23:56.22abhi2011ok
23:57.04abhi2011right i get it
23:57.32abhi2011but wait we have subtracted an arb8
23:57.36``Erikhttp://brlcad.org/gallery/d/170-2/primitives.png
23:57.48abhi2011so there is a hollow region inside the sphere
23:57.56``Erikwell, a sphere cut in half
23:58.04abhi2011ah yes right
23:58.42abhi2011ah cool thats handy
IRC log for #brlcad on 20110804

IRC log for #brlcad on 20110804

00:00.03``Erikthere's a program called "nirt", it's a console interface to individually fire rays at geometry with text output... maybe that'll be helpful playing with to understand what's in the C structures?
00:00.21abhi2011ah thats for nirt is for
00:00.32abhi2011right i ll do that
00:00.49``Erik"natelies interactive ray tracer"
00:01.10``Erikstarseeker did a lot of work overhauling the documentation for it
00:01.15abhi2011yes I remember reading that somewhere among the heap of docs :P
00:01.26abhi2011cool
00:09.32``Erikokie, I'm heading out, if you have questions, throw 'em out... if no one else answers them, I'll be back on tomorrow morning and try to respond to them all :)
00:16.23*** join/#brlcad merzo (~merzo@118-62-132-95.pool.ukrtel.net)
00:21.44abhi2011right thanks Erik
00:22.24abhi2011here is the program for getting the BB for geometry in a .g file using only librt : http://bin.cakephp.org/view/570066725
00:33.23*** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net)
01:15.46CIA-62BRL-CAD: 03kunigami * r45779 10/brlcad/trunk/src/rt/ (do.c ext.h opt.c view.c worker.c): added the random, unbuffered mode. it have a strange behaviour: the frame buffer is only painting pixels with x=0, even though I'm passing random values of x ranging from 0 to 511
01:56.47kunigamiIn the lines of my commit's comment, I've made some tests with different values of w and h when calling RT.
01:57.05kunigami512x512: http://dl.dropbox.com/u/1399996/GSoC/RT512x512.png
01:57.22kunigami128x128: http://dl.dropbox.com/u/1399996/GSoC/RT128x128.png
01:57.37kunigami300x300: http://dl.dropbox.com/u/1399996/GSoC/RT300x300.png
01:57.49kunigami64x64: http://dl.dropbox.com/u/1399996/GSoC/RT64x64.png
01:58.58*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593653.dsl.bell.ca)
01:59.21kunigamiOne note: the last rendering (64x64) was done in unbuffered mode(because the width is less than 96)
02:01.42kunigamiIs this a bug or one is not supposed to use w,h less than 512 in fb mode?
02:04.21kunigamialso, when I force rt to use unbuffered mode, it renders a black scene. (512x512)
02:14.31CIA-62BRL-CAD: 03kunigami * r45780 10/brlcad/trunk/src/liboptical/sh_osl.cpp: removed (again) the loop in sh_osl since we are doing multi-samples before calling this shader
06:28.14brlcadkunigami: you're looking at several bugs there
06:28.36brlcadat least two of them related to x11 changes in the past 10 years
06:29.04brlcadfirst, I don't believe the black one is actually black, it's just not updating
06:29.20brlcadyou might see an image if you minimize/restore .. something to cause a redraw
06:30.03brlcadthe 128 version is supposed to be "zoomed" where pixels are auto-scaled 4x4
06:30.33brlcadthat used to work, but something has changed, causing it to only draw some subset of duplicated lines
06:31.26brlcadkunigami: one tool you might find useful since you're working in framebuffer land is 'fbserv' .. you can run a persistent framebuffer and send render results to it
06:31.43brlcadfbserv -S1024 0 /dev/ogl &
06:31.50brlcadrt -F0 file.g object
06:33.00brlcadespecially for debugging, it helps sort out whether problems are on the sender/drawing side or on the receiving/framebuffer side
06:33.24brlcadabhi2011: nice work!
06:33.43brlcadkeep that code around, you'll need it for your project
08:01.20*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:30.36brlcadyawns
13:35.42abhi2011brlcad: is there any example which shows how to actually move geometry in mged
13:37.15brlcadundoubtedly
13:37.31brlcadthe general idea is that you apply a transformation matrix
13:37.31abhi2011:)
13:37.36abhi2011yes right
13:37.48abhi2011so some of the functions fromvmath.h
13:41.26brlcadthose are general math macros
13:41.38brlcadmaybe helpful, but they don't know about geometry
13:49.01brlcadthere is a function table that responds to all entity types and performs operations on them
13:49.18brlcadapplying a transformation matrix is the ft_xform() callback
13:49.46brlcadrt_matrix_transform() wraps that into a relatively simple API call
13:50.10brlcadsee src/librt/transform.c
13:52.50abhi2011right thanks, by the ft_xform() callback is called automatically in every rendering cycle like in glut ?
13:58.10abhi2011ah ok there is a ft_xform for each type of primitive and the proper one is picked from the function pointers table and called using rt_functab[input->idb_type].ft_xform()
14:01.36abhi2011reminds me of virtual functions in c++
14:03.19brlcadthat's almost exactly what it is, polymorphic behavior in c
14:04.41brlcadyou might get a little lost in the logic, but you can see a transformation applied (eventually) in the inside command, src/mged/cmd.c in the cmd_ged_inside() function
14:05.34brlcadcalls transform_editing_solid() which calls rt_matrix_transform()
14:06.03brlcadof course, those are all mged logic -- not useful to you other than as reference
14:07.13brlcadit is a good next step, though -- our moss.g sample geometry has a light source in it, try to move that lightsource down to the ground plate
14:14.14abhi2011right
14:21.02CIA-62BRL-CAD: 03erikgreenwald * r45781 10/brlcad/trunk/src/rt/do.c: remove unused variable
14:21.32CIA-62BRL-CAD: 03erikgreenwald * r45782 10/brlcad/trunk/src/rt/view.c: remove unused variable. fix signed/unsigned issue
16:53.33*** join/#brlcad Stattrav (~Stattrav@122.164.241.143)
16:53.33*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:55.30CIA-62BRL-CAD: 03starseeker * r45783 10/brlcad/trunk/src/other/tcl/ (4 files in 2 dirs):
16:55.30CIA-62BRL-CAD: Start a clean-up of the Tcl cmake logic, backported from experiments in progress
16:55.30CIA-62BRL-CAD: with building 8.6. This version of the logic allows XCode 4 to successfully
16:55.30CIA-62BRL-CAD: build Tcl (not sure about older XCode versions). More work is needed to try a
16:55.30CIA-62BRL-CAD: broader XCode build of BRL-CAD.
17:17.21CIA-62BRL-CAD: 03bhinesley * r45784 10/brlcad/trunk/src/libged/edit.c: An argument duplication function was checking the (always empty) destination argument for an object before copying, when it should have been checking the source argument
18:03.51bhinesleyis there a way to get the apparant coordinates of an object, as offset by matrices, without stepping through the tree and adding all of them up?
18:07.16bhinesleyex: if a shape is at 0,0,0, but it's inside a combination that is at 1,1,1, which is inside another combination drawn at 2,2,2; what's the best way to get "3,3,3" if I have a db_full_path "comb1/comb2/object"
18:16.58*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:44.00*** join/#brlcad kunigami (~kunigami@201.53.206.27)
19:05.25*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593653.dsl.bell.ca)
19:38.10*** join/#brlcad merzo (~merzo@9-227-132-95.pool.ukrtel.net)
19:49.43CIA-62BRL-CAD: 03starseeker * r45785 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: Add M_LIBRARY to tcl, not just tclstub
20:14.13*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177593653.dsl.bell.ca)
21:28.56CIA-62BRL-CAD: 03bhinesley * r45786 10/brlcad/trunk/src/libged/edit.c:
21:28.56CIA-62BRL-CAD: Wrote body of edit_translate command (basically a stripped down version of the
21:28.57CIA-62BRL-CAD: very first translate command I wrote). Removed all dead/obsolete code. A bit
21:28.57CIA-62BRL-CAD: more work on path/object to coordinate conversion functions, but it's not usable
21:28.57CIA-62BRL-CAD: yet, and still a WIP.
22:16.55CIA-62BRL-CAD: 03starseeker * r45787 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: Add M_LIBRARY for tclsh too
22:35.04*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
22:36.43kunigamibrlcad:  I think I didn't get how to use this framebuffer server. I have no /dev/ogl (maybe because I did not enabled it when installing brlcad?) and running without setting the framebuffer doesn't work
22:56.07CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3042 10/wiki/User:Bhinesley: /* Log */ Logging last couple weeks
23:15.33CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3043 10/wiki/User:Bhinesley: /* General plan */ was outdated
23:16.27CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3044 10/wiki/User:Bhinesley: /* Development timeline (from proposal) */ rename
23:18.53CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3045 10/wiki/User:Bhinesley: /* Who I am */
23:21.00CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3046 10/wiki/User:Bhinesley: /* Experience */ Not too shabby at Tcl/Tk/Itcl/Itk
23:25.44CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3047 10/wiki/User:Bhinesley: /* GSoC 2011 Project */
23:26.29CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3048 10/wiki/User:Bhinesley: /* GSoC 2011 Project */
23:27.53*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
23:29.00CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3049 10/wiki/User:Bhinesley: /* Log */ grammar: A'int liking "got" none
23:46.19*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
IRC log for #brlcad on 20110805

IRC log for #brlcad on 20110805

00:29.01*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
01:42.57*** join/#brlcad merzo (~merzo@9-227-132-95.pool.ukrtel.net)
02:05.14CIA-62BRL-CAD: 03starseeker * r45788 10/brlcad/trunk/src/other/ (6 files in 4 dirs): More Tcl/Tk build logic changes, again backported from 8.6 experiments.
02:06.35CIA-62BRL-CAD: 03starseeker * r45789 10/brlcad/trunk/misc/CMake/FindX11.cmake: FindX11 changes from tk - really need to put together some svn foo to have all these multiple copies of files come from one source file.
02:10.24starseekerbrlcad: I don't suppose we could skip straight to svn 1.6?  http://stackoverflow.com/questions/1355956/can-we-set-single-file-as-external-in-subversion
02:18.20brlcadstarseeker: er, how does that affect us?
02:18.36brlcadthey're talking about svn:external
02:20.32brlcadlike, I want to set up MagicSpecialSauce.cmake with my awesome macro definitions as an svn external embedded into every cmake-using svn repos around the world
02:22.01brlcadfor checking out a single file, 1.5 added a hackish manual workaround way to do it
02:23.24brlcadthe hack might be useful for gs, but not strictly necessary
02:23.55brlcadkunigami: you can run "fbhelp" and it'll list your available framebuffer devices
02:24.14brlcad/dev/X or /dev/wgl or /dev/ogl are the usual suspects
02:25.35brlcadbhinesley: db_non_union_push()
02:27.07brlcadbhinesley: er, never mind .. misread
02:27.41brlcadif you call db_walk_tree(), there is a callback that will have the composite matrix accumulated
02:27.56brlcadsee src/libged/push.c or src/libged/xpush.c
02:28.23brlcad(which are two ged commands that should be refactored into one ...)
03:11.32starseekergah this is weird - I can successfully compile tcl/tk 8.6 and run it, but when I try 8.5 wish doesn't work - it segfaults immediately on Tk_Main, and I can't even tell why in the debugger
03:16.55brlcadsounds familiar :)
03:17.05brlcadmaybe you can finally reproduce that bug I mentioned
03:17.15starseekeryou mean the iwidgets bug?
03:17.27brlcadno, different init bug
03:17.39brlcadiwidgets was yet another
03:17.57starseekergets curious and tries 8.6 with BRL-CAD...
03:21.50starseekeroh, right - would need the new itcl/itk too
03:22.25starseekeralright... how the heck do I debug this?
03:22.37starseekerbraces himself for a long day tomorrow...
03:25.52brlcadwhy does it crash
03:26.00starseekersegmentation fault
03:31.23brlcadmore specific than that
03:31.51brlcadpresumably dereferencing some variable that is not a valid pointer
03:31.53starseekerhttp://pastebin.mozilla.org/1290015
03:32.36starseekerhttp://bzflag.bz/~starseeker/tcltk85-cmake.tar.gz is what I'm working with
03:34.11starseekercd tcltk85 && mkdir build && cd build && cmake .. && make -j4 && gdb ./bin/wish
03:35.11starseekerin a way it actually reminds me of the wish.exe failure we get on Windows
03:35.49starseeker8.6 actually working is a temptation... wonder how we would do with the next-gen itcl/itk
03:41.55starseekerdecides tomorrow is the time to test that and heads home
03:45.59*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
04:00.21brlcadstarseeker: ah, making more sense .. so then since it's actually crashing *on* the call to Tk_main() .. my guess is that it's probably getting the wrong libtk
04:02.27brlcadmake sure you've installed and it's pulling the right libs at runtime (force the (DY)LD_LIBRARY_PATH setting)
04:43.29starseekerbrlcad: it should be pulling the right lib
04:51.59brlcadof course it should
04:52.05brlcadbut is it really
04:54.56brlcadthe crash would indicate 'maybe not' or there's some static initializer causing havoc or lib incompat with binary, etc
05:43.12bhinesleybrlcad: looks good, thanks
07:33.15*** join/#brlcad kunigami (~kunigami@201.53.206.27)
08:51.21*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
10:53.31abhi2011Hi
10:53.42abhi2011I am playing with the nirt program now
10:54.18abhi2011so I was looking at the example in page 5 of the Interactive Ray Tracing_The nirt command.pdf file
10:55.03abhi2011there are these 2 lines in the example :
10:55.06abhi2011nirt> s
10:55.07abhi2011Origin (x y z) = (6.63324958 0.00000000 0.80000000) (h v d) = (0.0000 0.8000 0.0000)
10:55.50abhi2011this was got after automatically backing out the origin point from which the ray was shot by setting backout as 1
10:56.11abhi2011what I dont get is the h v d reported for the vew co-ordinates
10:57.18abhi2011I am guessing h v d is horizontal distance which is distance along x, vertical distance along z, depth along y
10:58.01abhi2011so in this case since the origin of the ray  has been auto backed out to (6.63324958 0.00000000 0.80000000), hvd should be =(6.63324958 0.8000 0.0000)
10:58.38abhi2011because the h represent horizontal distance along x and the x value of the origin of the ray is 6.6332
11:47.36*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
11:53.31abhi2011wow the nirt in mged visualization is amazing !!
14:17.36starseekerbrlcad: ldd thinks it's pulling the right one:  http://pastebin.mozilla.org/1290563
14:22.14starseekercan LD_LIBRARY_PATH override what ldd is reporting?
14:25.02starseekerhmm, ok... so the old build did work and the new one doesn't - what did I change...
15:33.01brlcadno, ldd takes ld-library-path into account
15:56.05CIA-62BRL-CAD: 03brlcad * r45790 10/brlcad/trunk/include/ (bu.h fbio.h): move RED/GRN/BLU from fbio to bu given how fundamental the need for indexing into an rgb[3] array is.
16:03.31*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
16:04.19CIA-62BRL-CAD: 03brlcad * r45791 10/brlcad/trunk/src/proc-db/sphflake.c: eek, wasn't using libbu memory management. call libbu and free dynamically allocated memory.
17:39.26*** join/#brlcad emagdalena (~emagdalen@129.Red-88-4-185.dynamicIP.rima-tde.net)
18:33.33CIA-62BRL-CAD: 03brlcad * r45792 10/brlcad/trunk/src/proc-db/ (CMakeLists.txt Makefile.am menger.c): (log message trimmed)
18:33.33CIA-62BRL-CAD: initial implementation of a new procedural geometry generator that makes menger
18:33.33CIA-62BRL-CAD: sponges. menger sponges are sierpinski carpet patterns in 3d. this
18:33.33CIA-62BRL-CAD: implementation supports creating the normal 'inside' subtraction patterns as
18:33.33CIA-62BRL-CAD: well as inverted 'outside' subtraction patterns. there are also options to only
18:33.34CIA-62BRL-CAD: perform the patterns along specified xyz axes. this test case was written as a
18:33.35CIA-62BRL-CAD: means to test/compare performance of arb8+csg evaluation against evaluated bot
18:48.59*** join/#brlcad emagdalenag (~emagdalen@129.Red-88-4-185.dynamicIP.rima-tde.net)
18:49.55*** join/#brlcad emagdalena (~emagdalen@129.Red-88-4-185.dynamicIP.rima-tde.net)
18:50.12*** join/#brlcad emagdalenag (~splineman@129.Red-88-4-185.dynamicIP.rima-tde.net)
20:10.23*** join/#brlcad merzo (~merzo@66-250-132-95.pool.ukrtel.net)
20:39.37CIA-62BRL-CAD: 03erikgreenwald * r45793 10/brlcad/trunk/src/proc-db/menger.c: free light1 instead of double-freeing light0
20:56.25*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
21:06.59brlcadoops
21:07.19brlcadfyi, still working on that proc
21:07.34brlcadgoing to change the way it creates the layers to make better csg
21:07.44``Erikit blows up pretty quick with -r values :)
21:07.47brlcadright now, it blows the stack after four levels
21:08.03brlcader, after *3* levels
21:08.10``Erikat -r3, there're some insane length names, too
21:08.49brlcadyeah, you can e up each level individually, though
21:09.12brlcade level1.c
21:09.17brlcadshould look sane
21:09.42brlcadeach level is also presently independent, so they overlap space
21:09.49``Erikrt level2.c seems to hang, or take a really really long time
21:10.03brlcadit's just a really long time
21:10.15brlcadprep is insane
21:10.33brlcadabout a half hour iirc
21:11.08brlcadit evaluates all the individual pushed matrices and ends up recursing several thousand times
21:16.20abhi2011Erik: I have a question about nirt
21:16.48``Eriksooooo, ask it? :D
21:17.16bhinesleyhey... what do you think this is, a public forum?!
21:17.36abhi2011So I am in page 5 of the nirt interactive ray tracing pdf :P
21:17.57abhi2011and there is the view co ordinates shown in 1 of the examples
21:18.06abhi2011(h v d) = (0.0000 0.8000 0.0000)
21:18.27abhi2011the complete line is  : Origin (x y z) = (6.63324958 0.00000000 0.80000000) (h v d) = (0.0000 0.8000 0.0000)
21:18.46abhi2011so the ray was short from x = 6.633, 0, 0.8
21:19.00abhi2011thus hvd should be = 6.633, 0.8 , 0
21:19.06abhi2011not as shown
21:19.27abhi2011because h represent "Horizontal" distance right ?
21:19.34abhi2011and v is vertical
21:20.18abhi2011hvd is the co-ordinates of the ray origin in view co-ordinates
21:22.17starseekerabhi2011: no, xyz is the origin
21:22.22starseekerhvd is the view plain, iirc
21:23.29starseekerwas never terribly comfortable conceptually with hvd
21:24.29abhi2011oh ok, so no matter where i move the ray origin through the dir command, as long as I dont change my view(say keep looking at it from the front), hvd shoudnt change
21:24.49abhi2011*the xyz command i mean, not dir
21:31.07abhi2011but the example in the pdf and when I run nirt on the given model, does not show that
21:31.39abhi2011so first the origin and hvd is : Origin (x y z) = (0.00000000 0.00000000 0.50000000) (h v d) = (0.0000 0.5000 0.0000)
21:32.13abhi2011then xyz alone is changed with backout enabled
21:32.27abhi2011and after shooting we get : Origin (x y z) = (6.63324958 0.00000000 0.80000000) (h v d) = (0.0000 0.8000 0.0000)
21:33.05abhi2011hmm, maybe in the example the view was changed
21:36.22abhi2011hmm , no it couldnt have been changed, seems hvd is connected to xyz somehow
21:37.15abhi2011probably the view is changed to look towards the direction from which the ray will be shot
21:37.22abhi2011that seems to be the relation
21:52.24*** join/#brlcad kunigami (~kunigami@201.53.206.27)
22:06.09bhinesleyam I correct in assuming that bombing macros are disabled for a release build?
22:07.53bhinesleyI've been sticking BU_ASSERT's  all over the place
22:55.49abhi2011the command wrappers defined in mged/cmd.c  like cmd_ged_edit_wrapper seems to be all designed to send data back to a  tcl procedure
22:56.17abhi2011I guess this is the tcl proc thats invoked when the user types the command in the gui
22:59.27CIA-62BRL-CAD: 03starseeker * r45794 10/brlcad/trunk/src/other/tk/CMakeLists.txt: Ah HAH! Need to be more selective about when we define USE_TCL_STUBS - wish no likie.
23:00.01*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
23:07.39abhi2011I was looking into how tcl/tk is integrated with C as thats what appears to be used to add command to the mged tcl/tk user interface
23:08.26CIA-62BRL-CAD: 03brlcad * r45795 10/brlcad/trunk/src/proc-db/csgbrep.cpp: working towards writing out both brep and implicit forms for each entity type. consolidate writing out the objects to a common function, reducing 60+ lines
23:08.48abhi2011So I am guessing  the commands are written as an extension with an entry point like int DLLEXPORT  Entry_point_func(Tcl_Interp *interp) ?
23:09.05brlcadbhinesley: in general, they're left enabled
23:09.40brlcadit's only for specific production environments that need to squeeze out another 10-20% performance on inputs that are known to be good
23:10.18brlcadabhi2011: not really
23:10.46brlcadabhi2011: there is a simple mapping table in src/mged/setup.c that sets up the libged function name
23:11.12brlcadwhen a command is called, it walks the mapping table until it finds a match and simply calls that function
23:12.06brlcadin that sense, the ged_*() functions are "entry points" but that term seems ill/undefined
23:13.07bhinesleybrlcad (on tcl): that's what I thought... I never found any TCL c headers being used.
23:13.11abhi2011ok the entry point is defined in tclcad.c
23:14.45*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
23:15.12starseekersings a chorus of "ding dong the witch is dead..."
23:15.25bhinesleybrlcad (on bombing macros): so, I supposed I should limit the use of my asserts, or at least #if 0 them out
23:15.40bhinesleystarseeker: congrats :)
23:16.33brlcadbhinesley: nah, assert overhead is nominal
23:16.56brlcadyou shouldn't assert for the heck of it -- since the result of a failed assert is to abort an application
23:17.39brlcadif you validate your inputs and they fail, you return an error
23:19.23bhinesleybrlcad: I'm only using them to confirm that other functions are operating correctly; where just assuming that they are would probably cause a crash anyways
23:19.36brlcadthen it's all good
23:19.58CIA-62BRL-CAD: 03starseeker * r45796 10/brlcad/trunk/src/other/tcl/ (4 files in 4 dirs): Let's see if we can do without the tcl_cfg.h hack altogether.
23:20.26brlcadthat's exactly how they're intended to be used, to detect memory/logic bugs and abort early instead of crashing
23:20.35brlcador (worse) corrupting user data
23:20.48bhinesleyok, cool
23:21.21CIA-62BRL-CAD: 03brlcad * r45797 10/brlcad/trunk/src/proc-db/csgbrep.cpp: reduce about 20 more lines -- don't need separate arrays for arb data
23:23.47CIA-62BRL-CAD: 03starseeker * r45798 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: Whoops - don't forget windows.
23:29.25abhi2011brlcad : right, I get it
23:35.16*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
IRC log for #brlcad on 20110806

IRC log for #brlcad on 20110806

00:25.57CIA-62BRL-CAD: 03brlcad * r45799 10/brlcad/trunk/src/librt/primitives/brep/ (brep_debug.cpp brep_debug.h): RED/GRN/BLU are defined by libbu, pick a different name for RED
00:31.59CIA-62BRL-CAD: 03brlcad * r45800 10/brlcad/trunk/src/libwdb/skt.c:
00:31.59CIA-62BRL-CAD: still need to do more, but make a copy of the caller's sketch (in case it's on
00:31.59CIA-62BRL-CAD: the stack where the eventual call to bu_free() down in wdb_export() would be
00:31.59CIA-62BRL-CAD: bad). this is incomplete since we still should perform a deep copy of the
00:31.59CIA-62BRL-CAD: caller's struct (including all of the segments).
00:32.55CIA-62BRL-CAD: 03brlcad * r45801 10/brlcad/trunk/TODO: autotools unbusted, just needed a version bump
00:33.41CIA-62BRL-CAD: 03brlcad * r45802 10/brlcad/trunk/TODO: note to self, deep sketch copying still needed
00:36.51CIA-62BRL-CAD: 03brlcad * r45803 10/brlcad/trunk/src/proc-db/csgbrep.cpp: even further reduction of about 70 lines. code went a wee bit nuts with dynamic memory allocation. simplify, put objects on the stack.
00:43.27abhi2011brlcad : for testing object movement its best to write a mged plugin I guess. A stand alone program like the ones I wrote before do not have an opengl window anway
00:46.45CIA-62BRL-CAD: 03bhinesley * r45804 10/brlcad/trunk/src/libged/list.c: return from function bypasses rt_db_free_internal() call
01:51.44*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:22.01brlcadabhi2011: yes, that's the idea .. a libged command similar to 'clone' (src/libged/clone.c), search for 'clone' in src/mged and src/libged
02:22.08CIA-62BRL-CAD: 03bhinesley * r45805 10/brlcad/trunk/src/libged/edit.c: Functions for converting paths+objects+offsets to coordinates are written; need to be tested/debugged. Pretty close to being done with the command agnostic edit() stuff.
02:51.48*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:57.29CIA-62BRL-CAD: 03bhinesley * r45806 10/brlcad/trunk/src/libged/edit.c: (log message trimmed)
02:57.30CIA-62BRL-CAD: Reflowed all comments. Enable execution of subcommand functions in edit(),
02:57.30CIA-62BRL-CAD: "subcmd->cmd->exec()". The translate command should be operational through
02:57.30CIA-62BRL-CAD: ged_edit() once I resolve several issues with edit() and friends. The only
02:57.30CIA-62BRL-CAD: exception that I can think of, is the use of the bounding box centers of
02:57.30CIA-62BRL-CAD: objects; although everything in edit.c was designed with this in mind, the
02:57.30CIA-62BRL-CAD: argument-to-coordinate functions currectly will only use natural origins. It's
03:00.27CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3050 10/wiki/User:Bhinesley: /* Log */ today, and what's next
08:09.15*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
09:32.11*** join/#brlcad emagdalena (~splineman@129.Red-88-4-185.dynamicIP.rima-tde.net)
09:32.20*** join/#brlcad splineman (~splineman@129.Red-88-4-185.dynamicIP.rima-tde.net)
13:26.42*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
14:07.47*** join/#brlcad Elrohir (~kvirc@p5B14BCFE.dip.t-dialin.net)
14:43.34*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
16:33.49*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
17:45.41abhi2011here is the code so far for the new runphysics command which will move objects according to newtonian physics :P
17:45.45abhi2011http://bin.cakephp.org/view/558121873
17:46.39abhi2011I have got it inside mged as a command, as of now I am trying to apply a simple translation to a passed object to see if I can move them around
17:47.15abhi2011I am using transform_editing_solid()
17:48.00abhi2011though the solid passed will not be the current solid being edited , but instead the struct rt_db_internal for the passed object
18:24.46abhi2011ok I ll directly use rt_matrix_transform from librt
19:20.36*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:56.12brlcadmm, that looks not too shabby from abhijit
20:57.45*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
22:36.03abhi2011ok so I am trying to translate an object using an mged command in preparation to do more physics based transformations
22:36.08abhi2011here is the code : http://bin.cakephp.org/view/558121873
22:36.29abhi2011so I am trying to apply a simple translation to the passed object using rt_matrix_transform
22:36.48abhi2011and the command runs without errors and prints a message afterwards
22:37.00abhi2011so I am guessing the transformation matrix was applied
22:37.52abhi2011but the thing is, the rt_matrix_transform() commands takes an input solid (struct rt_db_internal) and returns an output solid (again another rt_db_internal)
22:38.05abhi2011this new solid should be at the new translated position
22:38.21abhi2011but I am not able to figure out how to verify this
22:39.00abhi2011this new solid is apparently not inserted automatically into the model tree as I cant see it using the list command in mged
22:39.22abhi2011I tried rt_db_put_internal(ndp, gedp->ged_wdbp->dbip, &os, 0); but it runs into pointer erros
22:44.00abhi2011so basically I need to insert the output solid returned by rt_matrix_transform() into the model tree or at the least print its position so I can see if its at the translated position
22:46.26``Erikcombinations hold matrices, primitives do not... the 'xpush' command walks down the tree propogating the matrix and finally modifying the primitive, so all matrices in the path should be identity... is that what you're looking for?
22:46.33abhi2011I cant do if ((ndp = db_lookup(gedp->ged_wdbp->dbip, os, LOOKUP_NOISY)) == RT_DIR_NULL){    either as I need the name of the output solid
22:47.33abhi2011Erik : ah ok so I can try to apply the transform on a combination
22:47.58abhi2011but if I use rt_matrix_transform() for that
22:48.26abhi2011then the paramters of rt_matrix_transform() show that there is an input and an output struct rt_db_internal
22:48.40abhi2011struct rt_db_internal is what will hold information about the combination I guess
22:49.08``Erikhm, looking at the source, rt_matrix_transform is just the last step to actually try to mutate the primitive :/
22:49.10abhi2011so rt_matrix_transform() does not transform the input directly
22:49.19abhi2011ah ok
22:49.32abhi2011all I need is to move a primitive or a combination
22:49.53abhi2011using a translation matrix as of now
22:50.04``Eriksrc/mged/edsol.c is where that function is called
22:50.12abhi2011yes
22:51.19``Erikhas a party to head off to, perhaps brlcad will peruse the backlog later and provide more insight
22:53.05abhi2011have a great time :)
23:18.38kunigamianyone able to compile the latest revision? I'm getting linking errors from libtk
23:26.33starseekerkunigami: what errors?
23:27.42starseekertrunk builds for me on gentoo...
23:30.36kunigamistarseeker: http://paste.ubuntu.com/660137/
23:32.00kunigamiweird. I tried a clean install and the problem persists
23:45.22CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3051 10/wiki/User:Abhijit: /* Development timeline */
IRC log for #brlcad on 20110807

IRC log for #brlcad on 20110807

00:17.33*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
02:48.53starseekerkunigami: is it building tcl?
02:49.17starseekerif that's a CMake build, can you post again with make VERBOSE=1 ?
02:50.20kunigamistarseeker: right, I'll do that in a minute. I went back to r45780 and it seems fine (r5797 gives a compile error too)
02:50.45starseekerkunigami: it's very probably the tweaks I made to the tcl/tk build system
02:51.07starseekerkunigami: you're on a mac?  which version of OSX?
02:51.39kunigamiI'm on on mac 10.6
02:51.44starseekerhuh
02:52.00starseekerwhat's your cmake configure line?
02:52.18kunigamistarseeker: cmake ../brlcad -DBRLCAD-ENABLE_OPENGL=OFF -DBRLCAD-ENABLE_COMPILER_WARNINGS=OFF -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DBRLCAD-ENABLE_OSL=ON -DCMAKE_INSTALL_PREFIX=/Users/kunigami/dev/brlcad-bin/ -DBRLCAD-ENABLE_STRICT=OFF
02:53.42starseekerhuh.  yeah, if you can post the whole thing (that plus make VERBOSE=1 ) that should help
02:54.47kunigamihere it is: http://paste.ubuntu.com/660214/
02:59.24starseekerkunigami: um.  can you try it again from a clean build directory?
02:59.50starseekereg cmake <options> && make VERBOSE=1
03:00.02kunigamioh, sure!
03:04.49starseekergah, wait a sec...
03:05.58CIA-62BRL-CAD: 03starseeker * r45807 10/brlcad/trunk/src/other/tk/CMakeLists.txt: Whoops. Helps to spell things correctly.
03:06.21starseekerkunigami: see if that fixes things
03:14.40kunigamistarseeker: seems it did! thank you!
04:03.30starseekerO.o  http://nova-docdb.fnal.gov/cgi-bin/ShowDocument?docid=6090
04:09.54starseekerhmm - can at least partially import this but it raytraces funny http://acquisition.jpl.nasa.gov/rfp/JC-2663-595218/GantryCADfile(STPformat).stp
04:58.12*** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br)
08:50.49CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3052 10/wiki/User:Abhijit: /* Logs */
08:56.05CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3053 10/wiki/User:Abhijit: /* Log */
12:15.45abhi2011brlcad : I have written the runphysics command to translate an input object using the rt_matrix_transform() function : http://bin.cakephp.org/view/1932154726
12:17.31abhi2011A new combination which is a copy of the input,  is created at the translated position (later I will make it work on the input combination itself)
12:19.13abhi2011I added the new translated combination to the db tree, but it seems to not respond to draw commands, this is the error I get in Mged : http://bin.cakephp.org/view/1614988156
13:15.10*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:48.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:15.05*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
14:46.43brlcadabhi2011: looking good ... does it work?
14:49.12brlcadone change I'd like to request .. "runphysics" sounds too quirky, too ambiguous
14:49.12abhi2011umm no brlcad :(
14:49.19brlcadalmost like "do science"
14:49.24abhi2011haha :)
14:49.38abhi2011"simulate"
14:49.42``Erik"teh winz:
14:50.01brlcadthat's exactly what I was going to suggest, "simulate" is better and extends to other operations in the future
14:50.11abhi2011right
14:50.18abhi2011so regarding the code
14:50.43abhi2011its seems that rt_matrix_transform() takes an input combination and returns an output combination
14:50.59brlcadokay
14:51.00abhi2011but what would be better is to directly act on the input
14:51.03``Eriksips his irish coffee in celebration of a successful oil change and tire rotation (next time, imma just pay someone to do it)
14:51.16abhi2011change its attributes so it gets drawn in the new position
14:51.49brlcadabhi2011: are you saying that the output combination is not the same as the input combination?
14:51.58``Erikthought rt_matrix_transform() just called the f_xform() field for the primitive, it did NOT operate at the comb level... but I may misrecall
14:52.17abhi2011brlcad : well I think so
14:52.39abhi2011because when I add it to the db then it shows an error
14:52.59abhi2011http://bin.cakephp.org/view/1614988156
14:53.24brlcad``Erik: it calls into the object functab
14:53.29abhi2011I call the output combination as translated_solid
14:53.32brlcad(combs are registered as objects)
14:53.39``Erikah, did not know that
14:53.49``Erikdo combs recursively pass the xform?
14:54.10``Erikxpush style?
14:54.35brlcadI don't recall, but I don't think so
14:54.54brlcadjust calls the generic transform
14:55.10``Eriksets the comb matrix and returns, ok
14:55.19``Erikmight be a pertinent detail to abhi's stuff
14:55.25brlcadwhich does an import with a matrix applied
14:55.59brlcadabhi2011: what is translated_solid?
14:56.03brlcad"l translated solid"
14:56.11brlcader, "l translated_solid"
14:56.23abhi2011its the output of rt_matrix_transform()
14:56.36brlcadno
14:56.38abhi2011i add the output of rt_matrix_transform() to the database
14:56.40brlcadrun that command in mged
14:57.15abhi2011yes  the command adds it to the database
14:57.24brlcad*sigh*
14:57.25brlcadno
14:57.33brlcadrun ... "l translated_solid" ... in mged
14:57.39abhi2011oh ok
14:58.04``Erikmost mged commands are simple wrappers to the C library
14:58.35``Erikso "what does this mean" can be easily experimented with by doing mged cmds
15:00.19brlcadfrom that pastebin listing, it looks like translated_solid is wrong -- it's not recognized as a comb yet giving a subtree failure
15:00.57abhi2011ya seems that way
15:00.59abhi2011http://bin.cakephp.org/view/1112923952
15:01.02brlcadI wouldn't worry about making a copy just yet -- try updating the original object
15:01.36brlcadinteresting
15:01.37abhi2011ok , then rt_matrix_transform() output should be copied into the original object
15:01.55brlcadrt_matrix_transform applied the change to the original object
15:01.59brlcadyou just have to write it out to disk
15:02.16brlcadlook at the other places where rt_matrix_transform() is called, see what else they're doing
15:02.39abhi2011yes
15:03.02abhi2011the translate and rotate commands apply vector math to do their thing
15:03.40abhi2011I was looking at chgmodel.c for how these commands work
15:04.22brlcadI believe you just feed rt_matrix_transform() the same rt_db_internal pointer for both input and output
15:05.11brlcadthen it'll either be written to disk, or you'll call an export function (e.g., rt_db_put_internal()) to write it
15:05.26abhi2011oh its that simple....:P
15:05.46brlcadit's something close to that simple
15:07.15abhi2011yes after getting the output from rt_matrix_transform() , I call db_diradd() to get the directory pointer and then rt_db_put_internal() to put the internal format of the combination to the disk
15:08.33``Erikbrlcad: I think I have the new machine cleaned up and about ready to look at migration again, the hiccup with the weird dep thrashing everything is fixed
15:09.44``Erik(if not zomfg migration, I'd appreciate the crit. name being moved so'z I don't have to remember #'s :D )
15:14.04brlcadnods
15:19.34abhi2011YES!!!! :)
15:19.40abhi2011just moved it
15:19.52abhi2011brlcad: thanks !
15:21.13abhi2011here is the modified code , have to clean up though : http://bin.cakephp.org/view/1932154726
15:36.50*** join/#brlcad splineman (~splineman@155.Red-88-21-190.staticIP.rima-tde.net)
15:36.56*** join/#brlcad emagdalenag (~splineman@155.Red-88-21-190.staticIP.rima-tde.net)
15:38.35*** join/#brlcad splineman (~splineman@155.Red-88-21-190.staticIP.rima-tde.net)
15:38.57*** join/#brlcad emagdalena (~emagdalen@155.Red-88-21-190.staticIP.rima-tde.net)
15:53.26abhi2011I am trying to do arbitrary rotations now for the simulate command
16:08.26*** join/#brlcad emagdalenag (~emagdalen@3.Red-83-56-124.dynamicIP.rima-tde.net)
17:13.41brlcadexcellent
18:24.04*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:32.00CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3054 10/wiki/User:Abhijit: /* Log */
18:54.23CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3055 10/wiki/User:Abhijit: /* Log */
20:46.54abhi2011ok I get a strange behavior when I link the simulate command with a command wrapper
20:47.28abhi2011so I have modified cmd.c to include a new command wrapper for the new mged command "simulate"
20:48.05abhi2011cmd.c now has the implementation for cmd_ged_simulate_wrapper(ClientData clientData, Tcl_Interp *interpreter, int argc, const char *argv[])  
20:48.18abhi2011its very similar to the cmd_ged_edit_wrapper()
20:49.11abhi2011http://bin.cakephp.org/view/1859715979
20:49.48abhi2011in the command wrapper I call the libged function which actually implements the simulate function : ged_simulate(struct ged *gedp, int argc, const char *argv[])
20:50.24abhi2011i call ged_simulate() 100 times from the command wrapper with an artificial delay inserted of 1/10th of a second
20:51.51abhi2011ged_simulate() is called inside a for loop and I draw the object at the new position as well at the end of each iteration, so it should appear to move every 1/10th of a second in mged
20:52.36abhi2011but the object is moved only at the end of all the iterations when the command wrapper returns
20:53.10abhi2011I would have expected mged to draw the object immediately after the cmd_draw() is called to draw the object
20:58.41abhi2011so the way the simulate command should work is , the user gives the number of steps to simulate as : simulate 10
20:59.17abhi2011and then the physics takes over and simulates with the command wrapper for simulate called the libged simulate implementation 10 times
21:00.14abhi2011but after each call to the libged simulate function ged_simulate(), the position of the dynamic object should be redrawn in mged and not after all the iterations are complete
21:00.14``Erikcommand sounds about right, I believe there is a "flush" type command that has to be passed to force display
21:00.25abhi2011aoh
21:00.35abhi2011right i ll check it
21:31.23abhi2011there is a update_views = 1;  probably that one  
21:54.48``ErikI tend to avoid gui code, but that sounds familiar. I think there was maybe discussion about an explicit "block until" flush cmd? I'm not sure :/
21:55.17``Erik(the discussion being about if we should implement one, or if the variable is adequate)
22:09.59abhi2011any way to grep the irc logs :P
22:16.34*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
22:18.02louipcabhi2011: the one's stored on your computer?
22:21.59abhi2011no the logs for the last few months
22:22.46abhi2011louipc: maybe I can find the discussion regarding the 'block until' flush command that Erik was speaking about
22:28.36abhi2011basically if a command is taking too long to process, there must be a way to send updates to the user as it progresses
22:58.53louipcabhi2011: you can try using google to search maybe
22:59.44louipcabhi2011: search "site:http://ibot.rikers.org/%23brlcad/ abhi2011" for example
23:20.18abhi2011louipc: ah yes that works quite well
23:20.34*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
23:37.04*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
IRC log for #brlcad on 20110808

IRC log for #brlcad on 20110808

00:49.06abhi2011ok so I am trying to add a new .cpp file to src/libged where all the c++ code to access bullet physics will go
00:49.40abhi2011the cpp file has a header which I include in the mged command implementation file
00:50.43abhi2011So my c++ test file is simphysics.cpp with some test code
00:51.45abhi2011http://bin.cakephp.org/view/1739302378
00:53.23abhi2011I have a header for it and this is included in simulate.c which has  the libged implementation of the simulate command : http://bin.cakephp.org/view/1706385166
00:54.24abhi2011the cpp file has the definition of a single function single_step_sim() which uses the cout object to print out some test message
00:55.19abhi2011I get a linking error when I compile which says single_step_sim()  is an undefined reference
00:56.39abhi2011However since I have included the header (which declares single_step_sim()  )    in simulate.c  the compiler should be able to see the declaration
00:57.14abhi2011Perhaps it has to be exported using GED_EXPORT, but its not called from outside the library so it shouldnt be required to export it
01:06.51abhi2011this is the linking error : http://bin.cakephp.org/view/1997617995
05:15.44*** join/#brlcad Stattrav (~Stattrav@203.196.190.162)
05:15.44*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
06:04.43*** join/#brlcad emagdalenag (~emagdalen@109.Red-88-4-184.dynamicIP.rima-tde.net)
10:23.01*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
11:32.54CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r3056 10/wiki/User:Kunigami/GSoc2011/Reports: /* Week 11 (August 1st to August 8th) */ log for past week
12:30.41*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:36.39abhi2011has anyone tried to add c++ files to existing code, that is mixing c with c++
12:38.07brlcadabhi2011: adding c++ to c files would make them c++ files
12:40.40brlcadyou'll want to write a bridge, i.e., one or more C functions that wrap all of your C++ logic
12:40.42abhi2011ok I am trying to integrate bullet c++ code into brlcad
12:40.48brlcadI know
12:40.49abhi2011right
12:41.08brlcadthose bridging functions will need to be marked extern "C" since they're in c++ files
12:41.16brlcadso that they're not name-mangled
12:42.52abhi2011yes I have written a separate function in a cpp file simphysics.cpp that has all the c++ code, I have declared this function in a header simphysics.h
12:42.54*** join/#brlcad emagdalenag (~emagdalen@179.Red-88-4-185.dynamicIP.rima-tde.net)
12:43.10abhi2011i include this header in simulate.c which is the libged simulate command implementation
12:43.41abhi2011in the header where i declare the c++ function, I can declare it as extern
12:43.55brlcadit's not just extern
12:43.58brlcadit's extern "C"
12:44.05abhi2011ah ok
12:44.20brlcadsearch for that in existing include/*.h headers
12:44.21abhi2011i get it
12:44.27abhi2011right
12:44.39brlcadstop saying right :)
12:45.05abhi2011:P, yes
12:51.46brlcadheh, http://www.sbir.gov/sbirsearch/detail/93829
12:52.06brlcadapparently ARA got half a million back in the mid-90's to develop that .. interesting, never saw it
12:52.35brlcad(assuming they got phase 2 funding, maybe only phase 1)
13:40.55abhi2011interestng
14:19.10*** join/#brlcad emagdalenag (~emagdalen@41.Red-88-21-190.staticIP.rima-tde.net)
14:52.47*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-187-155.wlan.tudelft.nl)
15:25.29CIA-62BRL-CAD: 03brlcad * r45808 10/brlcad/trunk/src/libwdb/skt.c: there already exists a copy function for deep copying, so use it.
15:27.33CIA-62BRL-CAD: 03brlcad * r45809 10/brlcad/trunk/src/libwdb/ (CMakeLists.txt Makefile.am sketch.c skt.c): rename from skt.c to sketch.c because it's easier to find the file if the filename matches the primitive's canonical short name.
15:35.56*** join/#brlcad kunigami (~kunigami@201.53.206.27)
15:49.05*** join/#brlcad fosburg (~steve@or-67-238-17-118.dhcp.embarqhsd.net)
15:49.59fosburganyone here
16:04.54*** join/#brlcad kunigami (~kunigami@201.53.206.27)
16:07.57*** join/#brlcad kunigami (~kunigami@201.53.206.27)
16:11.46*** join/#brlcad fosburg (~steve@or-67-238-17-118.dhcp.embarqhsd.net)
16:16.06kunigamirt is running out of single letter options :) shouldn't we allow more for more mnemonic options?
16:16.46kunigamiI'd like to add a framebuffer mode. Bothb,B, f and F are already taken, but -fb would be better anyway
16:23.47brlcadkunigami: we don't (yet) have proper infrastructure in place for --long-options
16:25.02brlcadwith getopt, -fb is equivalent to "-f -b", so at best you'd need something like --fb
16:25.12brlcadthat said, what do you mean by framebuffer mode?
16:27.20CIA-62BRL-CAD: 03brlcad * r45810 10/brlcad/trunk/include/wdb.h: meant to commit this with r45808, made the passed parameter const now that it's properly copied before export.
16:28.36CIA-62BRL-CAD: 03brlcad * r45811 10/brlcad/trunk/include/raytrace.h: add a new type, rt_curve, for use by sketch and extrude definitions.
16:38.40abhi2011does anyone else get warnings about the version infomation being missing from libz : /usr/bin/cmake: /usr/brlcad/dev-7.20.3/lib/libz.so.1: no version information available (required by /usr/bin/cmake)
16:38.58abhi2011I get this during cmake and during make install as well
16:39.38abhi2011maybe the libz version info needs to be patched
17:03.11*** join/#brlcad fosburg (~steve@or-67-238-17-118.dhcp.embarqhsd.net)
17:05.32kunigamibrlcad:  something like we discussed on email: the frequency on which the framebuffer is updated and how rays are shot. this would form two options. I want to add an option for the "how rays are shot". fb was just an example for a long letter example. Which name would better describe this parameter? tr?
17:08.05brlcadthat rabbit hole runs a little deep :)
17:09.25brlcadmy point wasn't specific to -fb, -abc == -a -b -c to getopt (which is highly desireable in some contexts)
17:09.42brlcadthe feature missing is long-opts support, which would let you specify longer name options in addition to one-letter optiosn
17:10.15brlcadhalf of rt's short options would be better as long-only options for some form of advanced control
17:11.38brlcadbut like I said, the infrastructure for long options isn't implemented, so better to just pick one of the few remaining one-letter options for now unless you want to tackle implementing long options properly (new libbu api)
17:12.12kunigamihehe ok. Will choose one of the remaining :)
17:12.19brlcad:)
17:13.01brlcadlooks like -m -y -z -L -Y -Z plus some punctuation are all that remain
17:15.39brlcadgiven -l is lighting model, -L for firing pattern might work well
17:18.36brlcadanother option might be to overload the -Q option or -B option
17:18.51brlcadlooks like -b might be fair game too..
17:22.08brlcaddefinitely fair game, it's the same as -j
17:22.54brlcadso I suggest -L, -Q, or -b
17:23.40brlcadthe latter two require a little refactoring, but seem most appropriate
17:25.43brlcadkunigami: suggest writing up the proposed usage change like what bhinesley did for edit, either as a comment or wiki dev page would be sufficient
17:26.05brlcadto make sure the usage is clean and impact minimal before you run down a path
17:27.14brlcadrt is a critical path, so should make sure there's extra thought put into how the new options will get used
17:33.31CIA-62BRL-CAD: 03brlcad * r45812 10/brlcad/trunk/src/libwdb/ (CMakeLists.txt Makefile.am extr.c extrude.c): rename extr.c to extrude.c so that the filename matches the primitiv'es canonical short name. makes it easier to identify what this file contains.
17:35.33*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
17:44.47kunigamibrlcad:  comment right on the code? like rt/main.c or rt/opt.c?
17:45.40brlcadanywhere, just some place we can collectively see it
17:45.52kunigamiok!
17:58.49*** join/#brlcad fosburg (~steve@or-67-238-17-118.dhcp.embarqhsd.net)
18:12.14brlcadexcellent
18:12.35brlcadcouple usage examples would be helpful too in addition to more formalized usage syntax
18:23.00CIA-62BRL-CAD: 03brlcad * r45813 10/brlcad/trunk/src/tclscripts/menu_override.tcl:
18:23.00CIA-62BRL-CAD: example of why it's useful to see the tclsh warnings.. remove a handful of
18:23.00CIA-62BRL-CAD: ::tk:: functions that curiously are living in our sources, yet they don't appear
18:23.00CIA-62BRL-CAD: to have any overridden behavior. menus in mged tested fine without, so let the
18:23.01CIA-62BRL-CAD: tk guys manage their own code. remove our fork.
18:25.58``Erikstarseeker: tclUnixInit.c:367 or so, #include <sys/utsname.h> for uname(3) on line 471 or so
18:26.22CIA-62BRL-CAD: 03brlcad * r45814 10/brlcad/trunk/misc/Doxyfile: output to 'doxygen_output' in whatever our current directory is, no point putting it into misc
18:28.06CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r3057 10/wiki/User:Kunigami/GSoc2011/RT_Parameters_Proposal: draft to present the new options to be added RT application. Waiting for review before implementing
18:28.28CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r3058 10/wiki/User:Kunigami/GSoc2011/RT_Parameters_Proposal: /* Examples */ correct formatting
18:29.28*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ)
18:29.38kunigamimay I already add osl and oiio code to the svn?
18:30.03tofuhow big are they?
18:30.48*** mode/#brlcad [+o brlcad] by ChanServ
18:31.01kunigamiosl is 5MB
18:31.24kunigamioiio is 9.4MB
18:31.50kunigamior we'll let them be optional external code?
18:31.56brlcaddo they have any dependencies of their own?
18:32.09brlcadit depends just how complex they are
18:32.20kunigamiyes, a quite long one by the way
18:33.35brlcaddo you have the build documented somewhere?
18:33.48kunigamihttp://brlcad.org/wiki/User:Kunigami/GSoc2011/OSL_Tutorial
18:33.59brlcadexcellent, thought you had
18:34.58starseekeras i recall, OSL has quite the nasty dependency list
18:35.02kunigamibut I didn't mentioned all the dependencies. Most of them are aviable like in mac ports or ubuntu synaptic
18:35.08starseekerllvm
18:35.10kunigamistarseeker: yup
18:36.24brlcadah, right, llvm .. that's certainly a pickle
18:37.14brlcadpretty much guarantees it'll be disabled on release configurations unless we do some heavy lifting to make it easier
18:37.16starseekerboost, imath, openimageio
18:38.25starseeker(imath looks like it may be part of openexr)
18:38.45kunigamiyes, I had to install openexr
18:38.53brlcadkunigami: how about checking all of the deps into a separate module
18:39.24starseekernot surpring, openexr really has taken off in the movie industry and that's sony's target use case for this...
18:39.31brlcadwe can hook those in later as an svn external if we want, or extra download step
18:39.41starseekervotes for that appraoch
18:39.41brlcadbut that way, the N deps are all in one place
18:39.43starseekerapproach even
18:40.51brlcadthen their compilation can be wrapped up with even a simple Makefile that will compile/install all in the proper order
18:41.01brlcad<PROTECTED>
18:41.17brlcadkunigami: do you know how to create a new module?
18:41.18starseekerosl itself uses cmake
18:41.29kunigamikunigami: nope
18:41.34kunigamiops
18:41.37kunigamibrlcad: nope
18:41.38brlcadsure, but it's just one of about a half-dozen or so
18:42.08starseekeropenimagio has one, it looks like
18:42.13starseekerpretty sure llvm does
18:42.39kunigamiyou mean cmake module? like FindXYZ.cmake?
18:43.00starseekerno, CMakeLists.txt file
18:43.08brlcadkunigami: basically, you'll checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad (perhaps with max-depth set to 0 so it doesn't check out the whole repo) and add an 'osl' dir with three subdirs, 'trunk', 'branches', 'tags'
18:43.56brlcadthen add the various OSL packages as subdirs under /svnroot/brlcad/osl/trunk/.
18:44.30brlcadone dir for each dep, openexr, llmbase, boost, etc
18:44.52brlcadcan skip any external deps that are in /svnroot/brlcad/brlcad/trunk/src/other (like libpng, libz, etc)
18:45.43starseekerhmm... openexr doesn't have one
18:45.52starseekerwonder if they'd accept one
18:46.16brlcadunless we plan on fully managing them, wouldn't bother
18:46.55brlcadonly reason to add them is to have them in revision control so they can be conveniently downloaded if we want to push out binaries with osl enabled
18:47.57brlcadexr-pix would be cool, that'd be a reason :)
18:49.10starseekerisn't quite sure how exr would integrate with our tools - we might have to make rt and friends output straight to exr if we wanted to take full advantage of it...
19:03.39CIA-62BRL-CAD: 03kunigami * r45815 10/osl/ (. branches/ tags/ trunk/): setting up initial structure for osl code and dependences
19:06.27*** join/#brlcad fosburg (~steve@or-67-238-17-118.dhcp.embarqhsd.net)
19:12.31CIA-62BRL-CAD: 03starseeker * r45816 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: Add one missing file to Windows source list - this new setup, for the first time, allows for a successful run of wish.exe
19:22.44*** join/#brlcad emagdalena (~emagdalen@216.Red-88-4-184.dynamicIP.rima-tde.net)
19:38.33CIA-62BRL-CAD: 03brlcad * r45817 10/brlcad/trunk/misc/ (CMakeLists.txt Makefile.am): the Doxygen paths are already relative, so no need to auto-generate the file with full-paths shoved in. write out to the doc dir.
19:56.07CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r3059 10/wiki/User:Kunigami: /* Links */ added link to my RT parameters proposal
20:01.04*** join/#brlcad dli (~dli@dsl-67-204-17-156.acanac.net)
20:03.49CIA-62BRL-CAD: 03brlcad * r45818 10/brlcad/trunk/ (16 files in 10 dirs):
20:03.50CIA-62BRL-CAD: fix a FIXME, rename the struct curve definition that was embedded into
20:03.50CIA-62BRL-CAD: rt_sketch_internal. this creates a new rt_curve structure and moves the
20:03.50CIA-62BRL-CAD: associated segment structures into rtgeom. unfortunately requires nmg.h for the
20:03.50CIA-62BRL-CAD: knot_vector and cascades a set of name changes, but improvement all around.
20:17.54*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:32.24CIA-62BRL-CAD: 03kunigami * r45819 10/osl/trunk/osl/: add just the empty dir for mime-type testing
20:35.00CIA-62BRL-CAD: 03kunigami * r45820 10/osl/trunk/osl/CHANGES: add just the empty dir for mime-type testing
21:54.45*** join/#brlcad ibot (~ibot@rikers.org)
21:54.46*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
22:05.20CIA-62BRL-CAD: 03brlcad * r45827 10/brlcad/trunk/ (include/raytrace.h src/librt/primitives/sketch/sketch.c): segment magic numbers are presently unsigned long, update pointers accordingly
22:15.48CIA-62BRL-CAD: 03brlcad * r45828 10/brlcad/trunk/src/proc-db/sketch.c: now that mk_sketch() releases memory, we can simplify by creating the sketch and all segments on the stack.
22:19.13CIA-62BRL-CAD: 03kunigami * r45829 10/osl/trunk/oiio/ (399 files in 82 dirs): adding missing files to oiio
22:21.18CIA-62BRL-CAD: 03brlcad * r45830 10/brlcad/trunk/src/proc-db/sketch.c: come to think of it, we don't need ANY stinking dynamic memory allocation. huzzah.
22:25.58CIA-62BRL-CAD: 03brlcad * r45831 10/brlcad/trunk/src/proc-db/sketch.c: reduce some more and document the vars
23:38.46CIA-62BRL-CAD: 03kunigami * r45832 10/osl/trunk/ilmbase/ (245 files in 69 dirs): adding latest stable version of ilmbase, 1.0.1
23:46.50CIA-62BRL-CAD: 03kunigami * r45833 10/osl/trunk/ilmbase/config/Makefile.in: added missing file to ilmbase
23:51.29CIA-62BRL-CAD: 03kunigami * r45834 10/osl/trunk/ilmbase/ (7 files in 7 dirs): added missing file to ilmbase (cant understand why some files are not being added)
IRC log for #brlcad on 20110809

IRC log for #brlcad on 20110809

00:04.54brlcadkunigami: it's because some files are listed in your ~/.subversion/config global-ignores directive, files that are "usually" auto-generated
00:05.25brlcadMakefile.in files being a byproduct of automake, though some projects choose to be autoconf-only and use Makefile.in
00:05.53brlcadremove the directive and should resolve itself
00:06.34kunigamithat's strange, my global-ignores only includes .o, .lo and .la
00:27.45starseekerbrlcad: we've got something odd going on with bu_ipwd
00:27.58starseekerI'm trying to run archer from build directory, and it's not finding the plugins
00:28.31starseekerthe problem traces to how plugins are loaded - the current working directory is changed to being fairly deep in the share structure
00:28.43starseekerwhen there, bu_brlcad_data no longer gives useful results
00:29.38starseekerbrlcad: try running bwish from share/brlcad/7.20.3/plugins/archer/Utility
00:30.05starseekere.g ../../../../../../bin/bwish
00:30.11starseekerthen try bu_brlcad_data ""
00:32.30dlistarseeker, is there any known issue with building brlcad against libpng-1.5?
00:36.19starseekerdli: trunk can (we actually just upgraded to 1.5)
00:36.44dlistarseeker, thanks a lot! just got a bug report from gentoo
00:41.29*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
00:49.44CIA-62BRL-CAD: 03kunigami * r45835 10/osl/trunk/openexr/ (396 files in 67 dirs): adding latest version of openexr (v1.6.1)
01:38.53kunigamiopenexr requires zlib, which is packed with brlcad. but openexr uses autotools to build. should I modify it to automatically find the brlcad version or may I assume that the user will take care of this dependence?
01:48.05brlcadkunigami: that is pretty odd then .. it's in my config (but then I added it)
01:49.18brlcadas for zlib, is there already a configure option for --with-zlib=/path/to/zlib or somesuch?  otherwise the top-level build file can take care of passing it in the build flags
01:49.42kunigamibrlcad: hmm, let me check
01:52.54kunigamithere's no such option. so the idea is that one top-level file builds all osl dependencies?
01:58.16brlcadyeah, something very simple to assist builds on linux/bsd/mac
01:59.12kunigamihm, ok
01:59.16brlcadeither a makefile or a script, whatever is easiest
02:00.54kunigamiI'd go for script. I'm not that fluent with makefiles
02:01.49brlcadstarseeker: data path loading requires either a) that one of the libbu path functions is called prior to a directory change or b) that the resources are in their install location
02:03.03brlcadif both those are false, then there's no way for libbu to know what the initial working directory path was (other than a hard override)
02:11.14CIA-62BRL-CAD: 03bhinesley * r45836 10/brlcad/trunk/src/libged/edit.c:
02:11.15CIA-62BRL-CAD: Batch arguments were expanding, but only the first set was being executed.
02:11.15CIA-62BRL-CAD: Fixing this meant writing a function to duplicate command argument groupings,
02:11.15CIA-62BRL-CAD: which in turn required changing the subcommand functions for looping through
02:11.15CIA-62BRL-CAD: args. The counters needed to be exposed as paramaters, and made non-static...
02:11.15CIA-62BRL-CAD: which should have been done in the first place. Updated the half-dozen or so
02:11.15CIA-62BRL-CAD: places that depended on the old logic.
02:20.19*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
03:04.18CIA-62BRL-CAD: 03bhinesley * r45837 10/brlcad/trunk/src/libged/edit.c: off by one errors introduced r45836
03:09.53starseekerbrlcad: it can't key off the location of the bwish binary?
04:00.49starseekerhmm... may want to re-examine the mechanism being used for plugin loading
04:02.14CIA-62BRL-CAD: 03bhinesley * r45838 10/brlcad/trunk/src/libged/edit.c:
04:02.15CIA-62BRL-CAD: Simplified/removed some things in edit(), and resolved several unrelated issues,
04:02.15CIA-62BRL-CAD: many of which were recently introduced. Translate isn't quite working yet. There
04:02.15CIA-62BRL-CAD: seems to be a problem getting the apparent coordinates of objects, which I think
04:02.15CIA-62BRL-CAD: might all be evaluating to (0,0,0). Also, there are several untested option/arg
04:02.15CIA-62BRL-CAD: combinations.
04:04.31starseekerbrlcad: if the "change to current working directory before doing things" approach is what's causing the break, I wonder if it might be workable to scrap that altogether
04:07.30starseekeror "change the current working directory" rather
04:07.44starseekerdoesn't quite see why that's essential
04:22.16CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3060 10/wiki/User:Bhinesley: /* Log */ today, plan
04:22.46CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3061 10/wiki/User:Bhinesley: /* Log */ typo
04:32.21brlcadstarseeker: why what is/isn't essential?
04:32.42brlcadarcher needing to change the cwd sounds bad
04:33.49brlcadand even if it "needs to" for some odd reason, it should be getting the current dir (via libbu) first so the path can be restored
04:41.28starseekerArcher::pluginLoadCWDFiles
04:42.09starseekerwill try to sort it out tomorrow
05:06.05brlcadyeah, without getting into the nitty gritty, there doesn't sound like there's any reason it needs to load files from "cwd" .. it needs to load files from a plugin dir, determined from bu_brlcad_data "path/to/plugin/dir"
05:46.30*** join/#brlcad blindbox (~UPPnub@60.51.60.209)
06:32.52*** part/#brlcad blindbox (~UPPnub@60.51.60.209)
08:33.16*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:58.26*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
09:56.50*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:32.33abhi2011brlcad: I am working on a new function to be added to librt which will reside in librt/bbox.c
13:32.57abhi2011the function looks like this : rt_bound_dbfullpath(const struct db_full_path *pp, struct rt_i *rtip, fastf_t *tree_min, fastf_t *tree_max)
13:33.31abhi2011so it will take a db_full_path  and return the bb for the combination or region in that path, otherwise return an error
13:38.08abhi2011however for finding the bb a db_full_path is not needed, generall the databse would be opened using rt_dirbuild() which returns a struct rt_i and not struct db_i
13:38.29abhi2011from that point onwards only rt_* functions would be involved
13:39.59abhi2011so I am currently using db_path_to_string() to convert the struct db_full_path passed to rt_bound_dbfullpath(), to a string representation of the path
13:42.04abhi2011I can use this string representation of a region/group to search the list of regions available in the struct rt_i * trip
13:42.27abhi2011once the region  is found then I can use rt_bound_tree() to get the bb
13:43.11abhi2011so my point is that db_path_to_string() seems to be the only way to jump from using db_* functions to rt_* functions
15:33.55brlcadabhi2011: the function shouldn't take an rtip
15:34.19brlcadthat's an implementation detail .. needs to be a simple form of "here's an object, get the bounding box"
15:35.14brlcadeither using db_full_patths or rt_db_internal objects, not immediately clear to me which is better
15:36.42brlcadalso, in general, the database won't necessarily be opened with rt_dirbuild() .. that's only for raytracing applications.  they may simply call db_open() or db_open_inmem() or wdb_dbopen() or ...
15:37.19brlcadthat's one of the points of creating this function, hiding the fact that we create a raytrace context so we can call prep so we can get the bounding boxes
16:12.05CIA-62BRL-CAD: 03brlcad * r45839 10/brlcad/trunk/src/proc-db/csgbrep.cpp: eliminate the remainder of dynamic memory allocation now that it is no longer needed. greatly simplifies creating sketch objects procedurally.
16:31.58CIA-62BRL-CAD: 03brlcad * r45840 10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp: help prevent crashing if the data file cannot be found, validate before trying to use the mapped file. this should be using dsp_get_data() instead of replicating logic.
16:53.07CIA-62BRL-CAD: 03brlcad * r45841 10/brlcad/trunk/TODO: sketch objects get copied deeply now
16:55.38CIA-62BRL-CAD: 03brlcad * r45842 10/brlcad/trunk/TODO: most of the wdb routines now properly make a copy so wdb_export can free it. possibly a few stragglers remaining, but not nmg and sketch previously mentioned.
16:57.12CIA-62BRL-CAD: 03brlcad * r45843 10/brlcad/trunk/src/proc-db/sketch.c: no more dynamic mem
16:57.43abhi2011brlcad: ok I get it.
16:57.52CIA-62BRL-CAD: 03brlcad * r45844 10/brlcad/trunk/src/proc-db/csgbrep.cpp: we already created a db_internal, don't call mk_sketch() directly.
16:59.25abhi2011all the prep functions take an rtip as input however i.e. rt_prep(struct rt_i *rtip) & rt_prep_parallel()
16:59.43brlcadknows that :)
16:59.51abhi2011I am guessing these are the only 2 ways to get the bb
17:00.00brlcadyou need an rtip
17:00.06brlcadthe function, however, does not
17:00.06abhi2011hmm so I would need to convert the input to an rtip
17:00.14brlcadright
17:01.19abhi2011rt_dirbuild() would open up the database and return a rtip, but we dont want the caller to pass the database name as well
17:01.27abhi2011just an object
17:01.30brlcadright
17:01.50brlcadand they might not be a raytracing app, so all they have is a filename and/or a dbip
17:02.20brlcadyou might get away with passing a (struct db_i *, struct rt_db_internal *, min, max)
17:02.46brlcador db_i, name, min, max
17:02.49abhi2011yes i am looking at rt_new_rti() which has db_i
17:02.57abhi2011as input
17:03.25abhi2011yah I am guessing the user will have at a minimum the db_i
17:03.33abhi2011else they wont have a file open :P
17:04.21brlcadthey won't necessarily have a file open
17:04.33brlcadyou can create memory-only database instances
17:04.39abhi2011ah yes right
17:04.48brlcadbut that's still encapsulated in a dsip
17:04.52brlcad*dbip
17:04.55abhi2011both ways, the db_i would exist
17:06.02abhi2011ok I ll proceed assuming that a db_i can be passed by the caller , as of now
17:06.29CIA-62BRL-CAD: 03brlcad * r45845 10/brlcad/trunk/src/external/Unigraphics/ug-g.c: call rt_curve_free() for consistent cleanup
17:17.34*** join/#brlcad ibot (~ibot@rikers.org)
17:17.34*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
17:19.00abhi2011ok, what is an in-mem,  you mean an in memory representation of the comb, which can be prepped ?
17:19.30brlcaddb_open_inmem()
17:19.39brlcadit's a dbip that only lives in memory
17:20.52brlcadyou can create an in-mem dbip, add the struct rt_db_internal * to it, call rt_new_rti() to get an rtip, and finally call rt_gettree() to evaluate the bounding boxes
17:23.26abhi2011ok
17:26.35CIA-62BRL-CAD: 03brlcad * r45846 10/brlcad/trunk/src/conv/dxf/dxf-g.c: free the sketch now that mk_sketch() doesn't
17:27.48abhi2011I see a duplication in 1 thing though
17:28.12abhi2011since db_* functions already provide database manipulation capabilities on disk and in-mem
17:28.38abhi2011is there any need to duplicate it in functions like rt_dir_build()
17:28.40CIA-62BRL-CAD: 03brlcad * r45847 10/brlcad/trunk/src/conv/dxf/dxf-g.c: struct is embedded, can't be null, and rt_curve_free() wants a pointer.
17:29.02abhi2011eg. rt_dir_build() and db_open() both open a database
17:30.07abhi2011but perhaps its because rt_dir_build() opens a on disk database and very conveniently returns a rt_i which can be used further down the raytracing system
17:30.13brlcadrt_dirbuild() calls db_open()
17:30.26abhi2011oh ok
17:31.09brlcadthe goal of dirbuild is to give a raytrace instance, the point of open is to get a database instance .. different (albeit related) purposes
17:31.37abhi2011yes I get understand
17:33.03CIA-62BRL-CAD: 03brlcad * r45848 10/brlcad/trunk/src/conv/shp/shp-g.c: no longer need to allocate dynamic memory for the sketch, keep it on the stack and just free the minimal set of dynamic memory that was needed for the sketch's curve segments.
17:36.49CIA-62BRL-CAD: 03brlcad * r45849 10/brlcad/trunk/src/libged/tire.c: another rt_sketch_internal that no longer needs to be dynamic. release the dynamic data associated with it though, now that mk_sketch() won't
17:42.15abhi2011i was looking at d b _ c r e a t e _ i n m e m() as well and I see that it add a  default _GLOBAL object as well, but what would be the point of adding such an object
17:42.54brlcaddoesn't matter
17:43.18brlcad_GLOBAL holds the working units for the geometry in question
17:43.30abhi2011ok
17:45.47CIA-62BRL-CAD: 03brlcad * r45850 10/brlcad/trunk/src/libged/make.c: enable creation of the old/original sketch object if a LIBGED_MAKE_SKETCH environment variable is set to 1. useful for debugging purposes and makes the code get compiled so it doesn't fall out of sync with the api.
17:52.24abhi2011I was reading about sketches at http://brlcad.org/wiki/Sketch , since I see a lot of code changes going on related to them,  I guess they are simply a line and curve based drawing of a model's shape ?
18:02.10*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
18:04.07brlcadabhi2011: they're autocad-style 2d "drawings"
18:05.17abhi2011ok
18:21.52CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/upload:
18:21.52CIA-62BRL-CAD: uploaded "[[Image:Example sketch.png]]": This is an example sketch that can be
18:21.52CIA-62BRL-CAD: created with the ''make'' command if the LIBGED_MAKE_SKETCH environment variable
18:21.52CIA-62BRL-CAD: is set to 1. This example sketch is primarily used for demonstration and
18:21.52CIA-62BRL-CAD: debugging purposes.
18:28.51CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3063 10/wiki/Sketch: link to the example sketch object image
18:33.11CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3064 10/wiki/SGI_Cube: clean up alignment with
18:35.04CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3065 10/wiki/SGI_Cube: swap images?
18:47.55CIA-62BRL-CAD: 03brlcad * r45851 10/brlcad/trunk/ (include/raytrace.h src/librt/htbl.c): use size_t for hit table indexing
19:03.43*** join/#brlcad ibot (~ibot@rikers.org)
19:03.43*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
19:05.21abhi2011Trying to convert the struct rt_db_internal to bu_external now as wdb_export_external() accepts only bu_external
19:06.32abhi2011some of the primitives  of librt do it
19:06.57abhi2011like rt_ell_export5() in librt/primitives/ell/ell.c
19:12.03abhi2011specifically the htond() and ntohd() seem to do conversions from an external db format bu_external to an internal rt_db_internal
19:21.19brlcadabhi2011: sounds too low-level
19:22.46brlcadwdb_put_internal() and rt_db_put_internal() both work at a higher level
19:22.55abhi2011well I wish there was a wdb_export_external
19:23.02abhi2011*wdb_export_internal
19:23.04abhi2011ah ok
19:23.36brlcadget/put read/write to disk
19:23.54abhi2011yes I need to look through the libwdb functions more carefully :P
19:23.55brlcadimport/export convert from/to serialized (i.e., disk) format
19:24.25brlcadit's understandably complex to fresh eyes :)
19:24.58abhi2011yah the thing is all the functions are there to make life easy, just need to run doxygen once
19:25.39brlcadeven with doxygen, there are a LOT of functions .. so it takes a while
19:25.52abhi2011ok
19:56.59CIA-62BRL-CAD: 03kunigami * r45852 10/osl/trunk/compile.sh: Added a script to build ilmbase and openexr
20:04.42brlcadkunigami: ready for testing?
20:07.06kunigamino
20:07.51kunigamiI'm currently trying to force openexr to use the local version of libz. It's getting from system]
20:10.06brlcadunless that causes a problem, wouldn't worry too much about it
20:11.38kunigamiactually I don't know how to tell openexr where to look if it's not installed on the system :P
20:12.04brlcadmain options are 1) install brlcad, then osl, then reinstall brlcad; or 2) link libz as svn external, then osl, then brlcad; or 3) copy libz, then osl, then brlcad
20:12.44brlcadautoconf supports setting CFLAGS/CXXFLAGS/CPPFLAGS/LDFLAGS during configure, that'd be how
20:13.20brlcad./configure CPPFLAGS=-I/path/to/libz/include LDFLAGS=-L/path/to/libz/libdir
20:14.20kunigamioh ok, great then. (by the way, I didn't understand what you meant in those three options)
20:17.12brlcadin terms of dealing with libz
20:17.18brlcadbasically three options
20:17.45brlcadif you assume brlcad is already compiled/installed (so you can use the libz it compiled), then you'll have to build brl-cad twice
20:18.31kunigamitrue
20:19.06brlcadalternatives are to link in libz sources (svn:external) or svn cp (i.e., fork them in)
20:34.12CIA-62BRL-CAD: 03starseeker * r45853 10/brlcad/trunk/src/ (6 files in 3 dirs): Simplify loading of Archer plugins - use bu_brlcad_data and avoid all the CWD logic. Good cleanup, and plugin loading now works in the build directory.
20:34.40brlcadawesome
20:48.34*** join/#brlcad DarkCalf (DC@173.231.40.98)
21:08.04CIA-62BRL-CAD: 03starseeker * r45854 10/brlcad/trunk/src/libbu/basename.c: Generalize bu_basename with the BU_DIR_SEPARATOR variable
21:09.52CIA-62BRL-CAD: 03starseeker * r45855 10/brlcad/trunk/src/libbu/basename.c: Fix comments
21:12.32brlcadstarseeker: i imagine the bu_basename() change is user-visible in some fashion
21:12.41brlcadpossibly the plugins one too
21:13.11starseekerpossibly... plugins is visible only when running from the build directory (probably why it never got addressed sooner...)
21:13.21starseekeradds NEWS item for basename
21:13.33brlcadyeah, plugins wouldn't be then
21:16.35CIA-62BRL-CAD: 03starseeker * r45856 10/brlcad/trunk/NEWS: Generalized the bu_basename function to work with Windows paths - allows libraries and programs to capture their executable name without path information.
21:18.40brlcadwhich means what to the  user?
21:19.03starseekerbrlcad: not entirely sure.
21:19.09brlcadheh
21:19.25brlcadwhat wasn't working that now is working?
21:19.28starseekerbrlcad: things *might* not work because of that, but we apparently hadn't run into anything
21:23.35*** join/#brlcad saltan (~lieven@d51530284.static.telenet.be)
21:25.37CIA-62BRL-CAD: 03brlcad * r45857 10/brlcad/trunk/NEWS:
21:25.37CIA-62BRL-CAD: how about this. cliff and bob improved mged/archer/bwish run-time behavior on
21:25.37CIA-62BRL-CAD: windows by fixing bu_basename() to work with the windows path separator. this
21:25.37CIA-62BRL-CAD: low-level interface is used for capturing the path to the running executable,
21:25.37CIA-62BRL-CAD: data resources, and more; so fixing the routine should generally make things
21:25.37CIA-62BRL-CAD: better, making apps more consistent for windows users.
21:30.14brlcadprepares a large whoosh commit
21:30.16starseekerthat'll work :-)
21:30.22starseekerducks and hides
21:51.12CIA-62BRL-CAD: 03brlcad * r45858 10/brlcad/trunk/ (88 files in 23 dirs): (log message trimmed)
21:51.12CIA-62BRL-CAD: Convert all BRL-CAD magic numbers to uint32_t. This change affects more than a
21:51.12CIA-62BRL-CAD: dozen structs and more than 500 usages throughout the code including many
21:51.12CIA-62BRL-CAD: function signatures, but is still considered minimally impacting. This
21:51.12CIA-62BRL-CAD: consolidates the slew of int, long, unsigned int, unsigned long, etc definitions
21:51.12CIA-62BRL-CAD: of magic numbers that were assuming to be 4 bytes for magic number validation.
21:51.13CIA-62BRL-CAD: It also exposed a curious book-keeping practice in NMG where pointers to the
21:51.42starseekertests the woosh
21:57.56starseekeryep, seems to work
22:03.13brlcadargh
22:21.49CIA-62BRL-CAD: 03bob1961 * r45859 10/brlcad/trunk/src/libtclcad/tclcadAutoPath.c:
22:21.49CIA-62BRL-CAD: Need to copy result of call to bu_brlcad_root() into local storage before
22:21.49CIA-62BRL-CAD: calling bu_brlcad_data() because bu_brlcad_root() uses static char array and
22:21.49CIA-62BRL-CAD: bu_brlcad_data() calls bu_brlcad_root() overwriting what was previously in the
22:21.49CIA-62BRL-CAD: static array.
22:24.28abhi2011rt_uniresource is often(always) specified with rt_db_put_internal()
22:24.43brlcadit's a global
22:24.47abhi2011I understand that it contains settings for uni processor machines
22:24.56abhi2011yes
22:24.57brlcadsort of
22:25.09abhi2011so what happens for multi cpu machines
22:25.26CIA-62BRL-CAD: 03brlcad * r45860 10/brlcad/trunk/src/librt/ (4 files in 2 dirs):
22:25.26CIA-62BRL-CAD: add a new private header for dsp-implementation use, moving the DSP() macro from
22:25.26CIA-62BRL-CAD: dsp.c to this new dsp.h header so that the brep routine can use the same macro.
22:25.26CIA-62BRL-CAD: remove the dsp_val() debugging wrapper function while we're at it.
22:25.52brlcadit's a "cpu resource" structure used for book-keeping
22:26.11*** join/#brlcad kunigami (~kunigami@201.53.206.27)
22:26.15abhi2011ok
22:26.29brlcadthe rt_uniresource can only be used by one cpu at a time, so it effectively makes that function  single-threaded
22:26.51abhi2011oh ok, some semaphore is present to enable that
22:26.59brlcadmany functions pass resources around, but don't actually do anything with them
22:27.13brlcadothers use the resource structure if they're SMP-aware
22:27.17brlcadlike the ray tracer
22:27.22abhi2011ok
22:27.29brlcadbasically, don't worry about it
22:27.35abhi2011ok :)
22:27.43brlcadif you were passed a resource, then pass it forward
22:27.57brlcadotherwise if you need to call something and don't have a resource, use the rt_uniresource
22:28.17abhi2011ok
22:31.35CIA-62BRL-CAD: 03brlcad * r45861 10/brlcad/trunk/src/librt/primitives/dsp/dsp_brep.cpp:
22:31.35CIA-62BRL-CAD: make the dsp brep implementation use the new private dsp.h header for the DSP()
22:31.35CIA-62BRL-CAD: macro instead of duplicating the code (bad, no donut for you). similarly, there
22:31.35CIA-62BRL-CAD: shouldn't need to be any need to validate the dsp_ip or load it because that
22:31.35CIA-62BRL-CAD: would have already happened during import. redoing that here will just leak
22:31.36CIA-62BRL-CAD: memory and be not as good as what is done during import.
22:36.08CIA-62BRL-CAD: 03starseeker * r45862 10/brlcad/trunk/src/other/tk/CMakeLists.txt: Make sure FREETYPE_LIBRARIES is empty if FREETYPE_FOUND is a no-go.
22:38.40dli/var/tmp/portage/media-gfx/brlcad-7.20.2-r1/work/brlcad-7.20.2/src/libged/png.c:363:38: error: 'Z_BEST_COMPRESSION' undeclared (first use in this function)
22:39.10dlistarseeker, so, 7.20.2 is not compatible with libpng-1.5
22:40.14dlistarseeker, is there a patch to make 7.20.2 build with libpng-1.5?
22:41.15``Erikthat's actually a zlib symbol, one that's been there for a long time :/
22:43.15brlcaddli: suspect that's not the actual first error
22:43.38brlcadprobably preceeded with some failure to find/include zlib.h
22:43.47dlibrlcad, seems to be, I do "make" again, that's the only error
22:44.11brlcadshow the entire output from the compile line on
22:44.33brlcadmake VERBOSE=1 if you're using cmake
22:44.54dlibrlcad, http://pastebin.com/xH38anuF
22:45.05brlcadcan't get to pastebin.com
22:45.26brlcadtry http://paste.ubuntu.com/
22:46.20``Erikgnarly, that really is the first error
22:46.44dlibrlcad, http://paste.ubuntu.com/662232/
22:48.06brlcadso then it's finding some zlib.h that doesn't declare Z_BEST_COMPRESSION
22:50.25dlibrlcad, let me try to build zlib
22:50.27starseekerdli: um.  I suppose I could make a patch...
22:50.36brlcaddli: what does your system zlib.h look like?
22:50.51dlistarseeker, if it's not too much work :(
22:51.39brlcadso far this has little if anything to do with libpng-1.5
22:52.03dlibrlcad, http://paste.pocoo.org/show/455636/
22:52.09``Erikyou fools have 8 minutes until http://www.humblebundle.com is over, if'n ya wanna show your support for linux or osX :)
22:54.53brlcaddli: yeah, that zlib.h definitely defines Z_BEST_COMPRESSION
22:55.08brlcadedit that file and put a #error on the line before Z_BEST_COMPRESSION
22:55.13brlcadsee if it's actually included
22:55.19dlibrlcad, so, it's the building scripts or configure
22:55.37brlcadeither neither?
22:56.12starseekerdli: this is most of it:  http://bzflag.bz/~starseeker/png_patch.diff
22:56.30starseekergiven it's gentoo, I'm assuming you're not using our src/other copies of zlib or libpng?
22:56.42dlistarseeker, thanks
22:57.09brlcadthe error says it's not declared, the source includes zlib.h, zlib.h lists it declared
22:57.15brlcadergo, there is no problem
22:57.23dlistarseeker, no other people, I'm the only one maintaining brlcad in gentoo
22:57.32``Erik2.5 minutes on humblebundle.com O.o
22:58.08brlcadnothing in libpng-1.5 changes Z_BEST_COMPRESSION
22:58.30brlcadso it's still an unknown problem, and libpng update is possibly a big red herring
22:58.33starseekerknows - was just giving him changes he will likely need later.
22:58.58brlcadOH
22:59.13brlcadI'm looking at head .. did 7.20.2 not include zlib.h ?
22:59.19dlistarseeker, why do I still need this patch? http://paste.pocoo.org/show/455638/
22:59.21brlcad(in src/libged/png.c
22:59.47brlcadthat would explain it, lucy
22:59.59dlibrlcad, the svn trunk builds without issue
23:00.04starseekerdli: um... may have something to do with spaces in paths...
23:00.40starseekeror just spaces in general
23:00.42brlcaddli: yeah, that explains it all -- the problem is a simple one-liner header #include missing
23:01.14dlibrlcad, add the header to the c file itself?
23:01.21brlcadhm?
23:01.29starseekerdli: does the patch I posted fix it?
23:01.31brlcad#include "zlib.h"  was missing from that file
23:01.45dlistarseeker, let me try
23:01.54brlcadstarseeker's patch, http://bzflag.bz/~starseeker/png_patch.diff fixes it for the previous release
23:02.13brlcadpng.h must no longer auto-include zlib.h for you
23:04.17CIA-62BRL-CAD: 03brlcad * r45863 10/brlcad/trunk/src/librt/primitives/dsp/dsp.h: prevent crashing if the dsp buffer isn't set yet
23:04.46CIA-62BRL-CAD: 03brlcad * r45864 10/brlcad/trunk/src/proc-db/csgbrep.cpp: initialize all of the dsp fields so we don't crash on export
23:08.01``Erikyup, 1.4 has #include <zlib.h>, 1.5 does not
23:10.22``Erikpng.h indicates that you should pass an actual number and that they may not correlate to the zlib values in the future
23:11.08``Erikline 1646
23:11.45brlcadfunny, their manpage gives an example using Z_BEST_COMPRESSION :)
23:13.06``Erik(does his best wallace shawn voice) docs that're out of date? inconceivable!
23:14.49CIA-62BRL-CAD: 03kunigami * r45865 10/osl/trunk/compile.sh: added oiio compilation. there's an issue with cmake mixing TBB versions (like it does with opengl in brlcad), so by now I just set TBB_USE=0
23:16.43CIA-62BRL-CAD: 03bhinesley * r45866 10/brlcad/trunk/src/libged/edit.c:
23:16.43CIA-62BRL-CAD: Enabled use of bounding box centers of objects as points. Basic object
23:16.43CIA-62BRL-CAD: translations are working "translate -k obj1 -a obj2 obj3", "translate -a obj2
23:16.43CIA-62BRL-CAD: obj1", etc. (redrawing is broken, the objects have to be blasted). It turns out
23:16.43CIA-62BRL-CAD: that getting the natural origin is what is causing the 0,0,0 coordinates;
23:16.44CIA-62BRL-CAD: haven't been able to figure out why. Many things aren't working yet. At least
23:16.44CIA-62BRL-CAD: some translations using reference vectors are working.
23:18.21CIA-62BRL-CAD: 03brlcad * r45867 10/brlcad/trunk/src/librt/primitives/ (20 files in 20 dirs):
23:18.21CIA-62BRL-CAD: make the caller allocate an ON_Brep object, maybe they want to avoid dynamic
23:18.21CIA-62BRL-CAD: memory allocation altogether. this plugs a leak in the csgbrep proc-db and begs
23:18.21CIA-62BRL-CAD: changing the *_brep() param to a simple ON_Brep * instead of a double pointer.
23:19.42brlcadcheers on bhinesley
23:19.55brlcadprogress, :)
23:20.04bhinesleyyes, finally :)
23:21.49bhinesleystill a lot to fix/test
23:22.18bhinesleyfor instance "translate 5 obj1.c" is broken
23:22.20bhinesleyrolls eyes
23:22.31starseekerheh - hang in there
23:22.46starseekerthat "it's all coming together" feeling is a lot of fun
23:25.59bhinesleystarseeker: agreed
23:30.04bhinesleyif I could do one thing differently, I would have used simple linked lists of arguments with flags, instead of a union of subcommand structs of args. That made so much more work and caused so many problems, that it couldn't possibly have been worth it
23:32.56bhinesleythe only 'pro' is that it should make it easier to build subcommand arguments programatically. Create a union, attach a command name, stuff the arguments in the correct elements and go.
23:33.09bhinesleys/Create/declare
23:33.25starseekernods - hindsight is often like that
23:49.32starseekermakes a note to check this out later: http://dgnlib.maptools.org/
IRC log for #brlcad on 20110810

IRC log for #brlcad on 20110810

00:13.34starseekerbhinesley: one question - with the benefit of hindsight, would it be better going forward to switch to a linked list approach (not right now obviously, with gsoc winding up RSN, but in the future)
00:14.43bhinesleyit probably depends on how often we're building commands programatically
00:15.22starseekerlinked lists can also be built programatically though, can't they?
00:16.13starseekerfigures for the editing commands programmatic calling will probably be fairly common...
00:26.36dlistarseeker, brlcad with starseeker's patch, brlcad-7.20.2 builds with libpng-1.5, thanks
00:27.52starseekerdli: np - good to know it fixes it for external libpng as well as our local copy
00:47.57*** join/#brlcad LainIwakuraX (~yuki@d24-57-80-191.home.cgocable.net)
00:49.17bhinesleystarseeker: yes; but it *may* be easier, and/or less error prone for edit() callers to use the structs. (btw, callers can actually still use a linked list if need be, and just run it through edit_<subcmd-name>_add_cl_args() before calling edit()). I decided on the edit_cmd union because it seemed like building args would be more legible, and therefore easier to build: "cmd.translate.ref_vector.from = arg;" rather than "args
00:52.12bhinesleystructs seems more "rigid", as you have a finite number of elements (arguments) that you can add
00:54.21bhinesleyas far as creating new edit subcommands goes, I don't think it makes much of a difference; it requires a couple subcommand-specific functions that would not be required if linked lists were used, but they're ~20 lines and dead simple.
00:58.06bhinesleyit feels like hacking in linked-list behavior, though
01:24.14bhinesleyI can't think of a compelling reason switch to linked lists. I'm open to criticism, though.
03:05.03*** join/#brlcad dli_ (~dli@dsl-173-248-211-69.acanac.net)
03:15.04*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
03:15.05yukonboboh hai
03:27.51CIA-62BRL-CAD: 03brlcad * r45868 10/brlcad/trunk/src/librt/ (db_io.c dir.c): the rt_fwrite_internal/db_fwrite_internal functions are only intended to work with v4 geometry.
03:31.23*** join/#brlcad dli_ (~dli@dsl-69-171-146-13.acanac.net)
03:39.11CIA-62BRL-CAD: 03brlcad * r45869 10/brlcad/trunk/src/proc-db/csgbrep.cpp: relearning how to write an object from nothing
03:39.38CIA-62BRL-CAD: 03brlcad * r45870 10/brlcad/trunk/src/proc-db/csgbrep.cpp: ws
03:40.06CIA-62BRL-CAD: 03brlcad * r45871 10/brlcad/trunk/src/proc-db/csgbrep.cpp: indent
03:43.30CIA-62BRL-CAD: 03brlcad * r45872 10/brlcad/trunk/src/proc-db/ (19 files): ws and indent cleanup
03:52.08yukonbobbefore I dig in: I'm getting a build failure on 7.20.2 (NetBSD, providing some own utilities (ie: tcl/tk/itcl)
03:53.08yukonbobis a warning (treated as error): bitv.c: in function 'bu_hex_to_bitv':
03:53.45yukonbobbitv.c:250: warning: array subscript has type char
03:53.48yukonbob, same for line 255
03:54.05yukonbobhad same error w/ 7.20.0
03:54.20yukonbobknown issue?
03:55.16yukonbobhrmm... macro issue?
03:55.35brlcadyukonbob: not a known issue, just our strict compilation behavior treating a warning as an error
03:55.53yukonbobhey brlcad  :)
03:55.54brlcadyou can disable strict compilation and it'll succeed
03:56.09yukonbobnods. alright :) Onward!
03:57.05brlcadif you try to compile with trunk, a full build log would be useful
03:57.11brlcadso someone can fix the warnings
03:57.43yukonbobwill work incrementally.
03:58.19yukonbob7.20.2 for now... I've got some tcl/tk/itcl integration I'd like to work with somebody on; then bigger fish
03:59.12yukonbobjust svn updated, but has to review tree, got merge conflicts, which is weird, considering I don't edit my local copy.
03:59.51yukonbobre-./configure'd, make'ing.
04:00.36yukonbobbrlcad: autoconf et al still to be first class citizens for foreseeable future?
04:01.51brlcadyukonbob: not really
04:02.01brlcadthe build system is being replaced with the new cmake build system
04:02.05yukonbobok... so cmake transition went well?
04:02.11brlcadfor the most part
04:02.14yukonbobnice.
04:02.22brlcadautotools is going through our deprecation process now
04:02.27yukonbobI like cmake, despite it's problems.
04:02.47yukonbobmy biggest peave is that they didn't use Tcl as the control language, but half-baked their own, but... ;)
04:02.54brlcadhttp://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/doc/deprecation.txt?revision=HEAD
04:03.09brlcadbasically a 3-month minimum to give people a head's up
04:03.29yukonbobnods.
04:03.41yukonbobwell, congratulations on the shift; not a small feat!
04:03.50brlcadstarseeker did all the hard work
04:03.57yukonbobwas just going to ask...
04:04.09yukonbobI know cliff was heads-down in it for a while.
04:04.34yukonbob[incr starseeker]
04:06.21yukonbobdammit
04:06.24CIA-62BRL-CAD: 03brlcad * r45873 10/brlcad/trunk/src/libged/ (dbip.c grid.c nmg_collapse.c): quell the non-%V warnings listed in dli's build log
04:06.28yukonbobnow real macro issues.
04:07.01yukonbobiso C does not permit named variadic macros...
04:07.43yukonbobhrmm. Looks to be from own X11 headers.
04:08.26yukonboboh. nm. /me reads on, sees, is itk.
04:15.40CIA-62BRL-CAD: 03brlcad * r45874 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: looks like this file is not in sync with the sources.. build failure with missing symbol and sure enough the source file isn't being compiled.
04:24.18brlcadbhinesley: ../../../src/libged/edit.c:1226: warning: passing argument 2 of 'ged_path_validate' discards qualifiers from pointer target type
04:25.33brlcadif you can capture another "make -k 2>&1 | tee build.log" .. I can take another pass at squashing any warnings that remain so you can keep strict enabled
04:26.40bhinesleybrlcad: will do
04:27.32brlcadalso,
04:27.33brlcad../../../src/libged/path.c:83: error: conflicting types for 'ged_path_validate'
04:27.33brlcad../../../include/ged.h:1885: error: previous declaration of 'ged_path_validate' was here
04:27.42brlcadperhaps header not checked in
04:27.56bhinesleythat's odd
04:28.13brlcador... maybe I'm not up to date.....
04:28.19brlcadlemme check
04:28.41bhinesleyI did change them in 2 seperate commits
04:30.03brlcadlow and behold, that was the problem for both issues, it's all good
04:30.09brlcadsorry for the bother!
04:30.18bhinesleyoh np
04:39.27CIA-62BRL-CAD: 03brlcad * r45875 10/brlcad/trunk/src/proc-db/csgbrep.cpp: things are way simpler than I was attempting, just call wdb_put_internal()
04:40.29CIA-62BRL-CAD: 03brlcad * r45876 10/brlcad/trunk/src/proc-db/csgbrep.cpp: unused var
04:43.08bhinesleybrlcad: build log: http://paste.pocoo.org/show/455744/
04:48.11CIA-62BRL-CAD: 03brlcad * r45877 10/brlcad/trunk/src/proc-db/csgbrep.cpp:
04:48.11CIA-62BRL-CAD: turns out, wdb_put_internal() has similar delusional notions to the mk_*()
04:48.11CIA-62BRL-CAD: functions assuming memory is dynamic and ready to be released. since we have
04:48.11CIA-62BRL-CAD: stack objects, that's bad. fortunately, it skips the free if idb_meth isn't
04:48.11CIA-62BRL-CAD: set, so try to pull a fast one.
05:00.24CIA-62BRL-CAD: 03brlcad * r45878 10/brlcad/trunk/src/librt/ (db5_io.c wdb.c): prevent crashing if idb_meth isn't set
05:21.38CIA-62BRL-CAD: 03brlcad * r45879 10/brlcad/trunk/src/librt/primitives/ (5 files in 5 dirs): remove debugging print statements, noisy
05:28.04CIA-62BRL-CAD: 03brlcad * r45880 10/brlcad/trunk/src/librt/primitives/pipe/pipe_brep.cpp: shush
05:28.25CIA-62BRL-CAD: 03brlcad * r45881 10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: print 5 in v5 routines, not 4
05:35.41CIA-62BRL-CAD: 03brlcad * r45882 10/brlcad/trunk/src/librt/primitives/ehy/ehy_brep.cpp: unused vars, perhaps wip
05:36.27CIA-62BRL-CAD: 03brlcad * r45883 10/brlcad/trunk/ (include/raytrace.h src/librt/primitives/sketch/sketch.c): more uint32_t magic number fallout
05:50.36CIA-62BRL-CAD: 03brlcad * r45884 10/brlcad/trunk/src/librt/primitives/ (extrude/extrude.c revolve/revolve.c sketch/sketch_brep.cpp): even more magic fallout. highlights the importance of consistently testing magic numbers, particularly where pointers to them are shoved into bu pointer tables and end up with signage issues.
06:02.50CIA-62BRL-CAD: 03brlcad * r45885 10/brlcad/trunk/src/librt/primitives/revolve/revolve_brep.cpp: yep, more
06:07.23yukonbobyay me! successfully built, installing; issues that I recognize from previous installs; conflicts w/ libpng between in-tree and other-installations, need to #include <zlib.h> (will find file), tweak itcl/itk...
06:11.29CIA-62BRL-CAD: 03brlcad * r45886 10/brlcad/trunk/src/librt/primitives/revolve/revolve_brep.cpp: more shushing
06:12.36CIA-62BRL-CAD: 03brlcad * r45887 10/brlcad/trunk/src/proc-db/csgbrep.cpp: and with this, we should now have all primitives getting written out identically in brep and implicit form (export needed the idb_type to be set). dsp is hozered, so disable.
06:13.09*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:29.32brlcadbhinesley: THX!
06:30.22bhinesleynp
06:30.46*** part/#brlcad saltan (~lieven@d51530284.static.telenet.be)
06:46.06CIA-62BRL-CAD: 03bhinesley * r45888 10/brlcad/trunk/src/libged/edit.c: (log message trimmed)
06:46.06CIA-62BRL-CAD: Wrote a function to expand arguments with partial coordinates set, via -x/-y/-z
06:46.06CIA-62BRL-CAD: options (support for this was missing in edit()). Required changes to functions
06:46.06CIA-62BRL-CAD: for getting object coordinates; they now write to any vector they are passed, so
06:46.06CIA-62BRL-CAD: that coordinates may be obtained without modifying the edit_cmd object. Resolved
06:46.06CIA-62BRL-CAD: issue in an argument string parsing function, which was incorrectly pairing
06:46.07CIA-62BRL-CAD: objects with the coordinates that they followed. Had to remove ability to
07:06.27CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3066 10/wiki/User:Bhinesley: /* Log */ today
07:23.16*** join/#brlcad dli (~dli@dsl-69-171-146-13.acanac.net)
09:45.54*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ)
09:46.33*** join/#brlcad d_rossbe1g (~rossberg@BZ.BZFLAG.BZ)
09:47.20abhi2011brlcad: I have been trying to insert a struct rt_db_internal into a directory
09:48.10abhi2011it goes like this : http://bin.cakephp.org/view/73267920
09:48.30abhi2011so I create a in-mem dbip
09:48.58abhi2011and then I create a struct directory by using dp = db_lookup(dbip, ip->idb_meth->ft_name, LOOKUP_NOISY)
09:49.19abhi2011the struct directory is required when using rt_db_put_internal(dp, dbip, ip, &rt_uniresource)
09:49.59abhi2011the db_lookup() is bound to fail however because the dbip it uses has just been created, so its empty
09:50.39abhi2011so is there any other way to create a struct directory *  that can be passed to rt_db_put_internal()
09:54.47abhi2011probably db_diradd() may work
10:34.47*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
11:17.49d_rossbergabhi2011: you have just created the in-memory database, therefore it's empty
11:18.35d_rossbergyou probably need a rt_i* as a parameter
11:19.55abhi2011d_rossberg:  Yes true, however I need top insert a struct rt_db_internal into the dbip before I can make a rt_i* out of it
11:20.05abhi2011<PROTECTED>
11:20.45abhi2011however before I can call rt_new_rti , i need to insert an object (represented by rt_db_internal) into the dbip
11:22.12abhi2011to insert a rt_db_internal  into the dbip, I call rt_db_put_internal(dp, dbip, ip, &rt_uniresource)
11:22.29abhi2011which requires a struct directory *  dp
11:22.47abhi2011its while getting the dp that I run into an issue
11:23.22abhi2011I obviously cannot use db_loopup() because dbip is empty
11:23.32abhi2011yet I need dp :P
11:23.56abhi2011*db_lookup()
11:24.06d_rossbergi'm afraid it's impossible to get the rtip back from a rt_db_internal structure
11:24.49d_rossbergrt_db_internal points to the internal representation of an object
11:24.56abhi2011hmm, my final aim is to calculate the bounding box for the passed rt_db_internal
11:25.07d_rossbergit needs to be castet to the real object type
11:25.13abhi2011oh ok
11:25.31abhi2011so a switch case to detect the object type
11:25.31abhi2011and convert
11:25.31d_rossberglook at rtgeom.h for these types
12:53.39*** join/#brlcad ibot (~ibot@rikers.org)
12:53.39*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
12:55.22CIA-62BRL-CAD: 03brlcad * r45889 10/brlcad/trunk/src/proc-db/csgbrep.cpp: this is v5 geometry, need to set the major_type as well as the minor.
13:00.47abhi2011So I am calling wdb_put_external() using :
13:00.49abhi2011if (wdb_put_internal(dbip->dbi_wdbp, ip->idb_meth->ft_name, &ip, 1.0) < 0)
13:01.05abhi2011I want it to insert an object named sph2.s
13:01.28abhi2011however ip->idb_meth->ft_name point to the ID of the sphere geometry ID_ELL
13:01.46abhi2011I would need the object name here
13:02.08abhi2011There should be some way to extract the object name from the struct rt_db_internal
13:02.21abhi2011I am looking at the fields of idb_meth now
13:03.39abhi2011so instead of wdb_put_internal (wdbp=0x634420, name=0x7fffe98ccdb0 "ID_ELL", ip=0x7fffffffd988, local2mm=1)
13:03.52abhi2011I want to call the function as wdb_put_internal (wdbp=0x634420, name=0x7fffe98ccdb0 "sph2.s", ip=0x7fffffffd988, local2mm=1)
13:06.23CIA-62BRL-CAD: 03brlcad * r45890 10/brlcad/trunk/src/proc-db/csgbrep.cpp: extrude and revolve don't actually need their own sketch objects, reduce
13:09.02tofuabhi2011: look at that file (csgbrep.cpp) .. in there is a little function that shows an rt_db_internal getting added to a database
13:09.47tofuat the rt_db_internal layer, you don't know the name any more, but you don't need to -- so you can just give it any dummy name
13:10.25tofuthe whole point of adding it to a dbip in the first place is just so you can get a proper rtip so you can call dirbuild and/or prep to get the bounding box calculated automatically
13:10.49tofusee the write_out() function
13:12.03abhi2011tofu: thanks!  i suspected the name wouldnt be there anymore and yes i dont need it too
13:12.04tofuthere's also wdb_put_internal() that is even simpler and might work for you (just write_out() couldn't use it)
13:12.22abhi2011ok
13:13.25abhi2011tofu: yes i am using wdb_put_internal (wdbp=0x634420, name=0x7fffe98ccdb0 "ID_ELL", ip=0x7fffffffd988, local2mm=1)  now
13:13.38abhi2011which needs a name to be pased as well
13:13.53abhi2011i could try a dummy of course
13:18.10tofubhinesley: you actually have no more compilation warnings listed in that log, just one bonefide build failure in cursor.c
13:19.41tofubhinesley: something is awry with the termcap.h/term.h/curses.h header detection, so it's not getting a header included that it needs -- if you would, work with starseeker to see what cmake isn't detecting properly as it's not a source code issue but a build system issue
13:30.03CIA-62BRL-CAD: 03brlcad * r45891 10/brlcad/trunk/src/tclscripts/mged/openw.tcl: only attempt to override tk behavior if tk is loaded
13:33.13starseekertofu: I'll take a look at that today - Bob's machine is having a similar issue
13:33.57starseekermildly frustrating - I thought I finally had that sorted - but I'll squash it sooner or later
13:34.35CIA-62BRL-CAD: 03brlcad * r45892 10/brlcad/trunk/src/tclscripts/mged/helpdevel.tcl: supposed to read helplib.tcl, but it doesn't, so simpilfy
13:37.12CIA-62BRL-CAD: 03brlcad * r45893 10/brlcad/trunk/src/tclscripts/mged/help.tcl: try a different way to read in the helplib.tcl file, source it
13:46.05CIA-62BRL-CAD: 03brlcad * r45894 10/brlcad/trunk/src/tclscripts/mged/mged.tcl:
13:46.05CIA-62BRL-CAD: another case where a tk function is curiously being overridden for no apparent
13:46.05CIA-62BRL-CAD: reason. TextInsert was added by gdurf back in 1995 with an empty log message,
13:46.05CIA-62BRL-CAD: so yank it. the current tk version looks similar enough but better.
13:48.44CIA-62BRL-CAD: 03brlcad * r45895 10/brlcad/trunk/src/tclscripts/mged/skt_ed.tcl: don't shadow the dot proc with a value
13:51.16CIA-62BRL-CAD: 03brlcad * r45896 10/brlcad/trunk/src/tclscripts/mged/skt_ed.tcl: remove the Sketch_editor namespace lookalike prefix from a handful of funcs that aren't listed as itcl class methods but are pretending to be them. make them regular procs.
13:53.34CIA-62BRL-CAD: 03brlcad * r45897 10/brlcad/trunk/src/tclscripts/rtwizard/RaytraceWizard.tcl: script isn't always being run as a main application, make sure argv exists
13:55.31CIA-62BRL-CAD: 03brlcad * r45898 10/brlcad/trunk/src/tclscripts/ (cad_dialog.tcl hoc.tcl): make sure the tk namespace exists before trying to set variables in it
14:04.00tofuthat should actually take care of most if not all of the tclscript blather
14:04.12CIA-62BRL-CAD: 03brlcad * r45899 10/brlcad/trunk/src/tclscripts/mged/ (8 files):
14:04.12CIA-62BRL-CAD: this could use some rethinking, but instead of testing to make sure the commands
14:04.12CIA-62BRL-CAD: we need actually exist at 'source' time, see if they exist at run-time. this
14:04.12CIA-62BRL-CAD: should avoid pkgindex blather and be more likely that the command is actually
14:04.12CIA-62BRL-CAD: already loaded.
14:07.37abhi2011csgbrep.cpp seems to be making a model by inserting arbs, ellipses etc using mk_brep()
14:08.55tofuit would seem that way because it is
14:09.15tofuit makes each primitive in implicit and brep/nurbs form
14:09.23tofuirrelevant for what you're doing
14:09.45abhi2011ok but I can use mkprep() to insert rt_db_internal
14:09.47tofuthe point is how it's writing out primitives using an existing rt_db_internal* is very similar to what you're trying to do
14:09.51abhi2011to a wdb
14:09.55tofuno
14:10.04tofuignore mk_*
14:10.10abhi2011ok
14:10.53tofuyou were trying to write an rt_db_internal to an inmem dbip, so you can get an rtip from it
14:10.59abhi2011yes right
14:11.06abhi2011mk_brep writes a boundary repr
14:11.18tofuIGNORE mk_*
14:11.37abhi2011yes ignored :)
14:11.40tofuyou care about the rt_db_internal
14:11.46abhi2011yes
14:11.53tofuread write_out()
14:12.16tofuit's yet another example of writing an rt_db_internal, you might be able to use a similar method
14:12.30tofuyou may also be able to just use wdb_put_internal()
14:13.52abhi2011tofu:  yes I have tried wdb_put_internal(), however it requires a valid name t be passed, a dummy name does not work
14:14.05tofueh?
14:14.29abhi2011well I have tried it like this : wdb_put_internal(dbip->dbi_wdbp, "dummy.s", &ip, 1.0)
14:15.19tofuit doesn't know what is valid/invalid, so if that failed, it's something else
14:15.55tofuin fact, the name you provided isn't dummy at that point -- you're saying "write this ip as dummy.s"
14:16.18tofuwhich is correct -- so if it fails, something is probably either wrong with the wdbp or ip
14:16.21abhi2011yes right
14:17.07abhi2011hmm, I do a valid lookup of the ip using  if ( !rt_db_lookup_internal(dbip, argv[2], &dp, &intern, LOOKUP_NOISY, &rt_uniresource)){
14:18.09tofuso then when you say it "does not work", what do you mean exactly
14:19.18abhi2011well I get a bad pointer error : ERROR: bad pointer 0x7ffff73da148: s/b rt_db_internal(xdbbd867), was Unknown_Magic(x7ffff73da5e0), file /home/abhi/socis/brlcad/src/librt/wdb.c, line 289
14:19.42abhi2011so here is the main program I have got so far to test : http://bin.cakephp.org/view/73267920
14:19.56abhi2011the program tests the new function in librt
14:20.36abhi2011this is the function : http://bin.cakephp.org/view/267477296
14:23.49abhi2011trying to find out if the ip i am passing is somehow in incorrect form :  wdb_put_internal (wdbp=0x634420, name=0x7fffe964745f "dummy.s", ip=0x7fffffffd988, local2mm=1)
14:25.16abhi2011hmm the magick number is wrong
14:26.56abhi2011the struct rt_db_internal probably needs to be properly initialized, just passing a pointer wont do
14:27.35abhi2011i ll try with  RT_DB_INTERNAL_INIT(tmp_internal);
14:30.20abhi2011hmm no , thats not the case, because i pass a valid ip using rt_db_lookup_internal() in the program
14:32.46abhi2011wdb_put_internal() causes bu_badmagic (ptr=0x7fffffffd988, magic=230414439, str=0x7fffe96a4577 "rt_db_internal", file=0x7fffe96a4350 "/home/abhi/socis/brlcad/src/librt/wdb.c", line=289) to be called
14:34.39tofuabhi2011: are you up-to-date with your checkout?
14:35.04abhi2011no I am not , will check out now
14:35.16tofuthere were a lot of magic number changes just yesterday and last night affecting magic numbers, that error looks related
14:35.23abhi2011oh ok
14:35.42abhi2011are magick numbers in a definite range ?
14:35.49tofushould always stay as up-to-date as possible, svn updating throughout the day unless you're at a critical point yourself
14:35.53tofuyes
14:35.58tofuthey're a specific value that is expected
14:35.59abhi2011so I can just look at a number and say this looks wrong
14:36.03abhi2011ok
14:36.29tofus/b means "should be"
14:36.45tofuso it should have had a value of xdbbd867 ... but instead it encountered x7ffff73da5e0
14:37.15tofuwhich just looks like the aforementioned type cast problem that has already been fixed
14:37.34abhi2011oh ok, yah the 7fffff.. thing looks like a virtual memory pointer
14:47.44tofumake sure you're actually passing correct data too, of course, that it really is a valid rt_db_internal
14:50.05abhi2011tofu: yes, I get the rt_db_internal using rt_db_lookup_internal(), which does not return an error
14:50.51CIA-62BRL-CAD: 03n_reed * r45900 10/brlcad/trunk/src/libgcv/wfobj/ (7 files): Removing unused C versions of obj parser sources. They will be out-of-sync with the refactored C++ parser sources.
14:51.44CIA-62BRL-CAD: 03Lighkatwheajec 07http://compilefarm.net * r3067 10/wiki/Main_Page:
15:24.59abhi2011thats strange, I get a seg fault after the latest checkout , during make install
15:25.04abhi2011while Generating ../share/brlcad/7.20.3/db/terra.g
15:26.01abhi2011http://bin.cakephp.org/view/1252572721
15:26.48abhi2011ok I ll probably need to run cmake again as well
15:30.30CIA-62BRL-CAD: 03n_reed * r45901 10/brlcad/trunk/src/libgcv/wfobj/ (obj_parser.h obj_parser.h): Reverted obj_parser.h to last working verion.
15:52.08abhi2011thats wierd I got the same error again
15:52.55abhi2011anyone else getting this error while building the latest version ?
15:53.32abhi2011appears to be related to rt_uniresource  : ../bin/asc2g: Symbol `rt_uniresource' has different size in shared object, consider re-linking
16:11.52tofuabhi2011: you need to fully rebuild
16:15.10brlcadwhatever dependency checking that cmake is doing apparently isn't full proof, make clean and rebuild
16:33.08*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
16:41.24bhinesleystarseeker: at your service; let me know if you need me to do anything for the termcap/term/curses detection issue
17:01.47CIA-62BRL-CAD: 03n_reed * r45902 10/brlcad/trunk/src/libgcv/wfobj/ (7 files): Changing .cc to .cpp. Whitespace and style.
17:04.37*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
17:48.10abhi2011thats strange a did a fresh checkout and a clean rebuild
17:48.23abhi2011brlcad compiled successfully
17:48.45abhi2011and I inserted my function into librt for finding the bounding box
17:49.01abhi2011but I still get an error related to magick numbers
17:49.13abhi2011ERROR: bad pointer 0x7fff838b3c18: s/b rt_db_internal(xdbbd867), was Unknown_Magic(x838b40b0), file /home/abhi/socis/brlcad/src/librt/wdb.c, line 289
17:49.50abhi2011i dont think this is a svn related problem, as I did a fresh build after clearing everything
17:51.09brlcadwhat does your function look like
17:52.40abhi2011brlcad: here it is http://bin.cakephp.org/view/84589638
17:53.37abhi2011this is the test program : http://bin.cakephp.org/view/453281250
17:53.40brlcadI have trouble believing that compiles without warning
17:54.38brlcadlisten to your compiler :)
17:55.17brlcadthe bad point failure is correct from what I see
17:55.23brlcad*pointer
18:03.41abhi2011brlcad: I ll have a look at the warnings again :)
18:09.21abhi2011ah shoot!!, missed that one among the thousand other warnings
18:15.28brlcadyou shouldn't have any warnings in your code....
18:23.07abhi2011by the way, while building brlcad, do you generally enable strict off : cmake ../brlcad -DBRLCAD-ENABLE_STRICT=OFF -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad
18:23.41``Erikleaves it at default strictness
18:24.31abhi2011ok :)
18:25.46bhinesleyabhi2011: We're supposed to leave it on. I'm running gcc 4.6, so it's been necessary for me to disable it while the compiler warnings were being dealt with; but all code should be strict compliant.
18:25.57brlcadstrict would be very useful if we turned it off, the point is to fix the issues reported
18:27.15abhi2011ok, yes I remember turning it off last month when I running on gcc 4.6.0 :P
18:27.55bhinesleyabhi2011: should be close to working now, if not working already
18:28.05abhi2011nice !
18:28.18bhinesleybrlcad has been working 25 hours a day on that
18:28.30bhinesleycracks whip
18:28.36abhi2011yeah I have seen him committing all day !
18:28.42brlcadjumps
18:28.46abhi2011:P
18:29.13abhi2011well lots of commits
18:30.36brlcadabhi2011: if you read the announcements from CIA-62 or join the brlcad-commits mailing list, it's easier to follow developments as they occur so you are aware what's going on and how changes might affect you
18:31.17brlcadthe commits mailing list can be particularly educational if you read through the patches and comments, get more familiar reading code
18:31.50brlcad(and that's true for pretty much any dev and any project that has a commit tracker)
18:31.58abhi2011yes I have been following the CIA-62 announcements, will join the brlcad-commits mailing list
18:32.43brlcadnot just to see "oh, john has been very busy and codes day and night" .. but actually have a pretty good idea of what john is doing and why
18:38.33``Erikone would hope the commit message does that, but the diff is what's really happening
18:44.13CIA-62BRL-CAD: 03Sean 07http://compilefarm.net * r3068 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Lighkatwheajec|Lighkatwheajec]] ([[User talk:Lighkatwheajec|Talk]]); changed back to last version by [[User:Sean|Sean]]
18:44.17CIA-62BRL-CAD: 03Sean 07http://compilefarm.net * r0 10/wiki/Special:Log/block: blocked [[User:Lighkatwheajec]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
18:47.27abhi2011yes, hoping to get commit access soon too :)
19:05.14abhi2011ok I am finally past wdb_put_internal(),  so rt_gettree() must always be called before rt_prep_parallel() , to load the geometry into rtip ?
19:05.46brlcadactually rt_gettree() should be sufficient, iirc
19:05.55abhi2011ok
19:06.07brlcadyou may have the bounding boxes computed by then
19:06.49abhi2011ok, so rt_gettree() gets the tree structure for the passed object name, and attaches it to the rtip list of regions ?
19:07.12abhi2011or probably marks them in rtip  , that this and this will be raytraced in the future
19:08.16``Erikhm, bounding volume info is generated during ft_prep()
19:09.02abhi2011ok, and ft_prep() is probably called only by rt_prep()
19:09.16``Erikyeh (or rt_prep_parallel() )
19:09.20brlcadyou'd think that
19:09.23abhi2011yes
19:09.26brlcadbut iirc, it's not
19:09.43brlcaddon't guess, read the code
19:10.03``Erikthe 3 prims I looked at set st_center and friends in their _prep() funcs, rt_gettrees_muves() doesn't try to call prep on the primitives
19:10.04brlcadI believe you have everything you need after calling gettrees
19:13.08brlcadprior statement true, latter statement not so true
19:16.12brlcadbasically, a slight nomenclature mismatch, always been the case afaicr
19:16.22brlcadrt_prep() and rt_prep_parallel() set up the spatial partitioning and other "preparation" activities
19:16.42brlcadthe actual prep callbacks, however, are called before that during tree loading
19:17.10brlcadwe consider all of that "prep time" when talking about rt, but code-wise, it's a separate step
19:17.40``Erikhuh, yeah, _rt_gettree_leaf() does the ft_prep
19:18.19``Erikguess ya do have the primitive aabb's after rt_gettree(), just not the bvh
19:18.24brlcadthinks he brought a server to its knees
19:18.38``Erikwhile(1)fork(); ?
19:18.48brlcada little more insideous
19:18.53brlcadand unintentional
19:18.55brlcadactual work
19:19.35``Erikg-nmg -a .00001 ? :D I oom'd a 64g box with something similar
19:19.48brlcadnot even that far
19:20.01brlcadthree or four big facetizations and a level 7 sphereflake output
19:20.35``Erikah, our sphflake example is level 3, right?
19:20.41brlcada 0.1, two 0.01, and a default, along with sphflake
19:20.50brlcadsomething around there
19:20.57brlcadI've done a 7 and 8 before
19:21.31brlcadsomething like 100MB for 7, 1GB or so for 8 iirc
19:22.44brlcadcourse, could have been completely coincidental too
19:22.59brlcadbut it's acting like a thrashed pig, a dead one at that
19:25.51``Erikhm, c++ link issues with gcc 4.7, std::list stuff O.o
19:32.10abhi2011ok I am trying to understand the code in tree.c, one thing I can immediately get : there is just one tree for the whole model right ?
19:32.34abhi2011so rt_gettrees() can get nodes from this main tree
19:32.51abhi2011which are the roots from smaller trees
19:33.29abhi2011*for smaller trees I mean
19:33.31brlcad``Erik: I linked with 4.7 just last week
19:34.08brlcadooh, server sprung back to life!
19:34.19``ErikI'm rebuilding with all local libs now, may've been a dep linked against 4.2 (this is on fbsd)
19:34.32brlcadhehe, load in the 50's
19:35.10``Eriksphflake and the tesselations should all be single threaded... did someone do something silly and try to start a java program on it or something? O.o :D
19:35.36CIA-62BRL-CAD: 03bhinesley * r45903 10/brlcad/trunk/src/libged/edit.c: flags for all 3 coordinates supplied in the "[x [y [z]]]" format were being set regardless of whether or not some of the optional coordinates were omitted
19:36.32brlcadprobably memory, all four jobs I had running probably all wanted as much memory as they could get
19:36.58brlcadhm, though top seems to think there's plenty of memory, no swap in use
19:37.09brlcad*shrug*
19:37.37``Erikhttp://paste.lisp.org/display/123942
19:37.49brlcadaha...
19:37.50brlcadProgram terminated with signal SIGKILL, Killed.
19:38.13brlcadsomeone intervened to bring it back to life
19:38.50brlcadapparently facetizing an ehy was sinking the ship
19:39.51brlcad``Erik: at a glance, the GLIBCXX_3.4.15 is suspicious
19:40.19``Erikyeh, considering librt links against /lib/libc.so
19:40.23brlcadgcc 4.7 should have come with a libc update
19:41.13``Erikthat librt links but things using librt don't is also surprising
19:42.09``Erikhasn't really done c++ on gcc, or lately.. was almost all back on msvc1.0 and borland 4.5/5.02
19:44.21kunigamidoes anyone know how to force cmake to find an include path? http://paste.ubuntu.com/662921/
19:47.03``Erikhm, interesting... it links against /usr/local/lib/gcc47/libstdc++.so, then runtime loads /usr/lib/libstdc++.so... might need explicit rpath info
19:47.56brlcador ld_lib path set
19:48.11brlcador /usr/local/lib config'd as a system lib dir before /usr/lib
19:48.17``Erikyeah, my little test program worked when I gave it LD_LIBRARY_PATH
19:48.31``Erikyou mean /usr/local/lib/gcc47? I think /usr/local/lib is already there
19:48.52brlcadright
19:49.52``Erikthat's letting the build continue *shrug* interesting that the rpath info isn't being forced to the 'odd' library
20:00.21CIA-62BRL-CAD: 03brlcad * r45904 10/brlcad/trunk/src/librt/primitives/revolve/revolve.c: revolve doesn't yet implement tessellation, but doesn't mean we should bomb. the NMG_CK checks aren't right since it's this function's job to fill them in.
20:10.16CIA-62BRL-CAD: 03brlcad * r45905 10/brlcad/trunk/ (5 files in 3 dirs): revolve using sk instead of skt like extrude is just asking for trouble. make the two consistent, the same.
20:13.19CIA-62BRL-CAD: 03starseeker * r45906 10/brlcad/trunk/src/other/CMakeLists.txt:
20:13.20CIA-62BRL-CAD: Ah - when doing the local termlib, we have to specify that we are using the
20:13.20CIA-62BRL-CAD: termcap.h header as well. Probably didn't spot this sooner because most systems
20:13.20CIA-62BRL-CAD: had a system termcap.h and the BRLCAD_INCLUDE_FILE test just happened to work as
20:13.20CIA-62BRL-CAD: well.
20:19.47CIA-62BRL-CAD: 03brlcad * r45907 10/brlcad/trunk/src/librt/primitives/sketch/sketch.c: similarly wrong to check them for validity when we're supposed to fill them in
20:20.35CIA-62BRL-CAD: 03brlcad * r45908 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: prevent tessellation from crashing on primitives that don't have a callback set (like sketch)
20:27.29CIA-62BRL-CAD: 03erikgreenwald * r45909 10/brlcad/trunk/src/libged/typein.c: rt_revolve_internals sk is now skt.
20:31.35CIA-62BRL-CAD: 03erikgreenwald * r45910 10/brlcad/trunk/src/libgcv/bottess.c: minor cleanup and reorg
21:15.23abhi2011ok finally got the function working, testing it on regions/combinations and groups now before submitting a patch
21:16.04kunigamimy problem was that cmake searches first on default paths. Adding NO_DEFAULT_PATH solved the problem
21:21.54CIA-62BRL-CAD: 03kunigami * r45911 10/osl/trunk/osl/src/cmake/externalpackages.cmake: modified the way osl searches for external packages. we want it to seach for local libraries (that will be packed and compiled with osl)
21:34.46starseekerbhinesley: does that lastest commit to src/other/CMakelists.txt fix your compile issue?
22:06.52bhinesleyapplauds starseeker
22:07.01bhinesleyworks like a charm
22:08.29bhinesleyThis will be nice. No more grepping through build logs for my warnings.
22:49.43brlcadstarseeker: vtk is the other project that came to mind that had implemented it a long while back
22:50.49brlcadlooking at their docs, it looks like I was confusing their normal scene node sorting
22:51.52brlcadwhich, for what it's worth, is all we'd probably every want anytime soon anyways since depth peeling is relatively-speaking very expensive
22:52.54brlcadbasically cuts performance by about an order .. which may be fine and dandy when your fps would have been 100+ .. but not when it's <1 fps
22:53.08brlcadhttp://www.vtk.org/Wiki/VTK/Depth_Peeling
22:54.57*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
22:55.33brlcadlooks like there was/is a related ogre gsoc project this year
22:56.49``Erikwishes ogre had a decent C interface for FFI O.o
23:00.31abhi2011I am getting a strange error when I try to start Mged, after I shifted BRL-CAD from the default installation location at /usr/brlcad
23:00.49abhi2011its now in /home/abhi/brlcad and is a debug build
23:01.10abhi2011however when mged starts up its not able to find helplib.tcl and so cant start the gui
23:02.44abhi2011I wonder how it knew previously to look in /usr/brlcad/share/brlcad/7.20.3/tclscripts
23:03.25abhi2011there should be a configuration for mged which I am missing i think
23:09.50bhinesleyabhi2011: with a debug build, you can run mged right from the build directory, without installing
23:12.25bhinesleymuch faster compile/dbug cycle that way anyways
23:12.34bhinesley*debug
23:14.14abhi2011bhinesley: I tried that too just now, so I am in brlcad-build, I cd into bin and mged
23:14.20abhi2011but the same error persists
23:14.47bhinesleywhat options are you building with
23:15.18abhi2011cmake ../brlcad -DBRLCAD-ENABLE_STRICT=OFF -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad
23:15.37bhinesleyactually, I'm getting the same error
23:16.01abhi2011is it after a recent checkout ?
23:16.38abhi2011the error is from mged.c
23:16.43bhinesleyyes, recent checkout
23:18.44bhinesleyyeah, it's looking in the wrong directory. changing to /home/bhinesley/brlcad-trunk/build/cmake/share/brlcad/7.20.3/tclscripts/geometree and then running ../../../../../bin/mged works
23:19.44bhinesleysince ../helplib.tcl is correct if the CWD is geomtree
23:20.10abhi2011the cmake changes wouldnt have a effect would it
23:20.30bhinesleyI'm not sure, but it does sound like a job for starseeker
23:20.43bhinesleyputs hand above brow and looks to the clouds
23:20.53abhi2011:)
23:22.41bhinesleystarseeker: archer isn't launching from build dir either: no files matched glob pattern "*.html"
23:23.46abhi2011yes ../../../../../bin/mged works for me too
23:58.13abhi2011brlcad:  can we expect the librt bb function rt_bound_dbfullpath(struct rt_db_internal *ip, point_t *rpp_min, point_t *rpp_max) , to work only on primitives
23:59.10abhi2011or should I expect the user to pass in regions or groups as well, in which I can iterate through the region's or group's constituent primitives
IRC log for #brlcad on 20110811

IRC log for #brlcad on 20110811

00:00.21abhi2011though in my original program, I was detecting a region by passing over the region list in the rtip and checking for name matches
00:03.43abhi2011so to detect the fact that the user has passed a region in a struct rt_db_internal , there should be a field in the struct rt_db_internal that identifies the contents as a region
00:04.47abhi2011or the user would need to pass the model's directory so I can try name matches to detect
00:20.10CIA-62BRL-CAD: 03kunigami * r45912 10/osl/trunk/osl/src/cmake/externalpackages.cmake: force cmake to ilmbase, openexr and llvm in the path os osl/trunk
00:21.32CIA-62BRL-CAD: 03kunigami * r45913 10/osl/trunk/osl/src/testshade/CMakeLists.txt: disable testshade_dso app because it uses an oiio version that is not stable (its not used by brlcad)
00:52.05CIA-62BRL-CAD: 03bhinesley * r45914 10/brlcad/trunk/src/libged/edit.c:
00:52.05CIA-62BRL-CAD: With the improved edit_*_get_arg_head()'s, individual subcommand init functions
00:52.05CIA-62BRL-CAD: are no longer necessary; a generic edit_cmd_init() can handle it all. Reduces
00:52.05CIA-62BRL-CAD: the number of functions needed for each subcommand to 4; nice. Also in this
00:52.05CIA-62BRL-CAD: commit: noticed a variable for a return value being initialized to a literal
00:52.06CIA-62BRL-CAD: value, rather than GED_OK.
01:53.16CIA-62BRL-CAD: 03bhinesley * r45915 10/brlcad/trunk/src/libged/edit.c: regrouping/sorting functions a bit
02:05.14starseekerbhinesley: um.  that's probably the html viewer not finding its stuff
02:05.25starseekerlooks at what mged is up too...
02:06.11bhinesleystarseeker: yeah, it's the one that I wrote :-P
02:06.31starseekercan you see where it's failing?
02:06.37bhinesleyyeah
02:07.05bhinesleyman_browser.tcl:124
02:07.48starseekerwhat's in $path?
02:07.56bhinesleyI'm checking
02:08.01starseekerwill see if he can duplicate the failure, one sec...
02:08.44starseekerregardless, we probably want to add -nocomplain to that glob - that's not a reason for archer to fail to start
02:08.55bhinesleyah there it is; its using the default for the class itself on :68
02:09.17bhinesleystarseeker: true
02:11.26bhinesleyseems the other help browser needs it as well
02:14.33bhinesleyhm, or not.
02:14.47bhinesleyI'm still getting an error, even with -nocomplain
02:17.00CIA-62BRL-CAD: 03starseeker * r45916 10/brlcad/trunk/src/tclscripts/mged/help.tcl: I think we want to get helplib.tcl from the tclscripts dir?
02:18.15starseekerbhinesley: I'm guessing share/brlcad/7.20.3/html doesn't have anything in it?
02:18.59bhinesleythere are folders and files
02:19.05starseekerO.o
02:19.06starseekerweird
02:19.22starseekerwhat does puts $path print out?
02:21.55bhinesleywell it's looking for ./share/brlcad/7.20.3/html/mann/en/
02:22.09starseekerwhich does exist?
02:22.20bhinesleymann doesn't
02:22.34starseekerurm.  that's the problem then
02:32.04CIA-62BRL-CAD: 03starseeker * r45917 10/brlcad/trunk/src/tclscripts/man_browser.tcl: Don't refuse to start archer just because the html docs aren't around.
02:32.22bhinesleywas just about to do that ;)
02:33.28starseekerone remaining wrinkle - when I nuked all of html and then re-ran make, the docs rebuilt but toc.html wasn't present - it's copied during the configure process, not the make process
02:33.49bhinesleymeh... your way looks better anyways
02:33.56starseekerprobably should have the archer help viewer check for that file as well as one of the generated files
02:35.51starseekerwonders reworking the "copy during configure" cases into build rules... wonder if that's practical/worth it...
02:40.52CIA-62BRL-CAD: 03starseeker * r45918 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl:
02:40.52CIA-62BRL-CAD: Check for toc.html as well, since it comes from the configure process and not
02:40.52CIA-62BRL-CAD: the make process in the build directory. May want to consider adding a copy
02:40.52CIA-62BRL-CAD: build rule for things like this so make puts everything back where it belongs,
02:40.52CIA-62BRL-CAD: but not a huge deal since re-running cmake takes care of it.
02:44.15CIA-62BRL-CAD: 03starseeker * r45919 10/brlcad/trunk/NEWS: A bug in Archer's help browser code resulted in Archer failing to start if it was unable to find the html files used for the help system - it now starts even if those files are not present.
02:44.28starseekerok, we should be good to go again
02:44.40starseekerabhi2011: does that fix it for you?
02:45.15starseekerbhinesley: still begs the question of why your mann directory wasn't present
02:45.57bhinesleyI reconfigured and I'm rebuilding... perhaps it is now. Do you periodically reconfigure? I tend to just 'svn update' and make
02:47.15bhinesleyit should trigger a reconfigure if it needs one, right?
02:54.06bhinesleystarseeker: no dice
02:59.11bhinesleyok iiii'm an idiot. BRLCAD-BUILD_EXTRADOCS=OFF
03:01.10bhinesleythat's what I get for using ccmake
03:15.46starseekerbhinesley: yeah, normally cmake is pretty good about reconfiguring/rebuilding when it needs to
03:16.08starseekerearlier case where brlcad had to recommend a clean rebuild was a bit surprising
03:16.56starseekerheh - yeah, if you tell it not to build the html docs it shouldn't :-P
03:17.10bhinesleyimaging that! :)
03:17.14bhinesley*imagine
03:17.31starseekerdid that fix everything?
03:17.37bhinesleyyes
03:17.50bhinesleythank you
03:18.18starseekernp
03:18.30bhinesleylooks like there was no cmake issue?
03:19.13starseekerI didn't see one - looked like just a few tcl file tweaks
03:20.52bhinesleyoh I see it now, help.tcl
03:22.14bhinesleywell, at least it exposed some problems
03:22.52starseekersure - good stuff :-)
03:23.33CIA-62BRL-CAD: 03bhinesley * r45920 10/brlcad/trunk/src/tclscripts/man_browser.tcl: set -nocomplain on glob, just in case; we don't want to fail to start due to some missing files
04:35.47brlcadstarseeker: the earlier clean rebuild case wasn't cmake's fault -- just coincidentally hitting a magic number failure after the magic numbers were converter to uint32_t, but he was passing a bad pointer (so the magic failure was the right thing to do)
04:37.54brlcadabhi2011: they can pass in any object, maybe even non-geometry
04:38.13brlcadnote that the name, rt_bound_dbfullpath(), is no longer right
04:43.55brlcadfinishes organizing the logo submissions
06:43.01CIA-62BRL-CAD: 03bhinesley * r45921 10/brlcad/trunk/src/libged/edit.c:
06:43.01CIA-62BRL-CAD: Now that there are functions to convert path+objects+offsets to coords,
06:43.01CIA-62BRL-CAD: arguments that had to be split into multiple structs (due to -x/-y/-z options)
06:43.01CIA-62BRL-CAD: can be consolidated. It would be slightly more efficient to do this as the
06:43.01CIA-62BRL-CAD: arguments are parsed, but IMO not worth muddying up ged_edit() over.
06:58.41CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3069 10/wiki/User:Bhinesley: /* Log */ today
07:22.18*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
09:14.25CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3070 10/wiki/User:Abhijit: /* Log */
09:42.04abhi2011brlcad: so I would need to find the list of primitives in the region represented by the rt_db_internal
11:02.42abhi2011bhinesley: did the mged and archer launching errors get resolved after the latest checkout
11:13.16CIA-62BRL-CAD: 03kunigami * r45922 10/osl/trunk/boost_1_46_1/: adding latest compatible boost version with osl. doing it by parts
11:14.45CIA-62BRL-CAD: 03kunigami * r45923 10/osl/trunk/boost_1_46_1/boost/: adding latest compatible boost version with osl. part 2
11:38.34abhi2011ok, db_walk_tree() allows a nice set of functions to be provided for accepting and rejecting regions while building a boolean tree of the regions, I will try and use it for adding the primitives of the passed regions to the wdb
11:52.11kunigamihmm just saw that boost has ~ 500MB. should upload it to svn anyway?
11:53.03kunigamiI didn't have to change anything on it from the original version. maybe add a line on the script to download it directly?
12:12.37kunigamillvm is pretty big too ~ 250MB
12:36.21abhi2011kunigami: doesnt boost source already ship with brlcad in src/other/boost
12:42.44abhi2011ok passing a leaf function to db_walk_tree() wont work because its never called even after a missing primitive is detected, was hoping to use the function to add the primitive
13:31.06starseekerabhi2011: mged and archer should launch now
13:52.25abhi2011starseeker: yes its fine now, thanks!
14:01.18*** join/#brlcad kunigami (~kunigami@201.53.206.27)
14:05.50brlcadkunigami: that's a bit large to add, maybe see if you can identify the portion used?  boost has a tool to identify the headers/deps needed so you don't have to download the kitchen sink
14:06.05brlcadllvm can be expected as a system install
14:19.41CIA-62BRL-CAD: 03n_reed * r45924 10/brlcad/trunk/src/libgcv/wfobj/ (5 files): Using more readable names. Removed unused typedefs and some cryptic size checks of questionable utility.
14:36.21*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-068.wlan.tudelft.nl)
15:12.02*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
16:27.57*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-068.wlan.tudelft.nl)
17:20.55*** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
17:58.58*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-068.wlan.tudelft.nl)
18:05.35*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:36.53*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:47.58kunigami1brlcad: ok
18:51.24*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:12.44abhi2011brlcad: currently the librt function for finding the bb works on shapes, but if I pass regions then the db_walk_tree() detects that the shapes of the regions are absent and causes the bounding box to not be calculated
19:13.44abhi2011so I am going to use the code in db_walk_tree() to add primitive leaf nodes when they are detected to be absent, which will involve significant amounts of duplicate code
19:14.56abhi2011so I was wondering if there is an easier way to find and add the primitives to the rt_db_internal representation of a region
19:17.02abhi2011db_walk_tree() allows call backs when a region is started and ended and for leaf nodes, but the leaf node callback is never called if a leaf (primitive) is found to be missing from the model tree
19:40.03CIA-62BRL-CAD: 03starseeker * r45925 10/brlcad/trunk/src/other/incrTcl/itcl/ (4 files in 2 dirs): Take a stab at moving the itcl compilation logic over to the cleaned up logic being used for tcl itself
19:43.56CIA-62BRL-CAD: 03bob1961 * r45926 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
19:43.56CIA-62BRL-CAD: Need to destroy the ray object whenever the ged object is destroyed or when
19:43.56CIA-62BRL-CAD: opening a different database. This fix was prompted by database turds being left
19:43.56CIA-62BRL-CAD: on Windows platforms whenever the ray object was used. That is, the ray object
19:43.56CIA-62BRL-CAD: also has the database copy (i.e. the turd) open and so the code that removes the
19:43.57CIA-62BRL-CAD: database copy fails.
19:49.30brlcadabhi2011: I don't think you can call db_walk_tree .. you don't know the name of the rt_db_internal that you're trying to calculate a bounding box for
20:07.48brlcadat least, you can't call it for that dbi -- you could call it for all of the comb's members to recursively get their bbs
20:08.48brlcadit might be easier to just implement ft_prep for combs
20:10.22CIA-62BRL-CAD: 03starseeker * r45927 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Do as MGED does and default to Navy
20:12.33brlcadabhi2011: aha, I think I have a solution, but it depends on what your code looks like now
20:12.59brlcadsince you DO have it working for primitive, just work on cleaning up the code and make your patch
20:13.47brlcadmake it gracefully fail on combs for now, then once your patch is integrated, can work on bb of comb
20:14.31abhi2011brlcad: hint to the solution :P
20:15.06brlcadif you have an rt_db_internal that is a comb, then you have a union tree pointer
20:15.17abhi2011yes
20:15.22brlcadif you have a union tree pointer, then you can call the other/existing bbox routine, rt_bound_tree()
20:15.53abhi2011ah yes thats the other function i used in my program before too
20:17.05brlcadyou may still need to call rt_gettree/rt_gettrees to load/evaluate the tree, but that's easy
20:17.05abhi2011rt_bound_tree(regp->reg_treetop, reg_min, reg_max)
20:17.31brlcadthat'd only be for regions
20:17.34brlcadyou have combs
20:17.40brlcadcombp->tree
20:17.40abhi2011ah yes
20:17.52brlcadsee rt_comb_internal in raytrace.h
20:18.15abhi2011ok
20:18.26brlcadbasically, implementing much of what _ged_get_obj_bounds() does
20:18.43brlcadjust instead of using db_full_path objects you're using rt_db_internal objects
20:23.30abhi2011ok
20:31.27*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:55.31CIA-62BRL-CAD: 03bob1961 * r45928 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: The backgroundColor routine should be calling ::cadwidgets::Ged::get_rgb_color instead of getRgbColor for consistency.
20:57.16CIA-62BRL-CAD: 03bhinesley * r45929 10/brlcad/trunk/src/libged/edit.c: oops... edit_cmd initialization routine introduced r45921 tried to set pointer that was pointed to by uninitialized pointer to NULL
21:18.00CIA-62BRL-CAD: 03starseeker * r45930 10/brlcad/trunk/src/other/ (7 files in 4 dirs):
21:18.00CIA-62BRL-CAD: Make a stab at itk, probably the trickiest of these extensions. Need to do some
21:18.00CIA-62BRL-CAD: more logic consolidation into tcl.cmake and the src/other CMakeLists.txt
21:18.00CIA-62BRL-CAD: settings probably need some more study (there are a lot of possible cases) but
21:18.00CIA-62BRL-CAD: getting there. Need to study STUBS usage in the standard Tcl/Tk build more and
21:18.01CIA-62BRL-CAD: see if I need some conditionalization logic for those flags...
22:10.31CIA-62BRL-CAD: 03starseeker * r45931 10/brlcad/trunk/src/libbu/progname.c: We need a static buffer here, otherwise our path disappears on us.
22:11.33*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
22:45.45CIA-62BRL-CAD: 03starseeker * r45932 10/brlcad/trunk/src/libbu/progname.c: avoid overwriting the full argv0 path - bu_getprogname was storing its basename in the save variable as argv0's full path information.
IRC log for #brlcad on 20110812

IRC log for #brlcad on 20110812

00:33.03``Erikprogname, eh? O.o I feel like bu_basename is ... wrong... assumes '/' is the path delimiter, which isn't guaranteed
00:34.01``Erikbut I'm recouping from exercise, so'z what do I know
00:34.31``Erik(also assumes that "." means "here")
00:36.32CIA-62BRL-CAD: 03bhinesley * r45933 10/brlcad/trunk/src/libged/edit.c:
00:36.32CIA-62BRL-CAD: Translations to absolute coordinates are mostly working now, id est "translate
00:36.32CIA-62BRL-CAD: 10 20 30 sphere.s". Ommitted coordinates are set to 0 for the time being; will
00:36.32CIA-62BRL-CAD: be enabled once relative positioning is working. Fixed lots of small stuff that
00:36.32CIA-62BRL-CAD: was causing big problems: return variables not being checked properly, vectors
00:36.32CIA-62BRL-CAD: not being initialized, using a ptr where a ptr-to-ptr was needed, etc.
00:36.43``Erik(here are some delimiters, delimited with spaces: / \ : . > )
00:37.45``Erik(here are some parent directory delimiters, for s&g: .. [-] :: / ^ < )
00:38.21``Eriks/delimiters/specifiers/
00:39.13``Erikfinishes drying off and heads out, have a good weekend all :)
00:52.41*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
02:14.37CIA-62BRL-CAD: 03starseeker * r45934 10/brlcad/trunk/CMakeLists.txt: Stay with the release wording.
02:16.26abhi2011patch submitted for new bounding box function in librt using struct rt_db_internal
03:12.04CIA-62BRL-CAD: 03bhinesley * r45935 10/brlcad/trunk/src/libged/edit.c: (log message trimmed)
03:12.04CIA-62BRL-CAD: Relative and absolute translations of single objects is now working, as is using
03:12.04CIA-62BRL-CAD: a default of the bounding box center of objects or option -k to set keypoints.
03:12.04CIA-62BRL-CAD: Objects and numbers are now working for all arguments, as well. Using the
03:12.04CIA-62BRL-CAD: apparent coordinates of objects (i.e. translate -k
03:12.05CIA-62BRL-CAD: a/very/specific/instance/of/shp.s -a 0 17 2.3 shp2.s) is working somewhat, but
03:12.05CIA-62BRL-CAD: is off a bit in many cases. Specifiying coordinates/objects with -x/-y/-z is not
03:15.19bhinesley^--regarding that... I failed to mention that using "obj/shp" vs. "shp" on the objects to translate does work as expected (ala oed)
04:03.23*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
04:28.23CIA-62BRL-CAD: 03brlcad * r45936 10/brlcad/trunk/NEWS: reword to put verb foot forward first, and to remove trailing dash
04:29.08CIA-62BRL-CAD: 03brlcad * r45937 10/brlcad/trunk/NEWS:
04:29.08CIA-62BRL-CAD: reword to put verb foot forward first, and to remove trailing dash; A bug in
04:29.08CIA-62BRL-CAD: Archer's help browser code resulted in Archer failing to start if it was unable
04:29.08CIA-62BRL-CAD: to find the html files used for the help system - it now starts even if those
04:29.08CIA-62BRL-CAD: files are not present.
04:37.20CIA-62BRL-CAD: 03brlcad * r45938 10/brlcad/trunk/ (NEWS src/libged/keep.c): the keep command now saves the sketch associated with a revolve, not just the revolve itself.
04:46.31CIA-62BRL-CAD: 03brlcad * r45939 10/brlcad/trunk/BUGS: revolve is busted?
04:53.25CIA-62BRL-CAD: 03brlcad * r45940 10/brlcad/trunk/ (BUGS TODO): document a few more issues being uncovered by the nurbs testing. tessellation failures (crash and graceful aborts) on rhc and epa hypersensitivity to absolute tolerance.
05:07.36CIA-62BRL-CAD: 03bhinesley * r45941 10/brlcad/trunk/src/libged/edit.c: Tweak behavior of -k/-a/-r translations, per IRC conversation with Sean on June 30, 2011, around 05:45:00 to UTC. Seems to be fully in compliance.
05:26.33CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3071 10/wiki/User:Bhinesley: /* Log */ today
06:46.21brlcad``Erik: er, bu_basename() uses BU_DIR_SEPARATOR now (change made earlier this week while you were sleeping)
08:14.46brlcad*finally* gets the script working (so he thinks) with all the calcs he originally intended: rt perf, rt pixdiff, rtedge pixdiff, rtxray pixdiff, projected area, and volume
10:40.54*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
11:32.00``Erikhuh, did I not svn up? O.o
11:32.29``ErikI looked on my home box to see what kinda stuff starseeker was mucking with, it tends to be horribly out of date :)
11:55.58CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r3072 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */ updated week 12, corrected formatting of week 11
12:32.06``Erikthat's a lot of updated files O.o
12:32.53``Erikif ya'll are calling this a churchville la tolteca day, I'm willing to come visit... otherwise, dayy off, beaches!
12:33.18``Erikgrabs a hedge trimmer and enjoys "vacation" O.o workworkowrk. zubzub.
13:00.35abhi2011Hi, I have seen boolean trees uses many places in the code , like for example one of the parameters of rt_bound_tree() in librt
13:01.05abhi2011I know what a boolean tree is , but I fail to understand how it can be used to represent a region
13:02.11abhi2011I would think a region would be represented by a non-binary tree for example
13:02.42abhi2011with the child nodes being the' unioned' regions or primitives
13:04.24abhi2011a boolean tree would be more useful to represent decision trees for example, but I am probably missing some essential point about the data structure used to represent the model
13:05.51abhi2011I can see that the operation on the constituents nodes like UNION/XOR are kept at the tree root, maybe thats the reason why boolean trees are used
14:43.04CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3073 10/wiki/User:Abhijit: /* Log */
17:00.21*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
17:32.48*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
17:44.57CIA-62BRL-CAD: 03bhinesley * r45942 10/brlcad/trunk/src/libged/edit.c: Check for existence of matp_t before getting vector or applying deltas.
17:47.11*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
18:16.53*** join/#brlcad kunigami_ (~kunigami@201.53.206.27)
19:18.52*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
19:39.07*** join/#brlcad Stattrav_ (~Stattrav@117.192.128.100)
20:02.40*** join/#brlcad dli (~dli@dsl-173-248-243-175.acanac.net)
20:02.50CIA-62BRL-CAD: 03starseeker * r45943 10/brlcad/trunk/misc/CMake/FindTCL.cmake: Do as Tcl does - if Tcl is quiet, so too should Tk be quiet.
20:36.56CIA-62BRL-CAD: 03bhinesley * r45944 10/brlcad/trunk/src/libged/edit.c: Disable error on the use of paths with len > 2. It was checking arguments it shouldn't have been. It may be better off dead anyways; see note in file.
20:38.26brlcadiiiinteresting votes on the logo images
20:38.39CIA-62BRL-CAD: 03bhinesley * r45945 10/brlcad/trunk/src/libged/path.c: reincrement pointer/length when done; otherwise, freeing the path only works intermittently
20:48.34louipchows that going?
20:49.27brlcadit's pretty much done :)
20:49.43brlcadnine judges have voted, four candidates shot to the top of the list
20:57.50brlcadah *whew*
20:58.15brlcadactually thought we had a tie for first ..
20:58.22brlcadbut was error in the maths
20:59.17CIA-62BRL-CAD: 03starseeker * r45946 10/brlcad/trunk/ (6 files in 4 dirs):
20:59.17CIA-62BRL-CAD: Begin a major re-work of the third-party-option-handling logic in CMake, taking
20:59.18CIA-62BRL-CAD: advantage of CMake's ability to constrain variables to particular string values.
20:59.18CIA-62BRL-CAD: This should actually simplify the build logic somewhat in the end, but right now
20:59.18CIA-62BRL-CAD: it's definitely alpha and untested in most configurations.
21:00.00brlcadshaweet, very clear 1st, 2nd, 3rd
21:04.46starseekeroof
21:04.46CIA-62BRL-CAD: 03starseeker * r45947 10/brlcad/trunk/CMakeLists.txt: Cleanup, delete leftover code.
21:06.58CIA-62BRL-CAD: 03starseeker * r45948 10/brlcad/trunk/CMakeLists.txt: Beware cut and paste.
21:08.04CIA-62BRL-CAD: 03starseeker * r45949 10/brlcad/trunk/CMakeLists.txt: ordering consistency
21:09.43CIA-62BRL-CAD: 03starseeker * r45950 10/brlcad/trunk/CMakeLists.txt: mark RPMBUILD_EXEC as advanced
21:11.22CIA-62BRL-CAD: 03bhinesley * r45951 10/brlcad/trunk/src/libged/edit.c: suboptions (-x/-y/-z) were erroneously detected as primary options, triggering a syntax error
21:11.57CIA-62BRL-CAD: 03starseeker * r45952 10/brlcad/trunk/CMakeLists.txt: Stray newline
21:19.58CIA-62BRL-CAD: 03starseeker * r45953 10/brlcad/trunk/configure.cmake.sh: Update configure.cmake.sh to reflect new variables
21:22.02CIA-62BRL-CAD: 03starseeker * r45954 10/brlcad/trunk/ (3 files in 2 dirs): Rename FindTclPackage to more accurately reflect what it's doing these days
21:23.09CIA-62BRL-CAD: 03starseeker * r45955 10/brlcad/trunk/CMakeLists.txt: Fix comment
22:29.40CIA-62BRL-CAD: 03bhinesley * r45956 10/brlcad/trunk/src/libged/edit.c:
22:29.40CIA-62BRL-CAD: Coordinate specification flags are all enabled by default, so a bitwise and is
22:29.40CIA-62BRL-CAD: needed to enable just one. Once that was fixed, they were not being detected as
22:29.40CIA-62BRL-CAD: suboptions; a separate flag was needed for that. ged_edit() is doing the right
22:29.40CIA-62BRL-CAD: thing now, but now it's being picked up as bad syntax somewhere else.
22:34.55CIA-62BRL-CAD: 03starseeker * r45957 10/brlcad/trunk/ (15 files in 14 dirs): Improve handling of extra documentation options - use conditional options keying off of program detection and other options, shorten variable names.
22:36.29CIA-62BRL-CAD: 03starseeker * r45958 10/brlcad/trunk/configure.cmake.sh: Correct configure.cmake.sh
22:37.27starseekerfigures that's enough damage for one day...
23:30.43*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
IRC log for #brlcad on 20110813

IRC log for #brlcad on 20110813

00:15.37abhi2011brlcad: I have modifying the bb function to work on groups and regions : http://bin.cakephp.org/view/1394071764
00:16.32abhi2011I am calling rt_gettree() before rt_bound_tree() to evaluate the tree first
00:17.59abhi2011I am testing with a region made as follows in mged  r part1.r u rcc2.s - sph2.s
00:19.18abhi2011so when traversing the tree in the rt_bound_tree() call , the first call sees the subtraction operator in tp->tr_op and proceeds smoothly down to the left child
00:20.34abhi2011however in the left tree where it should find the primitive rcc2.s, it encounters an unknown op 12, I think it should have encountered a tr_op = OP_SOLID for the rcc.s primitive
00:22.05abhi2011this is probably related to the fact that the rt_gettree() calls reports missing primitives for the region : db_lookup(rcc2.s) failed in /dummy, db_lookup(sph2.s) failed in /dummy,
00:22.07abhi2011rt_gettrees(dummy) warning:  no primitives found
00:24.31abhi2011so probably the missing primitives need to be added to the dbi , before the rt_gettree() call, so that the tree is evaluated properly
00:53.16abhi2011ok, 12 is a OP_DB_LEAF as defined in raytrace.h: line 1177, wonder why rt_bound_tree() cant interpret it
01:23.29starseekerhah, cool:  http://www.pointclouds.org/
01:27.00starseekerwonders if we can feed raytrace points into that and get NURBS back...
01:43.08starseekerbhinesley: curious - how close is your command to being fully functional?
02:09.12CIA-62BRL-CAD: 03starseeker * r45959 10/brlcad/trunk/CMakeLists.txt: Make sure BRLCAD_BUNDLED_LIBS is in the cache
02:31.17CIA-62BRL-CAD: 03starseeker * r45960 10/brlcad/trunk/ (misc/CMake/ThirdParty_TCL.cmake src/other/CMakeLists.txt): Tweaks to get Tcl/Tk package testing going again.
02:34.29bhinesleystarseeker: translate? Quite; I'd say that the "generic" subcommand processing plus the translate command is at 90% at worst. I'd planed on putting in some time this weekend, in the hopes that I will have translate completed, which would imply that generic subcommand processing is done as well. I'm aiming to have 'rotate' done by the end of GSoC; I'm not sure if I can, but that's what I'm shooting for. I highly doubt that I
02:37.13CIA-62BRL-CAD: 03starseeker * r45961 10/brlcad/trunk/CMakeLists.txt: Constrain the CMake dropdown menu options for CMAKE_BUILD_TYPE to Debug and Release
02:48.15bhinesleyrecalculates: more like 95% at worst
02:52.44starseekerbhinesley: cool.  the "recommended" pencil's down date for coding is the 15th, with a week to document what has been done - I was thinking, given the complexity of the command(s) your working on, it might not be a bad idea to start a docbook man page for this sucker - brlcad, what do you think?  should bhinesley keep chugging on the code?
02:53.12starseekercan see arguments both ways, but I really hate to interrupt your momentum on the code
02:53.30starseekerparticularly when it's something like this where having it all "loaded" in your head is important
02:53.37bhinesleyou know, I was actually thinking the same thing earlier today. I would be fine with documenting translate/edit before moving on.
02:53.55starseekerbhinesley: do you have any experience with docbook?
02:53.59bhinesleynone
02:54.02starseekerwinces
02:54.07starseekerurm
02:54.24bhinesleycan't be that bad...
02:54.57starseekerposts that one on the "famous last words" hall of fame...
02:55.11starseekerthe toplevel MGED command is "edit", correct?
02:56.04bhinesleyyes; but ged_edit recognizes the command name being used, and if it is a subcommand, uses it transparently
02:56.14starseekerO.o hmm
02:56.43starseekerbhinesley: keep coding for now - I need to think about how to organize that doc wise
02:57.27bhinesleyI don't know if the edit command itself all that necessary
02:58.10bhinesleywe could hide it behind subcommands, or not hide it... I don't see that it makes any difference
02:58.28bhinesleyunlikely that anyone is going to use "edit translate" when "translate" is available
02:58.36starseekerwould have taken the approach of having a powerful "edit" command, and then have tcl level "wrappers" that translate "rotate" to "edit rotate"
02:58.50starseekernods
03:00.32bhinesleywe could still do that. Right now, there are edit/translate/rotate/scale commands all tied to ged_edit(). We could get rid of translate/rotate/scale, and do it at a TCL level.
03:01.01starseekerwould like to have brlcad's opinion on that one
03:02.07starseekernot a big deal, I'm thinking - and I think you're right that the "man page" level is probably rotate/translate/scale - with perhaps a simpler one for edit showing the full syntax and referencing the individual man pages for each "subcommand" for more details
03:02.26starseekerotherwise edit would be a true monster of a man page
03:02.37bhinesleythat's basically the format I had for the "mock" manual pages in edit.c
03:02.59starseekerwas looking at those - nice work, and I think that will translate fairly cleanly to the docbook system
03:03.47starseekerbhinesley: I guess the thing to do is first make sure translate is solid, and see what brlcad thinks
03:05.37bhinesleyalright. For the record, I tend to agree that translate should be documented before moving on.
03:50.10CIA-62BRL-CAD: 03starseeker * r45962 10/brlcad/trunk/src/other/CMakeLists.txt: Need to flag ITCL_LIBRARY as advanced here too.
04:19.48CIA-62BRL-CAD: 03starseeker * r45963 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake): (log message trimmed)
04:19.48CIA-62BRL-CAD: Use a variation on the three way option trick to get more sophisticated about
04:19.48CIA-62BRL-CAD: turning on/off the optimization flags as a function of CMAKE_BUILD_TYPE - if
04:19.48CIA-62BRL-CAD: Auto, optimization flags are on for Release and off for Debug, but 'hard'
04:19.48CIA-62BRL-CAD: setting BRLCAD_FLAGS_OPTIMIZATION to ON or OFF will override the build-type
04:19.48CIA-62BRL-CAD: based decision. Also, clear the compile flags before we do our thing to
04:19.49CIA-62BRL-CAD: eliminate any flags CMake automatically adds for a given build type - that's why
04:24.36CIA-62BRL-CAD: 03starseeker * r45964 10/brlcad/trunk/CMakeLists.txt:
04:24.36CIA-62BRL-CAD: Go with the most expected/convenient behavior - can't think of a valid case to
04:24.36CIA-62BRL-CAD: install a rel into a dev dir or vice versa, complete and deceptive violation of
04:24.36CIA-62BRL-CAD: convention and more convenient/useful to have the install dir swapped as a
04:24.36CIA-62BRL-CAD: function of build type.
06:14.31CIA-62BRL-CAD: 03starseeker * r45965 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake): Just like the optimization flag, except with the opposite defaults, enable smart autosetting of the debug flags.
06:29.49CIA-62BRL-CAD: 03starseeker * r45966 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): A pattern emerges, time for a macro. CMAKE_BUILD_TYPE aware options.
06:33.26CIA-62BRL-CAD: 03starseeker * r45967 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Don't really need the project name and it's limiting flexibility.
06:54.43CIA-62BRL-CAD: 03starseeker * r45968 10/brlcad/trunk/ (7 files in 7 dirs):
06:54.43CIA-62BRL-CAD: Key the static lib building on the build type. Exposed a problem with making
06:54.43CIA-62BRL-CAD: the trigger variable an OPTION in sub-builds - doing so forces the setting into
06:54.43CIA-62BRL-CAD: the cache and makes it impractical for the AUTO_OPTION macro to do its thing.
06:54.43CIA-62BRL-CAD: Fortunately, the only files doing that were the ones we wrote - corrected them,
06:54.43CIA-62BRL-CAD: and we're good to go.
06:57.26CIA-62BRL-CAD: 03starseeker * r45969 10/brlcad/trunk/CMakeLists.txt: Mark rtgl as advanced. Starting to look fairly clean now, at least on Linux.
07:01.40starseekerbrlcad: hopefully that looks better, need to sleep now
17:46.06CIA-62BRL-CAD: 03starseeker * r45970 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: do some validation on auto_options - probably should at least make these case insensitive, figure out best way to do that later.
17:54.47CIA-62BRL-CAD: 03starseeker * r45971 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: Silly me - use tcl to ensure returning just the highest available package number, no need for bizarre regex foo in CMake.
19:16.34*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
22:35.47kunigamiI used boost bcp to select the necessary headers to compile both osl and oiio. it copied a subset of the library into a separated directory. when building though, it does not generate lib's for libraries such as threads. does anyone have experience on doing this?
IRC log for #brlcad on 20110814

IRC log for #brlcad on 20110814

04:06.36CIA-62BRL-CAD: 03bhinesley * r45972 10/brlcad/trunk/src/libged/edit.c:
04:06.36CIA-62BRL-CAD: Using a single coordinate specifier per argument is now working, i.e. "translate
04:06.36CIA-62BRL-CAD: -k -x ab/abc/sphere.s -a -x ab/def/sphere.s cube.s". Crashes if more than one is
04:06.36CIA-62BRL-CAD: used per -k/-a/-r option. A routine consolidating multiple -x/-y/-z arguments
04:06.36CIA-62BRL-CAD: into an edit_arg is the likely culprint. It was modified to accept a flag
04:06.36CIA-62BRL-CAD: controlling whether to skip consolidation of union edit_cmd common.objects or
04:06.37CIA-62BRL-CAD: not. Several unrelated corrections/comment updates.
04:13.55CIA-62BRL-CAD: 03bhinesley * r45973 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: delete FIXME comments; Cliff said that this is how he'd do it anyways, so I worry about changing it.
04:46.42bhinesley^-- heh, s/I worry/I won't worry/
07:18.58CIA-62BRL-CAD: 03bhinesley * r45974 10/brlcad/trunk/src/libged/edit.c: (log message trimmed)
07:18.58CIA-62BRL-CAD: Initializing cur_arg pointer to wrong value after freeing, resulted in stepping
07:18.58CIA-62BRL-CAD: over two nodes in linked list rather than one. Missing braces for if statements
07:18.58CIA-62BRL-CAD: causing havoc. Attempt to free a shallow copy of a union edit_cmd (wasn't
07:18.58CIA-62BRL-CAD: causing any problems though, since its contents were first replaced with NULL
07:18.59CIA-62BRL-CAD: pointers, which was detected by the freeing function and therefore nothing was
07:19.00CIA-62BRL-CAD: freed). Simplified and clarified a few other small things. Still some problems
07:32.48CIA-62BRL-CAD: 03bhinesley * r45975 10/brlcad/trunk/src/libged/edit.c:
07:32.48CIA-62BRL-CAD: Since target object paths are not checked for fp_len>2 anymore, translate needs
07:32.48CIA-62BRL-CAD: to use the last two directories in path. Remove commented out code that might
07:32.48CIA-62BRL-CAD: have been repurposed to detect argv strings containing >2 directories. It would
07:32.48CIA-62BRL-CAD: be a shame to reduce functionality just to make things marginally more
07:32.49CIA-62BRL-CAD: intuitive.
07:50.48CIA-62BRL-CAD: 03bhinesley * r45976 10/brlcad/trunk/src/libged/edit.c:
07:50.48CIA-62BRL-CAD: Comparing the contents of argument heads with that of common->objects is an
07:50.48CIA-62BRL-CAD: unsure way to end loops involving get_arg_head(). Instead, compare the address
07:50.48CIA-62BRL-CAD: of common->objects with that of the argument heads. This is of greatest
07:50.48CIA-62BRL-CAD: practical significant in batch operations, where it is possible for
07:50.49CIA-62BRL-CAD: common->objects to be NULL, and therefore match the first NULL argument, which
07:50.50CIA-62BRL-CAD: is not necessarily common->objects.
09:10.46CIA-62BRL-CAD: 03bhinesley * r45977 10/brlcad/trunk/src/libged/edit.c:
09:10.47CIA-62BRL-CAD: Specifiying one or more coordinates using the -x/-y/-z options is working. There
09:10.47CIA-62BRL-CAD: were missing parenthesis in several places, a couple conditionals that were
09:10.47CIA-62BRL-CAD: !'ing when they obviously shouldn't, and space for a vector allocated
09:10.47CIA-62BRL-CAD: conditionally when it should have been unconditional. I'll perform more thorough
09:10.47CIA-62BRL-CAD: testing once batch operations are working.
09:18.56CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3074 10/wiki/User:Bhinesley: /* Log */ friday, saturday
09:20.24CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3075 10/wiki/User:Bhinesley: /* Log */ strike off completed item
09:23.55CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3076 10/wiki/User:Bhinesley: /* General plan */ update progress
11:13.18*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:02.24abhi2011I noticed a strange thing in mged, if a shapes is killed while in edit mode and then changes are accepted from the edit menu, then the accept
12:02.25abhi2011tries to apply the changes to a non-existent shape and this crashes mged.
13:26.20*** join/#brlcad plaes (~plaes@gn237.zone.eu)
13:26.52plaesare there any plans to move brlcad repository to git?
13:28.44louipcHeheheh. Haven't heard anything.
13:29.13louipcbrl-cad is huge though. so it might just be better to use svn in this case
13:29.55plaeswell, yeah
13:30.08plaesis using git-svn anyway :)
13:30.19louipccool
13:30.31louipcdo you host your repo?
13:30.45plaesonly on my machine
13:31.22louipcwhat's the point then?
13:32.26plaesjust asking and sort of volunteering... ;)
13:33.31louipchehe better host it and display the wonders of git
13:33.47plaesgithub ^^ :)
13:34.15louipcI really like git too, but it's not for everything
14:35.43brlcadplaes: no such plans
14:37.42brlcadwhen you want to require active instead of passive coordination and centralized development, dvcs just add extra steps with minimal benefits
14:38.16brlcadgit-svn works just fine for those that want to use it
14:43.08*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
16:26.25plaeshum.. cmake doesn't seem  to be checking whether system TNT and JAMA support exists
17:35.10plaeswhen trying to build with system Tcl/Tk, there's a failure during linking
17:35.13plaescmake ^^
17:35.24plaesis this known issue?
18:01.49brlcadplaes: not a known issue
18:02.10brlcadmaybe you can post details (pastebin or sf tracker) with details?
18:02.16brlcader yeah
18:19.01*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
18:23.48*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:27.15plaeshm, ok
18:55.37plaeshttp://paste.pocoo.org/show/458325/
18:56.25plaeswhen linking against itcl, one has to provide the path to that library
18:56.48plaesI assume there are issues like that with other tcl/tk libs as well
18:57.14plaesunfortunately tcl/tk packaging is a mess.. :S
20:03.14CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3077 10/wiki/User:Bhinesley: /* Log */ rephrase
20:48.41*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
21:04.54brlcadplaes: it looks like incrtcl is configured to use a system itcl -- do you have a system libitcl installed?
21:08.03abhi2011brlcad: was wondering if you had a chance to look over the patch I submitted
21:08.34plaes~>
21:08.34ibotsomebody said > was redirection of stdout to a file.
21:09.14brlcadabhi2011: not yet, very busy weekend
21:09.37plaesbrlcad: yes, I have it installed
21:09.41brlcadabhi2011: moreover, once someone does look at it, they generally update the tracker so you know it was reviewed
21:10.05abhi2011:) yes I understand, I am proceeding with the simulate command coding  etc
21:10.37brlcadthat's fine, assuming the patch works perfectly :)
21:11.12*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
21:11.12brlcadif you run into a bug (you mentioned running into something the other day with mged) and find a fix, that'd be another perfect patch case
21:11.36abhi2011cool will look in it
21:11.48abhi2011yeah regarding the bb, having a bit of an issue with regions, but the patch I submitted will detect regions and combinations and gracefully exit
22:28.59CIA-62BRL-CAD: 03bhinesley * r45978 10/brlcad/trunk/src/libged/edit.c: Accepting multiple target objects, and performing batch operations is working. Reflowed and revised some comments, and ran a spellcheck. The only remaining known issue is fixing/enabling option -n.
22:53.53*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
23:00.03abhi2011anyone else getting a cannot find -litcl, cannot find -litk error ?
23:00.08abhi2011when building
23:15.36bhinesleyabhi2011: I just updated; no build errors for me
23:17.25abhi2011ok thats strange, seems its asking looking for system which I have specified during cmake -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON
23:17.33abhi2011*system libs
23:18.26bhinesleyI have that enabled too
23:18.57bhinesleyare you up to date? starseeker recently made some changes relating to Tcl
23:20.02abhi2011yes I just updated , thats when I began getting this error
23:20.40bhinesleythat's odd... you updated from the trunk dir, right?
23:21.02abhi2011yep, as always
23:21.06abhi2011its always worked before
23:21.09bhinesleyhm
23:21.29abhi2011i dont think i need itk-devel or itcl-devel
23:21.52abhi2011the binary libs have been enough to link before this
23:21.56bhinesleyI don't think so either
23:22.20bhinesleydid you say you're running Fedora?
23:22.29abhi2011opensuse 11.4
23:22.35bhinesleyah, someone else then
23:22.51abhi2011yeah it was me, ditched fedora :P
23:23.08bhinesleyoh, hah
23:23.25bhinesleyyeah I haven't been on good terms with it either
23:27.51abhi2011compiler issues ?
23:29.55bhinesleyno
23:30.42bhinesleyI've had to boot to a rescue console at least twice. I run "yum update" and it boots fine again.
23:30.57bhinesleyhad to remove kmod-nvidia
23:31.26bhinesleythere seems to be a lot of not-very-well-tested software that makes it into Fedora stable
23:32.37bhinesleyI'll be back to Debian before long, I'm sure
23:37.04bhinesleys/a rescue console/single user mode
23:39.54abhi2011yeah ubuntu seems pretty stable
23:40.36abhi2011so most of the mged commands work in archer now ?
23:40.56starseekerthe options for enabling everything have changed
23:41.14starseekernow it's -DBRLCAD_BUNDLED_LIBS=Bundled
23:42.22starseekerI'm not sure I can build against a system itcl/itk right at the moment - the 3rd party build logic got the guts ripped out of it and redone, so there's still some shakeout to do
23:42.39bhinesleyabhi2011: most of them were working before I started
23:42.56starseekerwe really really really need to quit using the Itcl/Itk C apis...
23:43.48bhinesleystarseeker: why is that?
23:44.38starseekerit's what complicates building with system tcl/tk vs. bundled tcl/tk so much - I can detect if a system Tcl/Tk has Itcl/Itk installed as a package, but when we're using the C api that's not enough
23:45.23bhinesleyah
23:45.31starseekerI ripped that stuff out once already, but we got some reports that iwidgets wasn't working (I think brlcad got 'em) and it was a problem I have been unable to reproduce
23:45.58starseekerwhich means I can't debug it, and I can change it back until I can - Catch 22
23:47.28starseekerbhinesley, abhi2011: after this latest round of updates, I'd be sure to clear my build dir and start fresh - lots and lots of changes
23:47.54starseekercmake-gui will show you the current layout, if you happen to have the gui version available
23:50.34abhi2011starseeker: ok so would i need to have the sources of  itcl/itk installed ?
23:51.03abhi2011or will enabling everything through -DBRLCAD_BUNDLED_LIBS=Bundled  be enough to build
23:51.39abhi2011hmm, i think it should look at the bundles libs, so the latter should be ok
23:52.05abhi2011yeah, I am doing a fresh build now
23:52.19bhinesleystarseeker: k, thanks
IRC log for #brlcad on 20110815

IRC log for #brlcad on 20110815

00:02.30bhinesleystarseeker: cursor.c errors are back http://paste.pocoo.org/show/458445/
00:24.03bhinesleystarseeker: scratch that, appears to be my fault
00:28.44abhi2011ok I get an error in analyze.c : /home/abhi/socis/brlcad/src/libged/analyze.c:312:5: error: call to function ‘rt_arb_centroid’ without a real prototype
00:29.00bhinesleystarseeker: double scratch that... not my fault
00:29.44abhi2011some more : /home/abhi/socis/brlcad/include/raytrace.h:3354:23: note: ‘rt_arb_centroid’ was declared here
00:30.17abhi2011seems the declaration is not being taken correctly
00:31.02abhi2011bhinseley: your error seems also related to implicit declarations
00:31.57bhinesleynods
00:32.52abhi2011hmm even in track.c its the same thing: error: call to function ‘track_mk_comb’ without a real prototype
01:25.35CIA-62BRL-CAD: 03bhinesley * r45979 10/brlcad/trunk/src/libged/edit.c:
01:25.37CIA-62BRL-CAD: During certain batch translations, objects after the first target object simply
01:25.37CIA-62BRL-CAD: moved to the same location as the first target object. This was due to certain
01:25.37CIA-62BRL-CAD: translation vectors not being recalculated after executing the first
01:25.37CIA-62BRL-CAD: translation. Since information about an argument is lost after the first vector
01:25.37CIA-62BRL-CAD: is calculated, there needs to be a new vector (and therefore struct edit_arg)
01:25.38CIA-62BRL-CAD: for each translation.
01:53.12starseekerbhinesley: can you give me a make VERBOSE=1 with the cursor error?
01:53.55starseekeralso, can you tell me if brlcad_config.h has #define HAVE_TERMCAP_H 1 ?
01:57.13bhinesleythere is no #define HAVE_TERMCAP_H
01:57.19starseekergrowl
01:57.19bhinesleyI'm running make right now
01:57.33starseekerone sec... let me see if I accidentally undid my fix
01:57.48bhinesleyI saw it there
02:01.13CIA-62BRL-CAD: 03starseeker * r45980 10/brlcad/trunk/src/other/CMakeLists.txt: Oops - variables changed, so update conditionals that use them...
02:01.18starseekerbhinesley: give that a shot
02:01.39starseekersigh... the hazards of radical rework
02:04.05bhinesleyrebuilding
02:07.10dlistarseeker, does cmake scripts support system tcl/tk now?
02:07.28dlistarseeker, instead of brlcad local building
02:09.02starseekerdli: it should - testing that now
02:09.28CIA-62BRL-CAD: 03starseeker * r45981 10/brlcad/trunk/src/other/CMakeLists.txt: Be slightly more aggressive with the find_library command for itcl
02:09.56dlistarseeker, great, because gentoo people still don't accept my packages, due to mandatory tcl/tk local building
02:10.09starseekerwinces - yeah, not surprised
02:13.54starseekerdli: still working on local itcl/itk - one second
02:21.23*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:34.08CIA-62BRL-CAD: 03starseeker * r45982 10/brlcad/trunk/src/ (3 files in 3 dirs):
02:34.09CIA-62BRL-CAD: Ah, right. Original CMake logic written assuming package require based Itcl/Itk
02:34.09CIA-62BRL-CAD: usage - when C libs were again necessary, just hacked in quickly. Can't get away
02:34.09CIA-62BRL-CAD: with that anymore, so use variables where appropriate and look for itk C library
02:34.15starseekerdli: give that a shot
02:36.02dlistarseeker, revision 45982
02:36.16dlistarseeker, testing now
02:36.23starseekerthat works for me here with system tcl/tk and itcl/itk - I don't have a system iwidgets, tkhtml, tkpng or tktable
02:36.53starseekerthe raster toolkit, opennurbs and STEP Class Libraries will stay on because we're currently maintaining our own versions of those
02:38.02starseekerdli: also, remember the cmake options have changed a lot - still probably in flux, actually
02:40.35dlistarseeker, this is reported configure options:
02:40.38dlistarseeker, http://pastebin.com/g7dD2VMP
02:41.21starseekerhmm - surprized the optimized release summary option isn't printing
02:41.36starseekeris that a clean configure from a fully updated trunk?
02:41.53starseekerwhat configure options are you passing in?
02:42.37bhinesleystarseeker: builds fine, thanks
02:43.40dlistarseeker, options passed to cmake: http://pastebin.com/h3ELaNfD
02:44.16starseekerdli: ah, let me translate those
02:44.58starseekerdli: will gentoo accept a BRL-CAD build of tkhtml?
02:46.08dlistarseeker, should be fine, since there's no tkhtml package in gentoo yet
02:46.50starseekerthey don't want static libs?
02:48.36dlistarseeker, I think it's ok, but they want to be sure about how libs are used/linked, so, package manager can avoid broken libraries better, package deps better
02:50.34starseekerdli: um - surprised you turned off the example geometry - is that a policy?
02:51.04starseekerwith EXTRADOCS off, the html documentation won't be available
02:51.56dlistarseeker, it's controlled by USE flag: examples
02:52.43dlistarseeker, http://pastebin.com/7ndb9WDQ
02:53.16dlistarseeker, so, USE="doc" will enable extradocs, extradocs_pdf, extradocs_man
02:54.20dlistarseeker, aqua, does brlcad support aqua?
02:54.35starseekerno
02:55.41dlistarseeker, then, it's a mistake
02:58.02starseekerwhat are you specifically setting up with the Gentoo build type?
02:58.22starseekerwe generally have Debug and Release - I haven't tried feeding in something else
02:59.30dlistarseeker, only debug and release, if USE="debug" it's Debug, otherwise Release
02:59.49starseekeryou're passing in CMAKE_BUILD_TYPE=Gentoo though
03:00.25dlistarseeker, it must be from the gentoo default :( need to disable that then
03:00.42starseekerdli: well, it might work - just completely untested
03:01.21starseekerdli: this is closer, given our current state: http://pastebin.mozilla.org/1300959
03:01.31starseekeryou can see what happens with that
03:02.07starseekerI will test with a "nonsense" build type setting and see what happens once...
03:03.29starseekerah, that's why the optimize and debug flags were not set
03:04.15dlistarseeker, I can try to set default build type to Release, then, if USE=Debug, set it to Debug
03:04.44starseekerdli: I wouldn't worry too much about the pdf doc building just yet - if you still want to enable it, the options are BRLCAD_EXTRADOCS_PDF and BRLCAD_EXTRADOCS_PDF_MAN
03:04.54starseekerremember Apache FOP is needed for that
03:05.24starseekerdli: well, a non-standard build type should still do SOMETHING sane
03:05.43starseekerI'm not sure how successful we'd be fighting with the gentoo guys about that
03:06.09dlistarseeker,  BRLCAD_EXTRADOCS_PDF and BRLCAD_EXTRADOCS_PDF_MAN were already in the package script
03:06.40starseekerah, k
03:07.10dlistarseeker, the complete gentoo package (ebuild) for the svn live version: http://paste.pocoo.org/show/458500/
03:10.34CIA-62BRL-CAD: 03starseeker * r45983 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Er, oops - fix default fallback settings for auto_option macro
03:10.55starseekerdli: that should help
03:11.11starseekeror at least, the settings are saner - trying the build now
03:11.58starseekeryeah, this should fall back to the /usr/brlcad path, no optimization and no debug flags by default
03:13.49starseekernote that tcl/tk need to be 8.5 - 8.4 will no longer be enough, IIRC (ttk widgets, among other issues)
03:14.35starseekertnt and jama are headers, and if I'm remembering right we need our local copies
03:14.46starseekershouldn't be a build issue at all
03:15.09starseeker(as far as conflicting with a system install anyway, unless we're copying those into our install tree - I'd need to check.)
03:18.39dlistarseeker, building, let's see how it works out
04:02.55starseekerdli: any luck?
18:08.28*** join/#brlcad ibot (~ibot@rikers.org)
18:08.28*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
18:10.43CIA-62BRL-CAD: 03starseeker * r45990 10/brlcad/trunk/src/archer/archer:
18:10.43CIA-62BRL-CAD: Warn if we appear to be running archer from a non-install directory with an
18:10.43CIA-62BRL-CAD: install already in place - this is the situation where .tcl files will get
18:10.43CIA-62BRL-CAD: pulled from /usr/brlcad/* instead of local copies, which if unnoticed by the
18:10.43CIA-62BRL-CAD: developer makes for some very frustrating troubleshooting (particularly for
18:10.44CIA-62BRL-CAD: those not familiar with bu_brlcad_root's behavior). We have enough information
18:10.45CIA-62BRL-CAD: to spot this situation at runtime, so do it.
18:12.54bhinesleystarseeker: alright. Their verbage was a bit strong/misleading.
18:18.49starseekerbhinesley: they have to write that for borderline cases where a student might be trying to sprint right at the end and shoves so much code at a mentor right before the eval that they *can't* properly evaluate it
18:19.43bhinesleyah
19:06.42kunigami1just wondering: is it feasible to pack boost compressed in the osl code? the 7ziped version has ~40MB
19:07.14starseekerkunigami1: um.  you couldn't extract the parts you need?
19:07.47kunigami1I still can't. I tried with 1.46.1. I'm currently trying with 1.47.0
19:08.24kunigami1I asked in boost dev list, but the guy suggested to me exactly what I did
19:09.32CIA-62BRL-CAD: 03tbrowder2 * r45991 10/brlcad/trunk/sh/conversion.sh: add a SAVE option to keep converted tgm from being deleted
19:12.38CIA-62BRL-CAD: 03tbrowder2 * r45992 10/brlcad/trunk/NEWS: documented change for users
20:22.43*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:30.48*** join/#brlcad merzo (~merzo@137-79-132-95.pool.ukrtel.net)
21:05.07kunigami1good, seems that was a bug with boost 1.46. let me see if oiio and osl compile with this smaller version
21:15.56plaesgotta love git-send-email \o/
21:25.58*** join/#brlcad KimK_ibmlaptop (~kkirwan@209.248.147.2.nw.nuvox.net)
22:08.59CIA-62BRL-CAD: 03starseeker * r45993 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Don't try adding the debug flag manually if it's Xcode - let Xcode itself handle things. Trying it manually caused an options conflict.
22:55.28*** join/#brlcad kunigami (~kunigami@201.53.206.27)
23:03.09CIA-62BRL-CAD: 03starseeker * r45994 10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeBase.itcl: rt isn't always in the path. Use the bu_brlcad_root, rtwizard.
23:07.40CIA-62BRL-CAD: 03starseeker * r45995 10/brlcad/trunk/NEWS:
23:07.40CIA-62BRL-CAD: rtwizard was relying on rt being present in the system path in order to run it
23:07.40CIA-62BRL-CAD: and generate a picture - instead, have it find and use the rt command specific
23:07.40CIA-62BRL-CAD: to its own BRL-CAD release without needing rt to be in the path.
23:15.24*** join/#brlcad merzo (~merzo@250-21-132-95.pool.ukrtel.net)
23:17.12bhinesleyhow do I get the natural origins of primitives?
23:17.20bhinesleycries uncle
23:22.40CIA-62BRL-CAD: 03starseeker * r45996 10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeBase.itcl:
23:22.41CIA-62BRL-CAD: Wow. Apparently the only reason rtwizard wouldn't output png ouput if you
23:22.41CIA-62BRL-CAD: specified a .png extension was due to its regarding the filename as a
23:22.41CIA-62BRL-CAD: framebuffer (-F) target instead of an output file (-o). Literally a one
23:22.41CIA-62BRL-CAD: character fix, and rtwizard will now output png files if given a .png filename.
23:22.57starseekerbhinesley: "natural origins?"
23:23.14bhinesleyyes, that's what brlcad called it
23:23.37bhinesleyas opposed to the bounding box center... he said that there is a natural starting point of primitives
23:23.39starseekeruh.  is that the point that (say) the sed command grabs from a primitive?
23:23.42starseekeroh
23:24.22bhinesleyI'm not sure, I'll have to look at sed
23:24.35starseekerwould suggest checking what sed does
23:24.46starseekerthat'd be my fist step anyway
23:24.50starseekerfirst step even
23:25.08starseeker(probably be shaking a fist at it too, come to think of it...)
23:25.23bhinesleyheh
23:26.10starseekerlook for f_sed in chgview.c in mged
23:26.20bhinesleyok
23:27.23starseekerhmm... that doesn't help much...
23:28.45bhinesleyI guess that's the problem, starseeker; I don't really know what I'm looking for
23:29.06starseekerbhinesley: that's a little outside my expertice also - let me dig a minute
23:29.20bhinesleyalright, thank you
23:33.29starseekeryou might try looking at curr_e_axes_pos being set in edsol.c
23:35.14starseekerah hah!
23:35.23starseekerget_solid_keypoint, edsol.c 9222
23:36.38bhinesleylooking
23:37.09bhinesleylooks promising; I was thinking that it would have to be different for each primitive type
23:37.24bhinesleyretrieving it, I mean
23:38.19starseekerwinces - OK, if that's actually it, the options are 1) make a libged version of that 2) refactor it into per-primitive calls via the functable (a better way but more time-consuming) 3) ask brlcad what to do (the best way but probably the most work :-P)
23:38.44bhinesleyhahaha @3
23:39.30starseekerI'd say start with 1) for now (lord knows we've got lots of logic like that in there that needs cleanup) and see if you can get it to actually work
23:39.57starseekerif that's what we need, then it'll be already isolated from mged and easier to use for the "right thing" refactoring step
23:42.21bhinesleyok, it doesn't sound so bad
23:50.57brlcadstarseeker: regarding r45996, does rtwizard's preview option still work?
23:51.51starseekerI believe so...
23:52.33starseekertests
23:52.50starseekeroh, wait - point
23:52.54starseekerit might not...
23:54.12starseekercrud, yeah no dice
IRC log for #brlcad on 20110816

IRC log for #brlcad on 20110816

00:01.57brlcadbasically it's a double-use variable so you'll have to conditionalize somewhere, even if you split it into two variables
00:02.37brlcadunless you change the logic to always go to a -o output file then pix-fb that file
00:02.54brlcadbut then you'll need rm logic if it's a preview too
00:03.12brlcadnothing at all tricky, but not a one-character fix ;)
00:03.33brlcadOSL solids up from siggraph: http://s2011compilers.org
00:04.13brlcadunfortunately, he pulled the cool images from alice in wonderland and the amazing spider man that showed OSL in production use
00:07.55brlcadbhinesley: heh, either of those options sound fine -- you only need to push the logic up into libged, but if you want to push it further (up into librt or into librt's individual primitives), even better
00:08.55brlcadanytime there is a switch or if table that itemizes primitives, that is a clear indicator of functionality that need to be refactored up into librt
00:09.25brlcadso that is the long-term goal, libged gets that code one step closer so it's still an improvement if that's as far as you take it
00:11.09bhinesleybrlcad: alright. If moving it to libged is supposedly easier, then I should probably do that for now. I don't want to get sidetracked from edit/translate just yet.
00:11.16brlcadplaes: thanks for the patches, will review
00:14.37brlcadkunigami: if it works compressed, just commit it uncompressed then .. the size isn't critical, it just doesn't seem "right" if it's huge huge
00:16.29brlcadbhinesley: as for the "required to stop", you have it spot on -- that's just for the official code tarball that has to be uploaded to google, you dont' have to stop coding in the least
00:17.34brlcadtechnically, you're being paid to "test google upload infrastructure" .. that's how they legally pay students for work that they don't directly evaluate
00:18.04bhinesleybrlcad: interesting
00:18.45brlcadyeah, it's pretty funny
00:19.49brlcadbhinesley: oh and libged is going to be easier because it's almost as simple as move block of code from mged to libged .. whereas to put it into librt properly would require adding a function to each individual primitive
00:20.07brlcadmaybe two hours difference, but more work nonetheless
00:20.18bhinesleyah, I see. the "OOP interface"
00:20.41brlcadnods
00:20.52CIA-62BRL-CAD: 03starseeker * r45997 10/brlcad/trunk/src/tclscripts/rtwizard/lib/ (FbPage.itk PictureTypeBase.itcl): Ah, not quite so simple - the same command feeds both the preview and the file-out operations, so we need to accomidate both.
00:21.30starseekerbrlcad: there we go - both preview and png output
00:22.02brlcadyou left a debug puts ;)
00:23.20starseekerpicky picky... :-P
00:23.40CIA-62BRL-CAD: 03starseeker * r45998 10/brlcad/trunk/src/tclscripts/rtwizard/lib/PictureTypeBase.itcl: remove stray debug output
00:26.47starseekerbrlcad: does rtwizard work on Windows?
00:27.24starseekerprobably shouldn't ask that...
00:28.43starseekerbrlcad: something up with those BU_ASSERT changes you made, by the way...
00:31.27CIA-62BRL-CAD: 03starseeker * r45999 10/brlcad/trunk/NEWS:
00:31.27CIA-62BRL-CAD: rtwizard can output png files now, handing it the same way rt itself does (use
00:31.27CIA-62BRL-CAD: .png as the file name suffix). Was primarly a matter of distinguishing between
00:31.27CIA-62BRL-CAD: framebuffer and file targets - previously the 'file output' was just a
00:31.27CIA-62BRL-CAD: framebuffer dump to a file.
00:32.02CIA-62BRL-CAD: 03bhinesley * r46000 10/brlcad/trunk/src/libged/edit.c: Changing memory allocations for structs to use BU_GETSTRUCT. Simplified/reduced some things. Added some error checking. Nothing major.
00:32.17CIA-62BRL-CAD: 03starseeker * r46001 10/brlcad/trunk/TODO: png in rtwizard, check.
00:32.46brlcadstarseeker: understood -- investigating, they should have been good to go as I was pretty careful but "-1" is a special case
00:33.01starseekerbrlcad: thanks
00:33.03brlcadthat might be what is causing the current problem even, just in a different way
00:33.33brlcadit writes out a -1 to mean "this is an identity matrix, don't write it out"
00:34.35CIA-62BRL-CAD: 03bhinesley * r46002 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am get_solid_kp.c): Migrating edit/edsol.c:get_solid_keypoint() to libged. It compiles cleanly, but is otherwise untested.
00:36.56starseekerbrlcad: how were you figuring to do the temp color thing for rtwizard?
00:39.06brlcadplaes: would like to talk about your libfft patches when you got a sec, questions 1) what's the impact (performance, correctness) using fftw3.. our used to be much faster; 2) configure.ac can't call PKG_* macros and that build system is deprecated anyways, cmake build is where the action is at (which I see you had a separate patch for); 3) again performance check, the fixed size convolutions are highly optimizable .. what's the impact?
00:39.13brlcadstarseeker: options to rt
00:39.42brlcadprobably set variables
00:39.50starseekererm.  don't know that trick
00:40.43brlcadbasically, get it to work with rt first, rtwizard just calls rt
00:40.59starseekernods
00:41.06brlcadrtwizard needs some gui interface to set/unset the colors
00:41.15brlcadbut then those just turn into command line opts
00:41.32starseekerare the rt options already in place to override colors?
00:41.35brlcaddo you know how rtedge options work?  same basic idea
00:42.02brlcadno, they're not -- that's pretty much 90% of the task
00:42.15brlcadthe rtwizard gui part is nothing
00:42.44starseekerright
00:44.08brlcadbhinesley: oof! .. so "moving code" probably wasn't the best term to use
00:44.18brlcadthose globals gotta go
00:44.59brlcadthe statics will need to be non-static since libged is supposed to be stateless
00:45.09brlcadthat may or may not break it
00:45.38brlcadparams should be const that can be const
00:46.15brlcadmged gets away with a lot of shit that isn't tolerated for libged (as that is the entire point of the library, clean refactoring)
00:47.10brlcadfinally, function should be added to ged_private.h (and renamed) so it doesn't accidentally become public libged api
00:48.49bhinesleybrlcad: alright
00:48.56bhinesleystill, I'll see if I can get it working first
00:53.30*** join/#brlcad kanzure (~kanzure@131.252.130.248)
00:53.35*** join/#brlcad piksi (piksi@pi-xi.net)
01:19.46CIA-62BRL-CAD: 03starseeker * r46003 10/brlcad/trunk/ (3 files in 3 dirs): Need to make the FindGL logic match up with the FindX11 logic to make sure the two are in sync. Needs more testing.
01:27.45CIA-62BRL-CAD: 03starseeker * r46004 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake ThirdParty_TCL.cmake): more case correction logic is needed - try this.
02:04.13CIA-62BRL-CAD: 03bhinesley * r46005 10/brlcad/trunk/src/libged/ (ged_private.h get_solid_kp.c): Make compliant with libged standards (rm global/static vars). Declare in ged_private. Temporarily disable support for ARS/BSPLINE, which will require a little more work.
02:05.09CIA-62BRL-CAD: 03bhinesley * r46006 10/brlcad/trunk/src/libged/get_solid_kp.c: remove (temporary) cast to void
02:11.47CIA-62BRL-CAD: 03bhinesley * r46007 10/brlcad/trunk/src/libged/edit.c: Enabled support for using the natural origins of primitives as a reference point.
02:13.18bhinesleystarseeker: Thank you, again, for helping me with that. I doubt that I would have been able to figure that out any time soon.
02:29.07starseekerbhinesley: np - that's what mentors are for :-)
02:29.32starseekerbhinesley: you've got the fun part - turn it into a viable libged function
02:33.20bhinesleystarseeker: well it seems to work just fine. Just need to make ARS/BSPLINE work; they used a couple globals that were set elsewhere. Making mged call the libged version is another matter.
02:35.22brlcadbhinesley: looks much better, nice work :)
02:36.18bhinesleybrlcad: great, thanks!
02:36.51CIA-62BRL-CAD: 03bhinesley * r46008 10/brlcad/trunk/src/libged/edit.c: Yikes; dynamically allocate a character buffer since _ged_get_solid_kp() writes to it.
02:37.24brlcadwhere's that string freed? :)
02:37.38bhinesley... in the code I'm about to write because you said that
02:37.45brlcadheh
02:38.23brlcadalso very minor point, but recommend bu_calloc unless you're in some performance-critical loop
02:38.40bhinesleyokay; why is that?
02:38.49*** part/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
02:38.51brlcadzero-initialized memory
02:39.02bhinesleyright, but why?
02:39.52brlcadin general, zero-initialized memory is much faster at exposing initialization/deinitialization bugs in code
02:40.10bhinesleyah
02:40.26brlcadsome compilers will even make malloc() zero-initialize by default unless you turn on -O# optimization level
02:40.36brlcadfor that same reason
02:41.40brlcadbut the standard doesn't require it, so it's better practice to do it intentionally yourself, then you also have the added benefit that you can test for nullity or 0-values
02:41.53CIA-62BRL-CAD: 03bhinesley * r46009 10/brlcad/trunk/src/libged/edit.c: Forgot to free string.
02:42.03brlcadr46008 leaks memory, btw ;)
02:42.22brlcadand r46009 should make it crash ;)
02:48.26starseekermake a note of these slides - http://www.slideshare.net/ckleclerc/2011-nasa-open-source-summit-david-wheeler
02:49.02CIA-62BRL-CAD: 03bhinesley * r46010 10/brlcad/trunk/src/libged/edit.c: Use *calloc* and *sizeof* like the grown-ups.
02:49.50bhinesleyalright, wth
03:00.11*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
03:00.21starseekerbhinesley: problem?
03:01.11bhinesleyNO. heh. Dumb mistake that I am not able to fix instantly for some reason.
03:02.01brlcadbhinesley: need a hint?
03:02.25bhinesleynah, then I will feel even stupider
03:02.52starseekerbhinesley: you might as well - it saves time, and I need those hints all the time :-P
03:03.02bhinesleysighs
03:03.21bhinesleyAlright. brlcad, is it because I need to use bu_strlcpy?
03:03.25brlcadhow would I know that r42009 will crash?
03:04.35brlcadthat should take you down the rabbit hole
03:05.42brlcaddamn server shut down during my latest nurbs performance testing after about 80% completion .. arf
03:05.53starseekerwinces
03:16.33starseekerbhinesley: try stepping through with a debugger (I'd start with the char *str; line)
03:24.06CIA-62BRL-CAD: 03starseeker * r46011 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Er, oops - normalize, THEN check.
03:24.58brlcadnifty, some oklahoma country music show wants to use our logo contest rules
03:25.21starseekerhah, awesome
03:28.53starseekerbhinesley: focus on why brlcad said 46008 leaks memory
03:31.05starseekerbrlcad: should we revert that BU_ASSERT size_t change for now?  it crashes on my gentoo box too
03:33.06starseekerdli: hah - saw the brlcad-9999 ebuild appear in one of the overlay updates :-)
03:34.35dlistarseeker, still, 7.20.2 cmake version doesn't work
03:34.46dlistarseeker, I mean to build with system tcl/tk
03:35.05starseekerdli: even with the patches to cmake?
03:35.22starseekerwell, presumably 7.20.4 will
03:36.00dlistarseeker, I can remove the 7.20.2 cmake ebuild for the time being
03:36.33brlcadstarseeker: working on the BU_ASSERT now, it should be something obvious
03:36.42brlcads/now/for a lil bit now/
03:37.05starseekerdli: probably simpler
03:37.45starseekera cmake patch would be rather... large at this point :-)
03:38.06louipc:o
03:38.30louipcwho wins the contest by the way?
03:39.18louipcis looking forward to seeing the logos.
03:42.46starseekersweet - bzflag ebuild now updated to 2.4 :-)
03:42.54dlistarseeker, I will ask someone to review the package and update the gentoo main tree
03:47.22CIA-62BRL-CAD: 03bhinesley * r46012 10/brlcad/trunk/src/libged/edit.c: Ptr to string, not pointer to char.
03:48.09CIA-62BRL-CAD: 03bhinesley * r46013 10/brlcad/trunk/src/libged/get_solid_kp.c: Enable BSPLINE support.
04:01.48brlcadbhinesley: that's nfg
04:03.04brlcadstr only needs to be a char*
04:06.07brlcadr46012 technically avoids the crash on free, but doesn't fix the problem -- you were closer with bu_strlcpy() thinking
05:02.40CIA-62BRL-CAD: 03bhinesley * r46014 10/brlcad/trunk/src/libged/edit.c: Don't dynamically allocate string.
05:08.22starseekerbhinesley: doesn't get_solid_keypoint still need to write to str?
05:09.55bhinesleyapparently I don't know what the fuck I'm doing.
05:10.33starseekerbhinesley: stay calm :-)
05:10.54starseekerwe've all made our share of this kind of mistake
05:11.50starseekerdon't give up - think about what brlcad said about 46008 and 46009
05:15.21starseekerbhinesley: sometimes in situations like this it's helpful to make your own isolated C file and just try to get it to do the one thing you're working on
05:22.08plaesbrlcad: awake now
05:22.17plaeslives in UTC+2
05:24.48CIA-62BRL-CAD: 03bhinesley * r46015 10/brlcad/trunk/src/libged/edit.c: keep a copy of original ptr to free
05:39.48plaesbrlcad: fftw - 1) tried benchmarking it, didn't notice much difference (maybe I need some bigger models to test with)
05:41.22plaesfftw - 2) Why cannot it call the PKG_* macros? autoconf works for me..  for cmake the paths to detect fftw and add it to libraries is missing
05:45.04plaesand 3)  fftw chooses different algorithms baased on the size, we had currently only "faster variant for length 256
05:46.10plaesIIRC, it uses faster algorithms for all powerof two sizes
06:41.03CIA-62BRL-CAD: 03bhinesley * r46016 10/brlcad/trunk/src/libged/get_solid_kp.c: Disable BSPLINE again... it's not working
06:46.55CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3078 10/wiki/User:Bhinesley: /* Log */ today
06:51.58*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
07:22.42*** join/#brlcad merzo (~merzo@193.254.217.44)
09:05.16*** join/#brlcad milamber (~devlin@d118-75-70-176.try.wideopenwest.com)
09:18.31*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
12:33.50*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:07.38kunigamibrlcad: the first time I tried uploading the full boost, the commit was interrupted. (I'm almost sure that was not my connection that failed) does sourceforge has some kind of cap?
13:08.58plaesyou want to bundle whole boost library?
13:09.41kunigamithat was not the first idea, but I'm having troubles in selecting only the required subset
13:09.57plaes:S
13:11.58starseekerbhinesley: closer, but you're still passing in str to get_solid_keypoint - you want to pass in the buffer (that's the whole point of mallocing it in the first place)
13:12.15kunigamiI had advances and managed to copy but now I'm stuck with a build error. probably the build scripts were not copied properly. I'll report to boost dev's list
13:13.18starseekerbhinesley: look at other parts of the code that are working with buffers and string assignment
13:13.24CIA-62BRL-CAD: 03kunigami * r46017 10/osl/trunk/boost_1_46_1/: deleting initial boost commits
13:13.31plaesmost of the times bundled libraries cause more damage than they fix.. (security issues, etc..)
13:14.01starseekerplaes: we will use system libs by default in our configuration if they are available
13:14.28starseekerbut if not, we have to be able to fall back on our local versions rather than fail to build
13:14.59plaeswell, boost is quite popular library
13:15.09plaesmost of the distros have it
13:16.05starseekerwindows is often where we end up needing local copies of things
13:16.38plaesyeah, package management in windows sucks :(
13:17.04starseekerthere are other issues too (Tcl/Tk on OSX is not built for X11, which we currently need)
13:18.30starseekerthe linux distros always hate bundling (and generally I agree with them) but in the case of something like BRL-CAD we can't always wait for the system to catch up
13:19.04starseeker(for example, a lot of linux distros will still put tcl/tk 8.4 on by default, which is too old for us now)
13:19.48kunigamiinteresting
13:23.45starseekeror there's the package dli is working on for gentoo - they don't have a tkhtml ebuild, but we're using that now for our doc viewing system
13:24.40plaesyeah, I'm using Gentoo too, though I'm compiling my own
13:25.10plaesah, dli is the one who maintains it
13:25.16starseekeris also a gentoo user
13:26.11plaesdlbtw, I fixed dev-tcl/itk to install itkConfig.sh file ;)
13:27.01dliplaes, but 7.20.2 is still not in main tree, I don't have access to main tree, only the sci-overlay
13:27.29plaesdli: why does it depend explicitly on java?
13:28.30plaesalso, Calculating dependencies - * A file is not listed in the Manifest: '/var/lib/layman/science/media-gfx/brlcad/brlcad-7.20.2-r1.ebuild'
13:29.16dliplaes, the dependency on java is removed already for cmake version :(
13:29.56dliplaes, weird
13:29.57``ErikBRL-CAD does have a JNI interface in src/librtserver that requires the java headers and libraries, and I believe the pdf docs require apache fop which is a java program
13:30.23dliplaes, sorry, my fault, forgot to check git ls-files
13:31.02starseekerwants to build a desktop with one of those new AMD 12 core processors :-)
13:31.43dliplaes, fixed in overlay
13:32.11plaesit works nice, now if you could add java USE flag too ;)
13:32.12dlistarseeker, in 5 years, netbooks will have that many cores :)
13:34.19dliplaes, I will do that, need some time to test it though
13:34.29starseekeris still stuck on two at the moment - house keeps breaking, so minor things like CPU core count take a backseat
13:36.20``Erikpats his 650mhz p3 O.o
13:37.04dli``Erik, I run an amd (athlon-4 k7) 500MHz
13:39.52starseekerif I can't emerge world from scratch in less than a minute the machine isn't powerful enough :-P
13:41.18dlistarseeker, I use ebuild qmerge to testing, so, easier than atomic emerge
13:45.17starseekerdli: cool.  nice work, bty - thanks for the time you're putting in
13:45.34starseekerhas some experience with gentoo integration and knows it ain't so simple
13:46.24starseekersaddles up and heads out
13:54.59plaeswow, you guys can then test my fftw patchset ;)
14:14.10CIA-62BRL-CAD: 03erikgreenwald * r46018 10/brlcad/trunk/include/bu.h: add BU_ASSERT_SSIZE_T
14:14.47CIA-62BRL-CAD: 03erikgreenwald * r46019 10/brlcad/trunk/src/librt/comb/comb.c: Change mi to ssize_t since we store -1 as a magic value and do a < in the assertion.
14:28.42dlistarseeker, JavaVM/jni.h - not found, the icedtea6 jni.h is /opt/icedtea6-bin-1.10.3/include/jni.h
14:56.13kunigamiis there anyway to be warned by subversion when I'm adding a file which does match any pattern on config file?
14:57.04kunigamiCurrently, it causes error when I'm already commiting and this way I have to reverse
14:57.16kunigami*revert
14:58.09kunigami(I'm referring to those mime types)
15:00.38``Eriktypically, it'll complain that you need to set the svn:mime-type and svn:eol-style
15:01.22kunigamiyup, but I'd like it to complain when I'm adding the files, not when committing.
15:25.16bhinesleystarseeker: _ged_get_solid_keypoint takes a char**. It changes what *str points to. That's one of the reasons why it was crashing when I attempted to free. There really is not point in allocating space; it never writes to it.
15:27.30bhinesley_get_get_solid_keypoint does things like *str = "V";, which was throwing me off. (*str = "V") != ((*str)[0] = 'V')
15:29.13bhinesleyso, silly enough, my first commit with "char *str = "V";" actually worked just fine
15:35.29brlcadright, as long as you don't try to free(str) or write to str, but you could pass &str to a char ** argument and repoint str to something else
15:36.32bhinesleythat's what I ended up doing when I realized that the pointer had changed
15:36.36brlcadplaes: computing a fft is a pretty quick operation these days so you'd probably want to perform a 256x256 convolution a few million times in a loop, compare before/after
15:37.33brlcadplaes: PKG macros are only available if pkg_config is installed, which isn't for many platforms our autotools build supports, but then like I said -- that build system is going away completely in a few months in favor of cmake
15:39.09abhi2011I have a question about setting up commands in mged, so if a command is to be run through a tcl procedure, then I guess it should not have a entry in the table in mged/setup.c
15:40.07abhi2011setting up a tcl script in tclscripts/mged should be sufficient, and this should avoid any conflicts with the setup.c mechanism of running commands ?
15:41.40bhinesleyabhi2011: meaning a purely Tcl command?
15:41.41*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
15:41.57brlcadkunigami: not sure about getting svn to warn when it *doesn't* match a pattern.. though it's not clear what error you'd run into that begs a revert -- if it aborts saying mime types aren't set, you can just set the mimetypes and try again until they're all set
15:42.26abhi2011bhinseley: no the logic for the command is in a c file and I have been running it so far using an entry in setup.c
15:42.39abhi2011so its not a pure tcl command
15:43.03abhi2011what I want is to call the command multiple times from a tclscript
15:43.07brlcadplaes: java is not required, it just builds a jni binding library if it's detected .. if an ebuild specified it as required, that could be simplified/removed
15:44.15kunigamibrlcad: I need to add an entry to .subversion/conf when it gives an error. But this will only make effect if I revert and add the file again. The reason I'm complaining is that if I'm adding to much code, it takes a lot of time before raising an error. I'm writing a simple script by now
15:44.20brlcadbhinesley: what about just removing the parameter altogether?
15:44.38brlcadif you don't use it, it's just overhead logic that will fall out of sync
15:45.15brlcadabhi2011: you shouldn't need to do anything in tclscripts/mged
15:45.42brlcadyou can call it multiple times from a tclscript already
15:46.20brlcadif you just want to avoid typing a test proc many times over, put your logic into a .tcl file and "source file.tcl" to run that proc
15:46.39brlcadcalling the command in a loop in order to get interactive updating is not the final form of the command
15:46.48brlcadit's just a short-term workaround
15:47.06*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
15:47.33bhinesleybrlcad: I could; it would remove a lot of functionality, since we'd only be able to get one type of point. I'm not sure how it would affect getting the coordinates of a BSPLINE/ARS; I haven't been able to get them to work yet in the first place
15:47.53bhinesleyso if I am personally not using it, it should be removed?
15:48.19brlcadbspline is going to be deprecated/removed so a non-issue there
15:48.38bhinesleyok, I'll remove that
15:48.40abhi2011oh ok, I thought the user would invoke a single command from mged , and then a tclscript corresponding to the command would run to update the position at each step (with the libged command running 1 step each time)
15:48.52brlcadars just needs to define a point, perhaps the first point .. which it would have had to do anyways for sed
15:49.29brlcadabhi2011: no, soonish, the libged command will run all N time steps.. the tcl script is just so you can see updates in the meantime
15:49.45brlcadgetting interactive updating *while* a command is running is going to require a minor modification
15:49.53bhinesleybrlcad: it relied on 3 globals (es_ars_crv, es_ars_col, es_pt), which I do not know how to set
15:49.59abhi2011brlcad: ok I understand
15:50.37starseekerhmm... get solid keypoint apparently allows to select vertex or height.
15:51.16starseekeror the A/B/C points for sph/ell
15:52.08starseekerdo we actually use that ability?
15:53.05brlcadbhinesley: quick glance through the code, those are set depending on the editing mode
15:53.22brlcadlemme see if it's obvious how the default is set
15:53.25bhinesleystarseeker: addressing me? well, it would be neat to incorporate the use of those points into edit.c, but would make for some even more daunting syntax. As it is, no, I do not use.
15:54.06starseekerbhinesley: more thinking out loud - the ability is in the code, but if we make no use of it it can be removed
15:54.17starseekerdefault looks like it might be edsol.c:2565
15:55.32bhinesleystarseeker: case ID_ARS doesn't use the string to select which point
15:56.01bhinesleyit uses es_ars_crv and es_ars_col, which are both set to -1 in edsol.c (?)
15:56.59brlcadbhinesley: keep in mind that the logic will forever exist in svn (and in mged until it's removed/refactored), so unless you're aiming for the long term proper refactoring (i.e. librt prims) .. you should simplify to just what you need
15:57.45bhinesleybrlcad: no problem
15:58.08brlcadstarseeker: if you're right, then it looks like you can't push an ARS
15:58.31brlcadso using the first point or average of all ars points would be perfectly adequate
15:58.50bhinesleyI've got to step out for a bit, bbl
15:58.55brlcadcya
15:59.00brlcadhits road
16:00.48brlcadhm, cmake build not catching warnings being spit out by atools build
16:01.05starseekeram I missing some flags?
16:01.28brlcadbhinesley: mixing decls and code in edit.c, have to put all decls at the top of a scope for c90 compliance
17:12.22bhinesleybrlcad: ah yes, assuming you're referring to the calloc, I was testing and forgot to move that back
17:23.58CIA-62BRL-CAD: 03bhinesley * r46020 10/brlcad/trunk/src/libged/edit.c: Don't mix decls and code.
17:25.20bhinesleybrlcad: saw what you meant.
17:25.29plaesbrlcad: did you see my answer to your fftw3 questions?
17:32.57*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
17:34.32brlcadplaes: yes, and I responded back  :)
17:35.37plaesah, didn't scroll up too much
17:36.05plaess/too/that
17:36.07brlcad<PROTECTED>
17:36.46plaeswhoa, cool
17:36.48bhinesleybrlcad: neat
17:37.18brlcadyou can add your own custom keywords to hilight too, but your nick is a default
17:37.35starseeker<PROTECTED>
17:37.44starseekeris that irssi specific
17:37.53brlcadhelps to leave off the leading space there starseeker ... :)
17:37.59starseekernods
17:38.14brlcadthat is a client command, but lots of irc clients support it
17:38.28starseekersweet
17:38.29bhinesleysaw a student in #gsoc send his /nickserv ident command
17:38.38bhinesley...with hundreds in the room
17:38.39starseekerheh - oops
17:38.44brlcadyeah, happens, then hilarity ensues
17:38.49*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
17:51.32*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
18:05.47louipclike password changing :P
18:15.31*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
18:22.05CIA-62BRL-CAD: 03brlcad * r46021 10/brlcad/trunk/src/proc-db/: ignore ringworld
18:25.39CIA-62BRL-CAD: 03bhinesley * r46022 10/brlcad/trunk/src/libged/ (edit.c ged_private.h get_solid_kp.c): Removed **strp parameter of _ged_get_solid_keypoint(), and updated arguments in edit.c. Temporarily disable certain primitive types that we're not yet calculating the keypoint of.
18:31.58starseekerblinks - apparently all ars does is tessellate itself and then call bot routines
18:34.16brlcadyeah, it was the quick and dirty way back in the day when it was being implemented
18:34.20brlcadsomeone completely intending to go back and improve on it some day
18:35.05brlcadprime example why you shouldn't half-ass anything, that crap lives on much longer that the dev that contributed it
18:35.28CIA-62BRL-CAD: 03starseeker * r46023 10/brlcad/trunk/src/librt/primitives/ars/ars.c: Been commented out for a long time, svn's got our back if we need it - outta here.
18:35.40brlcadif it's worth doing, do it while it's in context and we'll all waste a little less time
18:36.07brlcadars is really just a useful input type, describes geometry using waterlines
18:37.39brlcadshould be a nice smooth surface, or at least an option like dsp for faceted linear interpolation in addition to smooth
19:10.41CIA-62BRL-CAD: 03bhinesley * r46024 10/brlcad/trunk/src/libged/get_solid_kp.c: Enable retrieval of natural origin of PIPE and ARBN. Hard coded in a tolerance in ARBN for acceptable distance from point to plane, used in calculating origin.
19:11.21bhinesleyI am assuming it is unacceptible to hard code in a tolerance (as in r46024). Where should I get it from?
19:11.21CIA-62BRL-CAD: 03brlcad * r46025 10/brlcad/trunk/src/other/libpng/Makefile.am: add depends rule, support for 1.7, source our m4 dir
19:14.20bhinesleyI should mention that in the original file, it was set via mged_tol.dist
19:16.51brlcadbhinesley: the gedp has a ged_wdbp member that holds tolerance settings for the current database
19:17.09bhinesleyoh, cool
19:18.09brlcadsee rt_wdb in raytrace.h (and the respective tolerance structs in libbn)
19:21.21CIA-62BRL-CAD: 03bhinesley * r46026 10/brlcad/trunk/src/libged/get_solid_kp.c: get tolerance from db
19:23.45abhi2011brlcad: I have modifying the bb function to work on groups and regions : http://bin.cakephp.org/view/1394071764
19:24.01abhi2011I am calling rt_gettree() before rt_bound_tree() to evaluate the tree first
19:26.17brlcadabhi2011: excellent!
19:26.19brlcadthat's looking better
19:26.47brlcadprobably don't need the if (combp->region_flag) conditional if you're going to do the same to both if/else cases
19:27.23abhi2011ah yes, but I am not sure if both regions and groups will require the same treatment
19:27.29abhi2011I am testing with a region made as follows in mged  r part1.r u rcc2.s - sph2.s
19:27.31brlcadthey will :)
19:27.36brlcadregions are combs
19:27.41abhi2011yes right
19:27.49abhi2011yes ok
19:27.54brlcad:)
19:28.00abhi2011well , the thing is  when traversing the tree in the rt_bound_tree() call , the first call sees the subtraction operator in tp->tr_op and proceeds smoothly down to the left child
19:28.14abhi2011however in the left tree where it should find the primitive rcc2.s, it encounters an unknown op 12, I think it should have encountered a tr_op = OP_SOLID for the rcc.s primitive
19:28.28abhi2011this is probably related to the fact that the rt_gettree() calls reports missing primitives for the region : db_lookup(rcc2.s) failed in /dummy, db_lookup(sph2.s) failed in /dummy,
19:28.59brlcadyeah, that's exactly why
19:29.08brlcadyou need more than just the comb put into the inmem
19:29.26abhi2011ok
19:29.30brlcadyou have to put the whole hierarchy
19:30.11brlcaddb_functree() is good for that
19:30.15abhi2011ok, umm so I should use dbi_walk_tree() and register callbacks
19:30.17abhi2011oh ok
19:30.17brlcadsee src/libged/keep.c
19:30.49brlcadthe 'heep' command does the same thing you need to do except it writes to a file and you need to write to the inmem
19:31.06brlcader, "keep" command
19:31.29abhi2011ah , ok
19:32.20*** join/#brlcad dli (~dli@66.49.191.45)
19:32.39brlcadhm, abhi2011 but wasn't the point of the inmem so you could call rt_gettrees on it?
19:32.50brlcadwhich only applied to primitives
19:33.19brlcadwhy not just call rt_bound_tree() directly with the same (non-inmem) dbip?
19:33.42abhi2011well yes, for primitives I do call rt_bound_tree() directly
19:33.54abhi2011or rather
19:34.01abhi2011no I dont
19:34.16abhi2011its rt_gettree() which is sufficient
19:34.23brlcadright
19:34.37abhi2011however for combs, the rt_gettree() is not sufficient
19:34.45abhi2011but i havent tried rt_gettrees()
19:34.56abhi2011maybe that will work
19:35.08brlcader, that's not my point
19:35.53brlcadokay, so the problem is a bit convoluted because you lost the caller's rt_db_internal pointer
19:36.05brlcadfirst step, make that first parameter const
19:36.07abhi2011yes :)
19:36.14abhi2011nope that doesnt work
19:36.18brlcadit can
19:36.26abhi2011oh ok
19:36.35abhi2011wdb_put_internal() will be unable to free it then
19:36.39brlcadyep
19:36.45brlcadso you have to do something about that
19:37.18abhi2011well I have tried with const before but I ll try once more, perhaps I missed something
19:37.22brlcadif you make a copy, then that same ip should be just fine for rt_bound_tree()
19:37.28abhi2011ok
19:38.11brlcadit might even be easier to deal with primitives differently
19:38.57brlcadinstead of using an inmem and calling gettrees(), it might be a lot simpler to fill in an rt_comb_internal yourself with just that one primitive as a leaf node
19:39.22brlcadthen you could call rt_bound_tree() the same for any rt_db_internal regardless of it being a primitive or a combination
19:40.08abhi2011ok yes
19:51.37CIA-62BRL-CAD: 03brlcad * r46027 10/brlcad/branches/cmake/: remove the cmake branch as it was reviewed and merged back in April/May 2011. trunk is where the action is now.
19:54.00*** join/#brlcad dli (~dli@67.55.32.136)
19:57.43brlcadstarseeker: can the goblin branch be killed?
19:57.59brlcadhasn't had activity since early 2010
20:17.37CIA-62BRL-CAD: 03brlcad * r46028 10/brlcad/trunk/ (include/raytrace.h src/librt/bbox.c): accept sf patch 3390331 (Addition of a new librt function to return the bounding box) from Abhijit ( abhi2011 ). applies cleanly even if it's still a work in progress.
20:18.39abhi2011yipee :P
20:18.59bhinesleyabhi2011: looking good, I will probably use that to calculate my bb centers :)
20:19.08abhi2011nice :)
20:22.09CIA-62BRL-CAD: 03brlcad * r46029 10/brlcad/trunk/AUTHORS: credit abhijit nandy with his code contributions to date, namely efforts to implement a librt routine that calculates bounding boxes for given geometry. (see sf patch 3390331 and 3376910)
20:22.38brlcadabhi2011: so with that, you are now vetted with commit access -- don't break anything ;)
20:23.23brlcadthat also means, however, that you should commit the updates you have right away, though, and then continually commit to svn throughout the day while you work and make progress
20:23.50brlcadthat makes it a lot easier for other devs to track not only what you are doing, but how and why you arrive at various implementation decisions
20:24.11abhi2011brlcad: thanks, yes I will be careful :)
20:24.26brlcadjust do a good faith effort to make sure you don't break the build, follow the HACKING guidelines, and work with other devs if an issue comes up
20:24.40brlcadabhi2011: and congrats ;)
20:24.57abhi2011:) haha
20:25.22abhi2011yah I ll finish the bb functions and test it before my next commit
20:25.44abhi2011i mean first commit
20:26.31brlcadyou're the only one working on that function right now, so if what you have *now* already compiles, you can go ahead and commit it
20:26.39brlcadthen test/fix, then recommit, etc
20:26.46brlcadyou cannot commit too frequently
20:26.51abhi2011ok
20:26.59brlcadyou can very easily commit too infrequently (and many do)
20:27.23brlcadftw: svn commit -m "blah blah" my_file.c &
20:27.33brlcadbackgrounds the commit with the log message so you can keep coding ;)
20:27.42abhi2011yes ok
20:27.50abhi2011been using tortoise svn :P
20:28.04brlcadah, okay
20:28.24abhi2011i mean before for other projects , while in windows
20:28.27brlcadthat's your perrogative, just don't let the tool slow down your interaction and commits :)
20:28.40abhi2011yep
20:28.58abhi2011i have a question regarding the primary data structures
20:29.06abhi2011used in brl-cad
20:29.39abhi2011so the tree that the rt_* functions manipulate, thats the main boolean tree used to represent the model
20:29.56brlcadsure, you can look at it that way
20:29.56abhi2011I mean the union tree* structure
20:30.02brlcadnods
20:30.52brlcadnote that those represent the tree for a combination (i.e., a combination represents a boolean recipe)
20:31.16brlcadso primitives don't inherintly have a tree because they don't inherintly have a boolean recipe, they are leaf nodes
20:31.39abhi2011yes, so the root has the boolean operations being performed on the leaves, for each node , ok but if everthing is present in the tree leaves(which I understand can only be the primitives) then why is there a need to a slid table soltab
20:32.22brlcada need to what?
20:33.08abhi2011oops... i meant why is there a need for a solid table called struct soltab
20:33.34abhi2011it seems to hold extra information about solids in the model
20:33.56abhi2011but this could have been packed into the union tree nodes
20:34.24starseekerbrlcad: sure
20:35.16CIA-62BRL-CAD: 03bhinesley * r46030 10/brlcad/trunk/src/libged/get_solid_kp.c: Enable retrieval of reasonable default keypoints for the remaining primitive types (METABALL, BOT, ARS, NMG). Remove all FIXME's/unnecessary comments, and trim all line lengths.
20:37.32brlcadabhi2011: struct soltab are basically unpacked rt_db_internal objects of primitives only
20:38.04abhi2011ok
20:38.07brlcadpart legacy part optimized expressiveness
20:38.26brlcadsoltab is basically a prep'd rt_db_internal
20:38.42brlcadprimitive
20:39.04brlcadstarseeker: sure it can go or sure it has value and needs to stay? :)
20:39.16abhi2011ok, and I read in some of the docs that an octree based space partitioning is done before rays are shot by rt
20:39.26brlcaddon't want to remove it if there's some residual value there .. but if it's dead in the water, might as well clean up
20:39.54brlcadabhi2011: spatial partitioning is performed before rays are shot
20:40.05abhi2011ok
20:40.07brlcadso that you only evaluate against primitives that are "near"
20:40.13abhi2011yes
20:40.34brlcadyay, all logo finalists have responded .. time for the announcement
20:40.37brlcadwaddles
21:03.19DarkCalfbrlcad, have you seen Minecraft?
21:15.43kunigami>.< svn: Commit failed (details follow):
21:15.43kunigamisvn: MERGE of '/svnroot/brlcad/osl/trunk': timed out waiting for server (https://brlcad.svn.sourceforge.net)
21:16.11kunigamido you mind if I perform several small commits on boost parts?
21:19.14CIA-62BRL-CAD: 03kunigami * r46031 10/osl/trunk/boost/: adding boost by parts
21:20.27CIA-62BRL-CAD: 03kunigami * r46032 10/osl/trunk/boost/boost/: adding boost by parts
21:23.03CIA-62BRL-CAD: 03starseeker * r46033 10/brlcad/trunk/ (8 files in 8 dirs):
21:23.03CIA-62BRL-CAD: Start organizing a functab function specifically for bounding box calculation.
21:23.03CIA-62BRL-CAD: So far, have functions for ell, tor, tgc and rec pulled out from prep - arb8 is
21:23.03CIA-62BRL-CAD: implemented but the way arb prep works means we can't use it there. sph just
21:23.03CIA-62BRL-CAD: calls the ell routine.
21:24.13starseekerbrlcad: it can go
21:25.06starseekerkunigami: sure - that has to be done sometimes
21:25.07CIA-62BRL-CAD: 03kunigami * r46034 10/osl/trunk/boost/boost/aligned_storage.hpp: adding boost by parts
21:25.17CIA-62BRL-CAD: 03kunigami * r46035 10/osl/trunk/boost/boost/array.hpp: adding boost by parts
21:25.28CIA-62BRL-CAD: 03kunigami * r46036 10/osl/trunk/boost/boost/asio.hpp: adding boost by parts
21:25.38CIA-62BRL-CAD: 03kunigami * r46037 10/osl/trunk/boost/boost/assert.hpp: adding boost by parts
21:25.50kunigamiouch,
21:25.57CIA-62BRL-CAD: 03kunigami * r46038 10/osl/trunk/boost/boost/bind.hpp: adding boost by parts
21:25.57CIA-62BRL-CAD: 03kunigami * r46039 10/osl/trunk/boost/boost/call_traits.hpp: adding boost by parts
21:27.33CIA-62BRL-CAD: 03kunigami * r46040 10/osl/trunk/boost/boost/algorithm/ (43 files in 4 dirs): adding boost by parts
21:29.58CIA-62BRL-CAD: 03kunigami * r46041 10/osl/trunk/boost/boost/archive/ (97 files in 4 dirs): adding boost by parts
21:36.13brlcadstarseeker: awesome, adding the new functab!
21:36.38brlcadfwiw, that makes librt binary incompatible unless you make the new functab entry be last
21:36.50starseekerbrlcad: starting it anyway - some of these aren't so simple (trying the figure out how the frack to get a list of all vertices in an nmg)
21:36.59starseekerbrlcad: ah, crap
21:37.20brlcadnot .g incompatible, librt.so incompat
21:37.24starseekerI should move it then?
21:37.43CIA-62BRL-CAD: 03kunigami * r46042 10/osl/trunk/boost/boost/asio/ (310 files in 13 dirs): adding boost by parts
21:37.43brlcaddoesn't matter -- but if it stays as-is, minor should be bumped
21:38.01starseekergrins evilly - oh good, then we'll do the deprications too
21:38.16CIA-62BRL-CAD: 03kunigami * r46043 10/osl/trunk/boost/boost/bind/ (14 files): adding boost by parts
21:38.28CIA-62BRL-CAD: 03kunigami * r46044 10/osl/trunk/boost/boost/cast.hpp: adding boost by parts
21:38.35starseekerthere has got to be some way to iterate over all vertices in a model for nmg...
21:38.38CIA-62BRL-CAD: 03kunigami * r46045 10/osl/trunk/boost/boost/cerrno.hpp: adding boost by parts
21:38.48CIA-62BRL-CAD: 03kunigami * r46046 10/osl/trunk/boost/boost/checked_delete.hpp: adding boost by parts
21:38.59CIA-62BRL-CAD: 03kunigami * r46047 10/osl/trunk/boost/boost/compressed_pair.hpp: adding boost by parts
21:39.22CIA-62BRL-CAD: 03kunigami * r46048 10/osl/trunk/boost/boost/concept/ (11 files in 2 dirs): adding boost by parts
21:39.33CIA-62BRL-CAD: 03kunigami * r46049 10/osl/trunk/boost/boost/concept_archetype.hpp: adding boost by parts
21:39.44CIA-62BRL-CAD: 03kunigami * r46050 10/osl/trunk/boost/boost/concept_check.hpp: adding boost by parts
21:41.37CIA-62BRL-CAD: 03kunigami * r46051 10/osl/trunk/boost/boost/config/ (73 files in 6 dirs): adding boost by parts
21:41.49CIA-62BRL-CAD: 03kunigami * r46052 10/osl/trunk/boost/boost/config.hpp: adding boost by parts
21:41.59CIA-62BRL-CAD: 03kunigami * r46053 10/osl/trunk/boost/boost/cregex.hpp: adding boost by parts
21:42.08CIA-62BRL-CAD: 03kunigami * r46054 10/osl/trunk/boost/boost/cstdint.hpp: adding boost by parts
21:42.18CIA-62BRL-CAD: 03kunigami * r46055 10/osl/trunk/boost/boost/cstdlib.hpp: adding boost by parts
21:42.27CIA-62BRL-CAD: 03kunigami * r46056 10/osl/trunk/boost/boost/current_function.hpp: adding boost by parts
21:44.03CIA-62BRL-CAD: 03kunigami * r46057 10/osl/trunk/boost/boost/date_time/ (65 files in 3 dirs): adding boost by parts
21:45.07CIA-62BRL-CAD: 03kunigami * r46058 10/osl/trunk/boost/boost/detail/ (33 files): adding boost by parts
21:45.26CIA-62BRL-CAD: 03kunigami * r46059 10/osl/trunk/boost/boost/dynamic_bitset/ (. config.hpp dynamic_bitset.hpp): adding boost by parts
21:45.39CIA-62BRL-CAD: 03kunigami * r46060 10/osl/trunk/boost/boost/dynamic_bitset.hpp: adding boost by parts
21:45.47CIA-62BRL-CAD: 03kunigami * r46061 10/osl/trunk/boost/boost/dynamic_bitset_fwd.hpp: adding boost by parts
21:45.57CIA-62BRL-CAD: 03kunigami * r46062 10/osl/trunk/boost/boost/enable_shared_from_this.hpp: adding boost by parts
21:46.13abhi2011I have a question regarding commits, so suppose I have commited 2 or more files but I want to commit only a particular file as of now, can I do that
21:46.25CIA-62BRL-CAD: 03kunigami * r46063 10/osl/trunk/boost/boost/exception/ (16 files in 2 dirs): adding boost by parts
21:46.29abhi2011*i mean suppose I have modified
21:46.38CIA-62BRL-CAD: 03kunigami * r46064 10/osl/trunk/boost/boost/exception_ptr.hpp: adding boost by parts
21:46.41kunigamiyou can do: svn commit -m "message" name-of-the-file
21:46.51starseekersure - svn commit path/to/specific/file -m "message"
21:46.53abhi2011kunigami: thanks :)
21:46.54starseekerer, yeah
21:47.00abhi2011yes
21:47.21CIA-62BRL-CAD: 03kunigami * r46065 10/osl/trunk/boost/boost/filesystem/ (24 files in 4 dirs): adding boost by parts
21:47.30CIA-62BRL-CAD: 03kunigami * r46066 10/osl/trunk/boost/boost/filesystem.hpp: adding boost by parts
21:47.37plaesbrlcad doesn't support STEP ?
21:47.42CIA-62BRL-CAD: 03kunigami * r46067 10/osl/trunk/boost/boost/foreach.hpp: adding boost by parts
21:47.51CIA-62BRL-CAD: 03kunigami * r46068 10/osl/trunk/boost/boost/foreach_fwd.hpp: adding boost by parts
21:48.24CIA-62BRL-CAD: 03kunigami * r46069 10/osl/trunk/boost/boost/format/ (20 files in 2 dirs): adding boost by parts
21:48.35CIA-62BRL-CAD: 03kunigami * r46070 10/osl/trunk/boost/boost/format.hpp: adding boost by parts
21:49.13CIA-62BRL-CAD: 03kunigami * r46071 10/osl/trunk/boost/boost/function/ (20 files in 2 dirs): adding boost by parts
21:49.23CIA-62BRL-CAD: 03kunigami * r46072 10/osl/trunk/boost/boost/function.hpp: adding boost by parts
21:49.34starseekerplaes: we're working on it - step-g
21:49.36CIA-62BRL-CAD: 03kunigami * r46073 10/osl/trunk/boost/boost/function_equal.hpp: adding boost by parts
21:49.49plaesaha
21:50.01starseekerkunigami: uh, you might want to try committing per dir, not per file...
21:50.03CIA-62BRL-CAD: 03kunigami * r46074 10/osl/trunk/boost/boost/functional/ (13 files in 3 dirs): adding boost by parts
21:50.17starseekeroh, nevermind I see
21:52.16kunigamistarseeker:  I could have done a better job committing each dir's first and then all the single files in a single bundle :( sorry
21:52.29CIA-62BRL-CAD: 03kunigami * r46075 10/osl/trunk/boost/boost/fusion/ (111 files in 21 dirs): adding boost by parts
21:52.43CIA-62BRL-CAD: 03kunigami * r46076 10/osl/trunk/boost/boost/get_pointer.hpp: adding boost by parts
21:53.31brlcadstarseeker: there's nmg_visit()
21:53.54CIA-62BRL-CAD: 03kunigami * r46077 10/osl/trunk/boost/boost/graph/ (45 files in 7 dirs): adding boost by parts
21:53.58brlcadotherwise, I believe it's always treated as a recursive structure so integrity is better preserved
21:54.13starseekernods - OK, let me try a trick...
21:54.16CIA-62BRL-CAD: 03kunigami * r46078 10/osl/trunk/boost/boost/implicit_cast.hpp: adding boost by parts
21:54.16CIA-62BRL-CAD: 03kunigami * r46079 10/osl/trunk/boost/boost/integer/ (. integer_mask.hpp static_log2.hpp): adding boost by parts
21:54.17brlcadfor all regions, for all shells, for all loops, for all edges, for all vertices, etc
21:54.26CIA-62BRL-CAD: 03kunigami * r46080 10/osl/trunk/boost/boost/integer.hpp: adding boost by parts
21:54.33brlcadnmg_visit() has a vertex callback though, so that might be easiest
21:54.36CIA-62BRL-CAD: 03kunigami * r46081 10/osl/trunk/boost/boost/integer_fwd.hpp: adding boost by parts
21:54.37starseeker(by the way - is there a way to clear a bu_ptbl without having to free memory?)
21:54.47CIA-62BRL-CAD: 03kunigami * r46082 10/osl/trunk/boost/boost/integer_traits.hpp: adding boost by parts
21:54.57CIA-62BRL-CAD: 03kunigami * r46083 10/osl/trunk/boost/boost/intrusive_ptr.hpp: adding boost by parts
21:55.12CIA-62BRL-CAD: 03kunigami * r46084 10/osl/trunk/boost/boost/io/ (. detail/ detail/quoted_manip.hpp ios_state.hpp): adding boost by parts
21:55.23CIA-62BRL-CAD: 03kunigami * r46085 10/osl/trunk/boost/boost/io_fwd.hpp: adding boost by parts
21:55.28brlcadstarseeker: I believe so
21:55.33brlcadbu.h ftw ;)
21:55.39starseekeris looking
21:56.29starseekerah - bu_ptbl_zero perhaps...
21:56.39starseekernope there it is
21:56.41starseekerbu_ptbl_reset
21:56.42starseeker:-)
22:01.09CIA-62BRL-CAD: 03kunigami * r46086 10/osl/trunk/boost/boost/is_placeholder.hpp: adding boost by parts
22:01.51CIA-62BRL-CAD: 03kunigami * r46087 10/osl/trunk/boost/boost/iterator/ (17 files in 2 dirs): adding boost by parts
22:02.08CIA-62BRL-CAD: 03kunigami * r46088 10/osl/trunk/boost/boost/iterator.hpp: adding boost by parts
22:02.26CIA-62BRL-CAD: 03kunigami * r46089 10/osl/trunk/boost/boost/iterator_adaptors.hpp: adding boost by parts
22:02.38CIA-62BRL-CAD: 03kunigami * r46090 10/osl/trunk/boost/boost/lexical_cast.hpp: adding boost by parts
22:02.48CIA-62BRL-CAD: 03kunigami * r46091 10/osl/trunk/boost/boost/limits.hpp: adding boost by parts
22:02.59CIA-62BRL-CAD: 03kunigami * r46092 10/osl/trunk/boost/boost/make_shared.hpp: adding boost by parts
22:08.36CIA-62BRL-CAD: 03kunigami * r46093 10/osl/trunk/boost/boost/math/ (206 files in 7 dirs): adding boost by parts
22:08.50CIA-62BRL-CAD: 03kunigami * r46094 10/osl/trunk/boost/boost/mem_fn.hpp: adding boost by parts
22:08.59CIA-62BRL-CAD: 03kunigami * r46095 10/osl/trunk/boost/boost/memory_order.hpp: adding boost by parts
22:10.26CIA-62BRL-CAD: 03kunigami * r46096 10/osl/trunk/boost/boost/mpi/ (55 files in 4 dirs): adding boost by parts
22:10.39CIA-62BRL-CAD: 03kunigami * r46097 10/osl/trunk/boost/boost/mpi.hpp: adding boost by parts
22:13.58CIA-62BRL-CAD: 03starseeker * r46098 10/brlcad/trunk/src/librt/primitives/ (nmg/nmg.c table.c):
22:13.58CIA-62BRL-CAD: This appears to be a working bbox routine for nmg, but I need someone to review
22:13.58CIA-62BRL-CAD: it and make sure I haven't accidently swatted some other prep function during
22:13.58CIA-62BRL-CAD: this re-org. I can get a bbox and raytrace a facetized sphere.
22:31.17CIA-62BRL-CAD: 03kunigami * r46099 10/osl/trunk/boost/boost/mpl/ (902 files in 29 dirs): adding boost by parts
22:33.13CIA-62BRL-CAD: 03kunigami * r46100 10/osl/trunk/boost/boost/multi_index/ (54 files in 2 dirs): adding boost by parts
22:33.24CIA-62BRL-CAD: 03kunigami * r46101 10/osl/trunk/boost/boost/multi_index_container.hpp: adding boost by parts
22:33.36CIA-62BRL-CAD: 03kunigami * r46102 10/osl/trunk/boost/boost/multi_index_container_fwd.hpp: adding boost by parts
22:33.46CIA-62BRL-CAD: 03kunigami * r46103 10/osl/trunk/boost/boost/next_prior.hpp: adding boost by parts
22:33.56CIA-62BRL-CAD: 03kunigami * r46104 10/osl/trunk/boost/boost/non_type.hpp: adding boost by parts
22:34.07CIA-62BRL-CAD: 03kunigami * r46105 10/osl/trunk/boost/boost/noncopyable.hpp: adding boost by parts
22:34.22CIA-62BRL-CAD: 03kunigami * r46106 10/osl/trunk/boost/boost/none.hpp: adding boost by parts
22:34.30CIA-62BRL-CAD: 03kunigami * r46107 10/osl/trunk/boost/boost/none_t.hpp: adding boost by parts
22:35.21CIA-62BRL-CAD: 03kunigami * r46108 10/osl/trunk/boost/boost/numeric/ (20 files in 3 dirs): adding boost by parts
22:35.33CIA-62BRL-CAD: 03kunigami * r46109 10/osl/trunk/boost/boost/operators.hpp: adding boost by parts
22:35.45CIA-62BRL-CAD: 03kunigami * r46110 10/osl/trunk/boost/boost/optional/ (. optional.hpp optional_fwd.hpp): adding boost by parts
22:35.56CIA-62BRL-CAD: 03kunigami * r46111 10/osl/trunk/boost/boost/optional.hpp: adding boost by parts
22:36.27CIA-62BRL-CAD: 03kunigami * r46112 10/osl/trunk/boost/boost/parameter/ (17 files in 2 dirs): adding boost by parts
22:36.49CIA-62BRL-CAD: 03kunigami * r46113 10/osl/trunk/boost/boost/pending/ (9 files in 2 dirs): adding boost by parts
22:36.59CIA-62BRL-CAD: 03kunigami * r46114 10/osl/trunk/boost/boost/pointee.hpp: adding boost by parts
22:37.22CIA-62BRL-CAD: 03kunigami * r46115 10/osl/trunk/boost/boost/pool/ (12 files in 2 dirs): adding boost by parts
22:41.21CIA-62BRL-CAD: 03kunigami * r46116 10/osl/trunk/boost/boost/preprocessor/ (183 files in 35 dirs): adding boost by parts
22:41.39CIA-62BRL-CAD: 03kunigami * r46117 10/osl/trunk/boost/boost/progress.hpp: adding boost by parts
22:41.58CIA-62BRL-CAD: 03kunigami * r46118 10/osl/trunk/boost/boost/property_map/ (9 files in 3 dirs): adding boost by parts
22:46.44CIA-62BRL-CAD: 03kunigami * r46119 10/osl/trunk/boost/boost/python/ (208 files in 7 dirs): adding boost by parts
22:46.59CIA-62BRL-CAD: 03kunigami * r46120 10/osl/trunk/boost/boost/python.hpp: adding boost by parts
22:48.36CIA-62BRL-CAD: 03kunigami * r46121 10/osl/trunk/boost/boost/random/ (61 files in 2 dirs): adding boost by parts
22:48.51CIA-62BRL-CAD: 03kunigami * r46122 10/osl/trunk/boost/boost/random.hpp: adding boost by parts
22:49.57CIA-62BRL-CAD: 03kunigami * r46123 10/osl/trunk/boost/boost/range/ (45 files in 4 dirs): adding boost by parts
22:50.09CIA-62BRL-CAD: 03kunigami * r46124 10/osl/trunk/boost/boost/ref.hpp: adding boost by parts
22:51.47CIA-62BRL-CAD: 03kunigami * r46125 10/osl/trunk/boost/boost/regex/ (57 files in 4 dirs): adding boost by parts
22:52.02CIA-62BRL-CAD: 03kunigami * r46126 10/osl/trunk/boost/boost/regex.hpp: adding boost by parts
22:52.12CIA-62BRL-CAD: 03kunigami * r46128 10/osl/trunk/boost/boost/regex_fwd.hpp: adding boost by parts
22:52.21CIA-62BRL-CAD: 03starseeker * r46127 10/brlcad/trunk/src/librt/primitives/ (bot/bot.c bot/g_bot_include.c table.c): Add bbox routine for bots.
22:52.21CIA-62BRL-CAD: 03kunigami * r46129 10/osl/trunk/boost/boost/scoped_array.hpp: adding boost by parts
22:52.32CIA-62BRL-CAD: 03kunigami * r46130 10/osl/trunk/boost/boost/scoped_ptr.hpp: adding boost by parts
22:53.52CIA-62BRL-CAD: 03kunigami * r46131 10/osl/trunk/boost/boost/serialization/ (51 files in 2 dirs): adding boost by parts
22:54.06CIA-62BRL-CAD: 03kunigami * r46132 10/osl/trunk/boost/boost/shared_array.hpp: adding boost by parts
22:54.17CIA-62BRL-CAD: 03kunigami * r46133 10/osl/trunk/boost/boost/shared_ptr.hpp: adding boost by parts
22:55.53CIA-62BRL-CAD: 03kunigami * r46134 10/osl/trunk/boost/boost/smart_ptr/ (50 files in 2 dirs): adding boost by parts
22:56.08CIA-62BRL-CAD: 03kunigami * r46135 10/osl/trunk/boost/boost/smart_ptr.hpp: adding boost by parts
23:00.50CIA-62BRL-CAD: 03kunigami * r46136 10/osl/trunk/boost/boost/spirit/ (209 files in 36 dirs): adding boost by parts
23:01.10CIA-62BRL-CAD: 03kunigami * r46137 10/osl/trunk/boost/boost/static_assert.hpp: adding boost by parts
23:01.24CIA-62BRL-CAD: 03kunigami * r46138 10/osl/trunk/boost/boost/swap.hpp: adding boost by parts
23:01.45CIA-62BRL-CAD: 03kunigami * r46139 10/osl/trunk/boost/boost/system/ (. api_config.hpp config.hpp error_code.hpp system_error.hpp): adding boost by parts
23:04.48CIA-62BRL-CAD: 03kunigami * r46140 10/osl/trunk/boost/boost/test/ (126 files in 13 dirs): adding boost by parts
23:06.06CIA-62BRL-CAD: 03kunigami * r46141 10/osl/trunk/boost/boost/thread/ (47 files in 4 dirs): adding boost by parts
23:06.17CIA-62BRL-CAD: 03kunigami * r46142 10/osl/trunk/boost/boost/thread.hpp: adding boost by parts
23:06.30CIA-62BRL-CAD: 03kunigami * r46143 10/osl/trunk/boost/boost/throw_exception.hpp: adding boost by parts
23:06.43CIA-62BRL-CAD: 03kunigami * r46144 10/osl/trunk/boost/boost/timer.hpp: adding boost by parts
23:06.54CIA-62BRL-CAD: 03kunigami * r46145 10/osl/trunk/boost/boost/token_functions.hpp: adding boost by parts
23:07.05CIA-62BRL-CAD: 03kunigami * r46146 10/osl/trunk/boost/boost/token_iterator.hpp: adding boost by parts
23:07.15CIA-62BRL-CAD: 03kunigami * r46147 10/osl/trunk/boost/boost/tokenizer.hpp: adding boost by parts
23:07.30CIA-62BRL-CAD: 03kunigami * r46148 10/osl/trunk/boost/boost/tr1/ (. detail/ detail/config.hpp detail/config_all.hpp memory.hpp): adding boost by parts
23:07.46CIA-62BRL-CAD: 03kunigami * r46149 10/osl/trunk/boost/boost/tuple/ (6 files in 2 dirs): adding boost by parts
23:07.56CIA-62BRL-CAD: 03kunigami * r46150 10/osl/trunk/boost/boost/type.hpp: adding boost by parts
23:10.43CIA-62BRL-CAD: 03kunigami * r46151 10/osl/trunk/boost/boost/type_traits/ (121 files in 3 dirs): adding boost by parts
23:11.00CIA-62BRL-CAD: 03kunigami * r46152 10/osl/trunk/boost/boost/type_traits.hpp: adding boost by parts
23:11.57CIA-62BRL-CAD: 03kunigami * r46153 10/osl/trunk/boost/boost/typeof/ (29 files in 3 dirs): adding boost by parts
23:12.13CIA-62BRL-CAD: 03kunigami * r46154 10/osl/trunk/boost/boost/units/ (. detail/ detail/utility.hpp): adding boost by parts
23:12.43CIA-62BRL-CAD: 03kunigami * r46155 10/osl/trunk/boost/boost/unordered/ (16 files in 2 dirs): adding boost by parts
23:12.52CIA-62BRL-CAD: 03kunigami * r46156 10/osl/trunk/boost/boost/unordered_map.hpp: adding boost by parts
23:13.03CIA-62BRL-CAD: 03kunigami * r46157 10/osl/trunk/boost/boost/unordered_set.hpp: adding boost by parts
23:13.34CIA-62BRL-CAD: 03kunigami * r46158 10/osl/trunk/boost/boost/utility/ (15 files in 2 dirs): adding boost by parts
23:13.45CIA-62BRL-CAD: 03kunigami * r46159 10/osl/trunk/boost/boost/utility.hpp: adding boost by parts
23:13.57CIA-62BRL-CAD: 03kunigami * r46160 10/osl/trunk/boost/boost/version.hpp: adding boost by parts
23:14.05*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
23:14.07CIA-62BRL-CAD: 03kunigami * r46161 10/osl/trunk/boost/boost/visit_each.hpp: adding boost by parts
23:16.11CIA-62BRL-CAD: 03kunigami * r46162 10/osl/trunk/boost/boost/wave/ (62 files in 5 dirs): adding boost by parts
23:16.21CIA-62BRL-CAD: 03kunigami * r46163 10/osl/trunk/boost/boost/wave.hpp: adding boost by parts
23:16.32CIA-62BRL-CAD: 03kunigami * r46164 10/osl/trunk/boost/boost/weak_ptr.hpp: adding boost by parts
23:24.12CIA-62BRL-CAD: 03kunigami * r46165 10/osl/trunk/boost/doc/ (. src/ src/minimal.css): adding boost by parts
23:32.14brlcadstarseeker: have you been hooking the new bbox funcs into prep?
23:32.21starseekerbrlcad: yeah
23:32.24brlcadcool
23:32.25starseekerwhere I can
23:51.21CIA-62BRL-CAD: 03kunigami * r46166 10/osl/trunk/boost/libs/ (481 files in 118 dirs): adding boost by parts
23:52.56CIA-62BRL-CAD: 03kunigami * r46167 10/osl/trunk/boost/tools/: adding boost by parts
23:53.42CIA-62BRL-CAD: 03kunigami * r46168 10/osl/trunk/boost/tools/build/ (. boost.css index.html v2/): adding boost by parts
23:55.16CIA-62BRL-CAD: 03kunigami * r46169 10/osl/trunk/boost/tools/build/v2/ (21 files): adding boost by parts
23:58.51``ErikO.o svn has a builtin variant of .cvsignore? (the ringworld commit caught my eye)
IRC log for #brlcad on 20110817

IRC log for #brlcad on 20110817

00:00.25CIA-62BRL-CAD: 03kunigami * r46170 10/osl/trunk/boost/tools/build/v2/ (53 files in 6 dirs): adding boost by parts
00:01.22``Erik(a couple people (slow committers) have asked why we aren't on git, any valid argument?)
00:02.40CIA-62BRL-CAD: 03starseeker * r46171 10/brlcad/trunk/src/librt/primitives/bot/ (bot.c g_bot_include.c): Whoops - shouldn't be resetting stp here.
00:04.36CIA-62BRL-CAD: 03starseeker * r46172 10/brlcad/trunk/src/librt/primitives/ (ars/ars.c table.c): It's not strictly necessary for prep as long as we're using BoT internally for ars, but go ahead and add a bbox routine for ars.
00:05.22starseeker``Erik: we aim to have everybody committing to a common branch to avoid "working in isolation" too much, as I understand it
00:05.33starseekergit makes it much easier to wander off in a corner and work in isolation
00:06.10``Erikthat was my thought, but I'd probably present it as "suck it up, stub it so it compiles and commit a lot, stop whining"
00:06.52``Erikmy two office mates are reluctant to commit until they feel things are "done", which throws away the continual peer review aspect
00:07.39starseekernods - we've tried to discuss that with 'em before, but to no avail
00:08.14starseekerwonders if he should bother with a bbox routine for poly - I'm not even sure how I'd test it
00:08.38CIA-62BRL-CAD: 03kunigami * r46173 10/osl/trunk/boost/tools/build/v2/ (283 files in 38 dirs): adding boost by parts
00:10.22``Erik'poly'?
00:10.47``Erikopen nmg, basically?
00:11.38``Erikbe easy to write such a func, set max to -infinity, min to infinity, then for each vertex, see if max{x,y,z} is bigger and min{x,y,z} is smaller, update them as you go
00:16.20``Erikwanders off, hasta la pasta
00:17.28CIA-62BRL-CAD: 03kunigami * r46174 10/osl/trunk/boost/tools/build/v2/test/ (365 files in 50 dirs): adding boost by parts
00:22.13CIA-62BRL-CAD: 03kunigami * r46175 10/osl/trunk/boost/tools/build/v2/engine/ (99 files): adding boost by parts
00:24.14abhi2011is anyone able to compile with strict warnings on : cmake ../brlcad -DBRLCAD_BUNDLED_LIBS=Bundled -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad
00:24.16CIA-62BRL-CAD: 03kunigami * r46176 10/osl/trunk/boost/tools/build/v2/engine/ (14 files in 2 dirs): adding boost by parts
00:24.57abhi2011i am still getting the function prototype errors I was getting yesterday from a fresh checkout : /home/abhi/socis/brlcad/src/libged/inside.c:935:2: error: call to function ‘rt_arb_get_cgtype’ without a real prototype
00:41.40CIA-62BRL-CAD: 03kunigami * r46177 10/osl/trunk/boost/tools/build/v2/engine/boehm_gc/ (92 files): adding boost by parts
00:44.53CIA-62BRL-CAD: 03kunigami * r46178 10/osl/trunk/boost/tools/build/v2/engine/boehm_gc/ (59 files in 5 dirs): adding boost by parts
00:46.36CIA-62BRL-CAD: 03kunigami * r46179 10/osl/trunk/boost/tools/build/v2/engine/boehm_gc/doc/ (37 files): adding boost by parts
00:47.39CIA-62BRL-CAD: 03kunigami * r46180 10/osl/trunk/boost/ (Jamroot boost-build.jam boost.png bootstrap.sh): woot the last boost files
00:50.52CIA-62BRL-CAD: 03kunigami * r46181 10/osl/trunk/compile.sh: added rule for boost and osl - it remains fixing the destination dir of oiio and osl and testing on another machine
01:21.57starseeker``Erik: oh, I know it's easy to write but the primitive is an old one
01:22.24starseekermake and in don't support it, so creating one would require a bit of nonsense
01:24.18starseekerI can on gentoo - what gcc/os are you using?
01:25.15CIA-62BRL-CAD: 03bhinesley * r46182 10/brlcad/trunk/src/libged/edit.c: (log message trimmed)
01:25.15CIA-62BRL-CAD: Started logging tests of translate options/args. Ex. of a more complex set of
01:25.15CIA-62BRL-CAD: args that is working: "translate -a -x comb/combA 3 -z combB/combC 0 0 11 -y
01:25.15CIA-62BRL-CAD: combD/combE 0 7 combF/combG", which moves the instance of combG in combF from
01:25.15CIA-62BRL-CAD: it's bounding box center to (x= apparent bb ctr of comb/combA offset 3 units),
01:25.16CIA-62BRL-CAD: (y= apparent bb ctr of combF/combG offset 7 units), (z= apparent bb ctr of
01:25.17CIA-62BRL-CAD: combB/combC offset 11 units). Disable use of batch operator as an argument to
01:30.11brlcadabhi2011: so fix it :)
01:30.38brlcadfor whatever reason, nobody else is hitting that warning, making you the perfect person to fix it
01:32.15brlcadstarseeker: poly was the precursor to BoT
01:34.27CIA-62BRL-CAD: 03brlcad * r46183 10/brlcad/trunk/TODO: the hf and polysolid primitives are both supplanted by newer more complete primitives (half and BoT respectively), so mark them for removal in rel8
01:35.02abhi2011yep I turned of strict warnings :P
01:35.35brlcadabhi2011: that's no fix :P
01:35.46brlcadyou do understand what that message means, yes?
01:36.24abhi2011hehe yeah, will look into it, though its strange that I am getting it for almost every c function
01:37.08brlcadshouldn't have to look into it .. should be obvious -- if it's not, then you definitely should "fix" that warning
01:37.29brlcadprototype is empty
01:37.44brlcadit wants a real decl with the args listed
01:37.58brlcaddecl is in include/raytrace.h
01:38.56abhi2011yes and I am sure its included in the appropriate c file
01:39.43brlcadsure, but the prototype is *empty*
01:39.53brlcadthat's what the compiler is warning you about
01:40.10brlcadmake it be not empty
01:40.33bhinesleyabhi2011: curious which gcc you're running
01:40.48abhi2011yes, I can do that, I am just wondering if its code being modified by someone else
01:41.19abhi2011brlcad:  4.5.1 20101208
01:41.53CIA-62BRL-CAD: 03brlcad * r46184 10/brlcad/trunk/TODO: need to include deprecation output on the old build system as well as when creating (or perhaps exporting) bspline/poly/hf primitives.
01:42.30brlcadabhi2011: no entiendo.. "code being modified by someone else"?
01:43.23brlcadno code is sacred, if code is found deficient, it gets fixed/improved/refactored
01:43.37brlcadrevision control is our safety net
01:44.48abhi2011brlcad: ok :) , though I was wondering whats the compiler version you are using
01:45.11abhi2011because it seems more like a  compiler flag issue
01:45.15bhinesleyabhi2011: we're all over the place. I'm using 4.6
01:45.19abhi2011ok
01:45.51CIA-62BRL-CAD: 03brlcad * r46185 10/brlcad/trunk/doc/deprecation.txt:
01:45.51CIA-62BRL-CAD: they were never officially documented as such, so do so now. mark the bspline,
01:45.51CIA-62BRL-CAD: poly, and hf primitives as deprecated. as removing them is a rather major
01:45.51CIA-62BRL-CAD: backwards-incompatible change, they're better suited to rel8 than they are the
01:45.51CIA-62BRL-CAD: usual 3-minor release timeframe. they should be documented somewhere
01:45.52CIA-62BRL-CAD: regardless.
01:46.34brlcadabhi2011: we intentionally consider all warnings as errors for this exact reason, so that the issues get fixed
01:48.41brlcadthe compiler usually issues warnings for pretty good reasons, so it's our project stance to halt regardless of version or environment (unless the issue is fundamentally unavoidable or a bug outside our control that cannot be compensated for easily)
01:49.47starseekerbrlcad: do we have a tool to convert bspline/poly/hf primitives to their newer versions?
01:49.59starseekerwonders if cline can also get chopped...
01:50.19brlcadstarseeker: nope
01:50.22abhi2011brlcad: yes, I understand that, the errors came for a huge number of functions across multiple files, so I ll see if fixing one of them makes a difference
01:50.40brlcadstarseeker: actually "yes" .. it just doesn't
01:50.42brlcaddbupgrade
01:51.13starseekernods
01:51.37starseekerso that would be added for a 5->6 upgrade?
01:51.51brlcadI added code to run bspline through brep, worked well
01:51.59brlcadbut the other two are relics
01:52.45starseekernods - but I'm guessing we still don't get to ignore 'em in the upgrade path?
01:52.59brlcadshouldn't
01:55.33starseekerdo we teach dbupgrade to convert 'em now when run on a v5 file?
01:57.29*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:03.50CIA-62BRL-CAD: 03bhinesley * r46186 10/brlcad/trunk/src/libged/edit.c: Simplify iterating through arguments for execution of batch commands.
02:11.42brlcadstarseeker: that would probably be okay
02:12.52brlcadpresently does nothing with v5 files, of course
02:35.52CIA-62BRL-CAD: 03brlcad * r46187 10/brlcad/trunk/src/librt/primitives/table.c:
02:35.52CIA-62BRL-CAD: there's no need to intentionally make matters any harder for ourselves than they
02:35.52CIA-62BRL-CAD: need to be, move the bbox routine to the end so we can reduce the risk of
02:35.52CIA-62BRL-CAD: calling the wrong callback and crashing (or worse) if an older library somehow
02:35.52CIA-62BRL-CAD: got linked. also didn't seem to be any particular grouping reason to have it
02:35.52CIA-62BRL-CAD: between ifree/describe .. more closely related to prep and params, which the
02:35.53CIA-62BRL-CAD: latter is conveniently at the end.
02:36.35CIA-62BRL-CAD: 03brlcad * r46188 10/brlcad/trunk/include/raytrace.h: oops, this file goes with r46187. move bbox to the end.
02:37.00brlcadstarseeker: you see tom's note?
02:37.05brlcadrevenge of the red
02:40.42CIA-62BRL-CAD: 03brlcad * r46189 10/brlcad/trunk/src/libged/red.c: remove the WARNING blather. all of the known red issues were fixed and are now integrated into our release regression testing with a rather extensive set of tests.
03:04.47abhi2011ok I  was looking into the error: call to function ‘blahblah’ without a real prototype , that I have been getting : it seems many(about 40+ functions, probably more) have been declared as follows Function(), and overhauling all of them would involve updating a huge number of files
03:08.05abhi2011Not sure if it would be a good idea to do that
03:08.21bhinesley$5 says that it would be :)
03:09.12abhi2011hehe :), well I ll get started then
03:09.38bhinesleyi'm really curious as to why you're being alerted to these issues and not me (and others?). As brlcad pointed out, at least with the first warning, there is an actual problem that we can all observe; not the result of some configuration issue on your end.
03:10.32bhinesleyslight differences in the compiler, I must assume
03:10.42abhi2011well I am using a standard cmake configuration : cmake ../brlcad -DBRLCAD-ENABLE_STRICT=ON -DBRLCAD_BUNDLED_LIBS=Bundled -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/abhi/brlcad
03:10.51abhi2011yes, the funny thing is, it wasnt there last week
03:11.01abhi2011exactly same compiler
03:11.25bhinesleyshrugs
03:22.09brlcadyeah, that's the odd part
03:22.51brlcadI pulled latest gcc svn (gcc 4.7) and don't get that warning, even though it's clearly a valid warning with the dumb k&r declarations being used
03:24.19brlcadabhi2011: so yeah, it would be a great idea to fix them since you're the one getting the reports .. but it's impossible that it's a "huge" number of files :)
03:24.48brlcad40+ functions would, at worst, be 40+ files .. that's quick n' easy, maybe 20 min on a bad day :)
03:25.18brlcadmore than likely, it's 90% in raytrace.h
03:27.08CIA-62BRL-CAD: 03brlcad * r46190 10/brlcad/trunk/TODO: report that rtcheck doesn't work in previous release. probably the rt output bug, but warrants a quick test before the next release.
03:31.21CIA-62BRL-CAD: 03bhinesley * r46191 10/brlcad/trunk/src/libged/edit.c: (log message trimmed)
03:31.21CIA-62BRL-CAD: Argument type flags were being cleared by mistake. This led to an assert failure
03:31.21CIA-62BRL-CAD: when trying to calculate vectors, as there was no argument flagged EDIT_FROM;
03:31.22CIA-62BRL-CAD: which should at least defaulted to something. The batch operator is now working,
03:31.22CIA-62BRL-CAD: at least in the simple cases that I tried. Also, a variable tracking the number
03:31.22CIA-62BRL-CAD: of arguments in a linked list was only incremented by 1 for each batch operator,
03:31.23CIA-62BRL-CAD: rather than adding the number of target objects to the total. I didn't observe
03:31.44bhinesley^-- amazing the trouble a missing bit can cause
03:41.04CIA-62BRL-CAD: 03bhinesley * r46192 10/brlcad/trunk/src/libged/edit.c: Error about not yet supporting use of the batch operator to specify individual coordinates was a bit overzealus.
03:41.42bhinesleyyay, all kinds of neat stuff works now
03:53.06brlcadheh
03:53.10brlcadawesome!
03:53.39brlcadbhinesley: so you're soon to be on my radar to obtain deeper understanding of all the changes you've made of lagte
03:53.55brlcadthe code is getting a bit complex for the task at hand
03:54.52brlcadbut a bit premature to comment other than "that's a lot of code!" :)
03:55.07brlcadnice work on tackling such a complex task
04:00.17bhinesleygreat, I look forward to your comments/ideas
04:04.47bhinesleyif I remove incomplete scale/rotate stuff, there are 1176 LOC according to cloc; and about as many lines in comments
04:05.33brlcadstarseeker: nmg bbox looks good to me on the surface, save for one issue -- an empty nmg will likely crash, need to init vert_table
04:06.41brlcadbhinesley: like I said, that's a lot of code (for something as basically amounts to a xform call) :)
04:07.06brlcadthe arg processing probably begs refactoring
04:07.11bhinesleythe translate command is 158 LOC
04:07.29brlcadyeah, that's more what I'd expect
04:07.50brlcadso there's a ton of infrastructure around the meat of the matter
04:07.57brlcadnot saying that's good or bad, it is what it is
04:08.09bhinesleysame here
04:08.43brlcadit is, however, a pretty strong cue that something probably needs to be refactored
04:09.37bhinesleythat's not suprising. I've learned a lot (about brlcad and coding), and there were a lot of suprises along the way.
04:11.29bhinesleyI certainly didn't expect it to take me this long
04:11.37bhinesleybut there it is
04:17.21brlcadyep
04:18.14brlcadhopefully you stick to it too, there's a lot of interesting projects you could cut your teeth on now that you've become a little familiar with the code
04:18.33brlcadsome a lot more exciting that argument parsing ;)
04:18.37bhinesleyhehe
04:29.16CIA-62BRL-CAD: 03bhinesley * r46193 10/brlcad/trunk/src/libged/edit.c: These arguments to translate work, since r46191/92.
05:37.50CIA-62BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3079 10/wiki/User:Bhinesley: /* Log */ crossed out tasks, logged today
06:38.09brlcadpublishes the logo contest finalists
06:38.15brlcadwaddles off into the night
07:34.57*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
11:18.46abhi2011brlcad: yes, I have begun modifying the k&r styles
14:00.34CIA-62BRL-CAD: 03kunigami * r46194 10/osl/trunk/oiio/Makefile: modified the build script a bit so that oiio exports to a default destination install
14:02.10*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
14:09.59CIA-62BRL-CAD: 03kunigami * r46195 10/osl/trunk/osl/ (Makefile src/CMakeLists.txt): added missing make from osl root and also turned off -werror
14:11.35CIA-62BRL-CAD: 03kunigami * r46196 10/osl/trunk/compile.sh: now both osl and oiio should be build on default dirs
14:17.25CIA-62BRL-CAD: 03kunigami * r46197 10/osl/trunk/boost/boostcpp.jam: missing file to build boost
14:17.48*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:19.52CIA-62BRL-CAD: 03kunigami * r46198 10/osl/trunk/compile.sh: boost should be built before oiio/osl
14:51.32CIA-62BRL-CAD: 03starseeker * r46199 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: initialize bu_ptbl for nmg vert list in bbox routine.
14:55.00*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
15:05.07kunigamiis there any environment variable I can set so that cmake find_library will look there too?
15:10.48``Erikmebbe LD_LIBRARY_PATH ?
15:13.13kunigamihmm I tried that, but didn't work. INut 'll check again
15:19.04kunigaminope. by the way, I'm trying to call FindPNG module, but it's not setting anything. I've build brlcad and so libpng was build on <brlcad dest>/lib/, which is the path that I added to LD_LIBRARY_PATH
15:29.22*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
15:30.28kunigamianyone having problems with ITK_LBRARY not being found?
15:34.43brlcadabhi2011: so version control 101 -- if you've been modifying them, then you should be committing already
15:35.20brlcadfix one, commit, fix another, commit -- at least per file
15:35.52brlcadwaiting to commit them all as one mega change is much harder to review
15:39.48starseekerkunigami: you're using a system itk?
15:40.36starseekerkunigami: I believe the environment variable is CMAKE_LIBRARY_PATH
15:58.13CIA-62BRL-CAD: 03r_weiss * r46200 10/brlcad/trunk/src/ (4 files in 4 dirs): Updated files 'get_solid_kp.c', 'rec.c', 'tgc.c' and 'nmg.c' to remove the compiler error/warning message 'ISO C90 forbids mixed declarations and code'.
16:00.02*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
16:02.48kunigamistarseeker: I'm using -DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON, so I believe it's using from the source
16:06.59starseekerkunigami: that option has changed - try -DBRLCAD_BUNDLED_LIBS=Bundled
16:07.05kunigamistarseeker: thanks, that name led me to the CMAKE_PREFIX_PATH
16:07.19kunigamistarseeker: oh,
16:10.43kunigamihmm, no, the error remains
16:10.56CIA-62BRL-CAD: 03abhi2011 * r46201 10/brlcad/trunk/src/librt/bbox.c: Updated librt function for finding bb from rt_db_internal
16:20.29CIA-62BRL-CAD: 03abhi2011 * r46202 10/brlcad/trunk/include/raytrace.h: Updated declaration for the bb function as well
16:28.52CIA-62BRL-CAD: 03abhi2011 * r46203 10/brlcad/trunk/src/fb/fb-orle.c: Filled in empty K&R style prototypes with the parameter datatypes
16:29.41CIA-62BRL-CAD: 03abhi2011 * r46204 10/brlcad/trunk/include/orle.h: Filled in empty K&R style prototypes with the parameter datatypes
16:31.37kunigamidamn
16:32.17abhi2011there appears to be 2 structures in use in libfb with exactly the same definition : struct ColorMap and struct RLEColorMap
16:33.19abhi2011kunigami: I was getting the itk error 2 days ago, but a clean checkout and the bundled options helped compile it successfully
16:33.55kunigamiI had mistyped the command to DBRLCAD-BUNDLED_LIBS=Bundled sorry :(
16:34.09abhi2011:)
16:36.13abhi2011and strangely some of the functions in libfb are defined with struct RLEColorMap * but are passed struct ColorMap * , leading to a lot of warnings
16:37.10*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
16:40.07starseekerabhi2011, kunigami: if you guys can use cmake-gui, it will show you the most common "user" options
16:50.53CIA-62BRL-CAD: 03starseeker * r46205 10/brlcad/trunk/src/librt/primitives/ (poly/poly.c table.c): add a bbox routine for poly - pretty minimal shifting of the logic, as this is on its way out anyway.
16:54.11kunigamistarseeker: do you know if it is available for mac?
16:55.55brlcadabhi2011: why did you add fb.h to orle.h ?
16:56.14brlcadorle shouldn't need fb.h iirc
16:57.08*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
16:58.39CIA-62BRL-CAD: 03brlcad * r46206 10/brlcad/trunk/src/fb/ (cmap-crunch.c fb-cmap.c fb-orle.c fbpoint.c): remove authors, revision control tracks actual authorship
17:00.31bhinesleykunigami: not sure about your question, but fyi the curses version, ccmake, will achieved the same end
17:03.49kunigamibhinesley: I'll take a look on that. thanks!
17:07.23abhi2011brlcad: that was to allow the declaration of struct ColorMap to be available, I had modified the declaration of rle_wmap() to be rle_wmap(FILE *, ColorMap *); as a ColorMap* was being passed to it in fb-orle.c
17:07.46abhi2011But i later changed it to rle_wmap(FILE *, RLEColorMap *);
17:08.06abhi2011when I checked the definition of rle_wmap()
17:08.32*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
17:09.00CIA-62BRL-CAD: 03brlcad * r46207 10/brlcad/trunk/src/fb/fb-orle.c: the structures are just coincidentally the same, so we need to copy the color map values before passing to rle_wmap. if fbio's structure ever changed, the hard cast would have been a potentially nasty bug to diagnose.
17:09.22abhi2011So my question is I do get a lot of warnings (which of course are treated as errors), wherever a struct RLEColorMap * should be passed instead of struct ColorMap*
17:09.26*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
17:10.45abhi2011brlcad: ok so I can copy the struct ColorMap values to a struct RLEColorMap instead and pass a struct RLEColorMap* as expected
17:13.09CIA-62BRL-CAD: 03brlcad * r46208 10/brlcad/trunk/src/fb/ (cmap-crunch.c fb-cmap.c fb-orle.c fb-rle.c): ws indent style cleanup
17:13.31brlcadabhi2011: yeah, that's probably better
17:13.37abhi2011ok
17:13.52brlcadI'm actually not 100% positive that they're actually compatible too, but that's how the code is presently written
17:14.02brlcadthe new rle color maps have a different ordering iirc
17:14.59CIA-62BRL-CAD: 03brlcad * r46209 10/brlcad/trunk/include/orle.h: shouldn't need fb.h here
17:16.24brlcadabhi2011: coincidentally, that's why the compiler warnings are a good thing -- we wouldn't have known that a struct was being implicitly converted until the arg list was added to the function prototype
17:17.31CIA-62BRL-CAD: 03kunigami * r46210 10/osl/trunk/jpeg-8c/ (180 files): oiio also depends on jpge
17:17.45starseekerkunigami: cmake?  sure
17:17.46abhi2011brlcad: ok I ll explicitly specify the struct members while copying instead of a plain A = B
17:19.19starseekerkunigami: http://www.cmake.org/files/v2.8/cmake-2.8.5-Darwin-universal.dmg
17:23.41*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
17:29.04brlcadkunigami: heh, the list just keeps growing :)
17:29.29kunigamibrlcad: libtiff is coming too!
17:29.33brlcad:)
17:30.38brlcadkunigami: it's a good thing OSL is actually worth it ... can't wait to see a full detail rendering run over a weekend
17:31.06kunigamibrlcad: :)
17:31.08starseekerisn't sure if brlcad is making an assertion or a challenge :-P
17:31.18kunigamihehe
17:32.46CIA-62BRL-CAD: 03starseeker * r46211 10/brlcad/trunk/src/librt/primitives/ (bspline/bspline.cpp table.c): Take a stab at a bbox routine for brep. Like poly, not going to put much effort into this one - in this can't won't even hook it into prep.
17:33.10starseekerhmm s/can't/case
17:33.42brlcadand s/brep/bspline/
17:34.03starseekerer, yeah
17:34.37brlcadis excited, actually getting 3D geometry for the logo
17:34.49brlcadthough that will be fun to model in BRL-CAD
17:37.34kunigamiby far, the thing that is taking more time is to add entries on subversion/config of files without extension :(
17:37.57starseekerkunigami: yep, always a problem when adding an external repo
17:38.48brlcadkunigami: write a script?
17:39.00brlcadthey're all header files, no?
17:39.06starseekernotes that the moose is out, abstract art is in ;-)
17:39.38kunigamibrlcad: I wrote a script to tell which files are not covered by config before adding them https://gist.github.com/1150253
17:39.42brlcadthe moose isn't necessarily out, but the other won had considerably more votes
17:39.51brlcads/won/one/ jessh
17:40.19kunigamimaybe I can assume a default (svn:eol-style=native;svn:mime-type=text/plain) in those cases
17:41.08brlcadmaybe I'm missing something, but you should be able to add most all of boost with a 'find' command one-liner
17:42.28brlcadstarseeker: I think what'll amount to is a mix -- the moose is still the mascot, just the logo doesn't necessarily refer to it
17:42.38starseekernods
17:42.41brlcadlike how redhat's is a hat, even though the mascot is a penguin
17:43.00brlcador ubuntu with the three holding hands
17:43.51bhinesleywhat could cause the compiler to warn about variables as being "set but not used", when they are in fact set and used (in rec.c vars:magsq_c/magsq_d)?
17:44.11*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
17:44.52bhinesleyoh gosh, n/m I was in the wrong function with the same vars
17:45.12starseekerbhinesley: that's a consequence of the bbox function logic moving
17:45.13brlcadkunigami:  cp boost /path/to/svn/boost ; cd /path/to/svn ; find boost -type d -exec svn add {} \; -type f -exec svn add {} \; -exec svn ps svn:eol-style native {} \; -exec svn ps svn:mime-type text/plain {} \;
17:45.23brlcadsomething like that at least, should do the trick
17:45.26starseekermagsq_c and magsq_d are apparently not used in prep now
17:45.33kunigamibrlcad: now I'm not sure we're talking about the same things. Here are the files of libtiff that svn won't know how to set mime-type/eol-style: http://paste.ubuntu.com/668472/
17:46.31brlcadyeah, so I'd just take that list as-is, set them as text/plain and move on :)
17:47.17brlcadcat log | awk '{print $4}' | xargs svn ps svn:eol-style native
17:47.18brlcad<PROTECTED>
17:47.21CIA-62BRL-CAD: 03starseeker * r46212 10/brlcad/trunk/src/librt/primitives/rec/rec.c: compilers should be happy.
17:48.06kunigamihmmm I didn't know that it was a command to set it. I was editing the config file manually >.<
17:49.24bhinesleystarseeker: yeah sorry, I would have removed them but went to the wrong function and it looked fine :-|
17:49.37starseekernp - my fault, it was my change
17:49.51bhinesleyah
17:50.17starseekeris extracting bounding box logic from prep routines - occasionally messy
17:52.36brlcadkunigami: oh dear!...
17:53.18brlcadkunigami: http://brlcad.org/wiki/Mime-types
17:53.38brlcadspecifically, the part near the end
17:54.06kunigamiI should have read past the 5th line too :(
18:03.22*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
18:07.17CIA-62BRL-CAD: 03starseeker * r46213 10/brlcad/trunk/src/librt/primitives/ (ebm/ebm.c table.c): ebm bbox routine.
18:14.46CIA-62BRL-CAD: 03starseeker * r46214 10/brlcad/trunk/src/librt/primitives/ (table.c vol/vol.c): vol is basically a variation on ebm as far as bbox goes.
18:16.37CIA-62BRL-CAD: 03bhinesley * r46215 10/brlcad/trunk/src/libged/edit.c:
18:16.37CIA-62BRL-CAD: Testing "translate -k -x 3 -a -y 5 shp" revealed that the default "to" points
18:16.37CIA-62BRL-CAD: (ex: x/z of -a) were being set to shp's bb-ctr, rather than the kp specified
18:16.37CIA-62BRL-CAD: with -k (which in turn defaults points to the bb-ctr of shp). That cmd should
18:16.37CIA-62BRL-CAD: move the bb-ctr of shp to y=5 and not change its x/z pos (the -k part is
18:16.38CIA-62BRL-CAD: superflous). It was moving the y-axis, but was also moving on the x-axis an
18:16.39CIA-62BRL-CAD: amount equal to the difference between the bb ctr of shp and x=3.
18:17.03brlcadstarseeker: the good news is that all counts towards GS/GE work
18:17.34*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
18:21.38*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
18:32.03starseekerbrlcad: question - looking at bn_tol in bn.h, the comments say double perp; /**< @brief nearly 0 */ but BN_VECT_ARE_PARALLEL is doing NEAR_EQUAL comparisions between _tol->perp and -1.0/1.0.  Won't those always be false?
18:44.58CIA-62BRL-CAD: 03kunigami * r46216 10/osl/trunk/tiff-3.9.5/ (447 files in 26 dirs): oiio also depends on tiff
18:51.02brlcadstarseeker: I believe the comment is misleading
18:52.32bhinesleystarts cracking on docbook
18:53.08brlcadstarseeker: oh, my bad -- it's right
18:53.19CIA-62BRL-CAD: 03kunigami * r46217 10/osl/trunk/compile.sh: added rules for jpeg and tiff
18:54.07brlcadperp is close to zero, the comparison isn't between tol->perp and -1.0/1.0 .. it's between the dot product value and -1/1 .. within a tol->perp near-zero tolerance
18:55.19brlcadsince the dot product is already range clamped, the tight distance tolerance becomes too tight.. you want a different tolerance close to zero but bigger than SMALL_FASTF, probably even bigger than 0.0005
18:56.18brlcadinterestingly enough, looks like it's 1e-6 in most places I can find
18:56.53starseekerthere's an RT_DOT_TOL in the header, but I'm not sure it's used
18:57.09brlcadhm, 0 in some places 0.001 (which feels right) in others, and 1e-6 in most places (feels too tight)
18:57.51brlcadheh, nice relevant comment in libbn/plane.c
18:57.57brlcad<PROTECTED>
18:57.58CIA-62BRL-CAD: 03starseeker * r46218 10/brlcad/trunk/src/librt/primitives/ (arbn/arbn.c table.c):
18:57.59CIA-62BRL-CAD: Make a stab at arbn bbox. This is another one where prep won't call the bbox
18:57.59CIA-62BRL-CAD: routine directly, since it needs the same work for other stuff. Tried to pix
18:57.59CIA-62BRL-CAD: sensible defaults for tolerances, since we don't pass a tolerance into this
18:57.59CIA-62BRL-CAD: function.
18:58.47brlcadlooks like RT_DOT_TOL isn't used
18:59.01starseekergrowl.  It should be
18:59.20brlcadused during typein
18:59.27brlcadfor hyp and ehy
18:59.40starseekerneeds something in the arbn bbox routine
18:59.53starseekersure don't want to hardcode a number
19:00.20brlcadlooks like cline, ehy, epa, hyp, nmg, red, revolve, rhc, rpc, and tgc use RT_DOT_TOL internally
19:00.44brlcadso it is used.. just probably not in all the places it should
19:00.52starseekernods
19:03.33starseekeryipe - pipe bbox is going to be a bit of fun
19:07.06bhinesleys/yipe/yipee
19:07.41brlcadstarseeker: just call bbox on all the individual tgc and sph elements
19:07.49brlcader, tor
19:08.22starseekerbrlcad: actually, as I'm digging in it looks like there's already some more or less split out functionality for this
19:08.33brlcadhm, okay
19:08.51starseekerrt_bend_pipe_prep deals pretty much entirely with per-bend bbox issues,fromt he looks of it - just a head insertion at the end
19:09.31starseekeroh, wait - hmm
19:09.38starseekerscratch that, it is mixed abit
19:10.29starseekerthat bp struct is not a throwaway
19:11.08*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
19:11.34starseekerand we do need this logic, otherwise it becomes possible (I think) to create pipes with really really bad bboxes
19:16.40CIA-62BRL-CAD: 03r_weiss * r46219 10/brlcad/trunk/src/libbn/plane.c: (log message trimmed)
19:16.41CIA-62BRL-CAD: Within file 'plane.c' updated functions 'bn_coplanar', 'bn_isect_2planes' and
19:16.41CIA-62BRL-CAD: 'bn_isect_lseg3_lseg3_new'. Corrected a bug in 'bn_coplanar' when computing the
19:16.41CIA-62BRL-CAD: distance between planes. Within function 'bn_isect_2planes' changed some
19:16.41CIA-62BRL-CAD: floating point compares from zero to SMALL_FASTF and improved the comments.
19:16.41CIA-62BRL-CAD: Within 'bn_isect_lseg3_lseg3_new' fixed a bug when line segments are colinear
19:16.42CIA-62BRL-CAD: and the intersection in on the end point(s), the clamping of the exact end point
19:40.18brlcadnow that's some good stuff
19:40.49brlcadr_weiss should get to more nitty gritty libbn review like that instead of futzing with nmg!
19:41.08brlcadsomeone should go pat him on the back, that's more like it :)
19:42.23brlcadexcept for the whole bn_isect_lseg3_lseg3_new()
19:44.11*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:50.40CIA-62BRL-CAD: 03r_weiss * r46220 10/brlcad/trunk/src/librt/primitives/nmg/nmg_misc.c: Updated function 'nmg_ck_vert_on_fus' within file 'nmg_misc.c'. Simplified logic, did some code cleanup. Removed an unnecessary floating point compare to zero.
20:09.18CIA-62BRL-CAD: 03kunigami * r46221 10/osl/trunk/compile.sh: oiio will add /dist, no need to do that with $prefix
20:17.03CIA-62BRL-CAD: 03starseeker * r46222 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: Richard pointed out a pre-existing nmg bounding box function - use that.
20:22.42bhinesleyconsiders investigating how much work it would be to get linkends between manual pages working
20:24.34*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
20:28.34CIA-62BRL-CAD: 03bhinesley * r46223 10/brlcad/trunk/doc/docbook/system/mann/en/ (CMakeLists.txt Makefile.am translate.xml): Add placeholders for edit/translate commands
20:29.07bhinesleyoops
20:33.17CIA-62BRL-CAD: 03bhinesley * r46224 10/brlcad/trunk/doc/docbook/system/mann/en/ (edit.xml translate.xml): Overwrote translate.xml last commit... reverting and adding edit
20:55.35CIA-62BRL-CAD: 03bhinesley * r46225 10/brlcad/trunk/doc/docbook/system/mann/en/ (CMakeLists.txt Makefile.am edit-translate.xml):
20:55.35CIA-62BRL-CAD: Unless mged's translate command is deprecated, we'll need two sets of
20:55.35CIA-62BRL-CAD: "translate" manuals. Name the new page "edit translate", where the command will
20:55.35CIA-62BRL-CAD: display the page. Don't mention the Archer alias "translate", since the same man
20:55.35CIA-62BRL-CAD: page will be seen in mged.
20:56.16CIA-62BRL-CAD: 03r_weiss * r46226 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c:
20:56.16CIA-62BRL-CAD: Added a new function 'nmg_isect_2faceuse' to file 'nmg_inter.c' which finds the
20:56.16CIA-62BRL-CAD: intersection line between two faceuse. This new function is based on function
20:56.16CIA-62BRL-CAD: bn_isect_2planes but can better determine coplanar and parallel faceuse because
20:56.18CIA-62BRL-CAD: vertex distances to the faceuse planes are used instead of the angle between the
20:56.18CIA-62BRL-CAD: planes and the distance between the planes at their point closest to the origin.
21:19.29CIA-62BRL-CAD: 03n_reed * r46227 10/brlcad/trunk/src/conv/obj-g_new.c: minor style and ws changes
21:25.17CIA-62BRL-CAD: 03n_reed * r46228 10/brlcad/trunk/src/libgcv/wfobj/obj_parser.cpp: minor readability changes
21:38.22CIA-62BRL-CAD: 03n_reed * r46229 10/brlcad/trunk/src/libgcv/wfobj/ (obj_grammar.h.in obj_grammar.yy obj_grammar.yy obj_rules.ll): Replaced Bison parser input with Lemon parser input. Parser gives identical output for a lot of input obj files, but there are still some discrepancies that need to get worked out.
21:39.26brlcadwoot!
21:45.17CIA-62BRL-CAD: 03starseeker * r46230 10/brlcad/trunk/src/librt/primitives/ (rpc/rpc.c table.c): Add rpc bbox routine - while we're at it, make a tighter bbox instead of bounding the bounding sphere.
21:46.14starseekergo n_reed!
21:48.55CIA-62BRL-CAD: 03bhinesley * r46231 10/brlcad/trunk/src/libged/edit.c:
21:48.55CIA-62BRL-CAD: I've been using the "translate" alias to test, so I didn't notice that the
21:48.55CIA-62BRL-CAD: calling the edit command directly was recently broken. It was trying to call
21:48.55CIA-62BRL-CAD: subcommand functions of the edit help command, which don't exist. Fixed other
21:48.55CIA-62BRL-CAD: small problems with the help system. I replaced some 1-off goto's with the code
21:48.56CIA-62BRL-CAD: they were redirecting to, to please the Lords of Kobol.
21:50.00CIA-62BRL-CAD: 03r_weiss * r46232 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c:
21:50.00CIA-62BRL-CAD: Within file 'nmg_inter.c' updated function 'nmg_isect_two_generic_faces' and
21:50.00CIA-62BRL-CAD: disabled functions 'nmg_isect_nearly_coplanar_faces' and
21:50.00CIA-62BRL-CAD: 'nmg_isect_coplanar_edges' to quiet compiler errors/warnings because they are no
21:50.00CIA-62BRL-CAD: longer used. Simplified the function 'nmg_isect_two_generic_faces' which was
21:50.00CIA-62BRL-CAD: possible by using the new function 'nmg_isect_2faceuse'.
21:55.14CIA-62BRL-CAD: 03r_weiss * r46233 10/brlcad/trunk/include/raytrace.h: Updated include file 'raytrace.h' to add the new function 'nmg_isect_2faceuse'.
21:56.47CIA-62BRL-CAD: 03starseeker * r46234 10/brlcad/trunk/src/librt/primitives/rpc/rpc.c: comment doesn't apply anymore
22:02.14CIA-62BRL-CAD: 03r_weiss * r46235 10/brlcad/trunk/src/librt/bbox.c: Updated file 'bbox.c' to stop compiler errors.
22:14.48starseekerwonders if smaller rpc bounding boxes are technically user visible...
22:14.56starseekermay have minor raytrace consequences
22:49.42CIA-62BRL-CAD: 03r_weiss * r46236 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: Updated function 'nmg_ck_fu_verts' in file 'nmg_fuse.c'. Fixed a bug which caused a seg fault if a loopuse contained a single vertex instead of an edgeuse. Also did some code cleanup.
22:51.38CIA-62BRL-CAD: 03kunigami * r46237 10/osl/trunk/boost/boost/math/policies/error_handling.hpp: workaround to resolve the problem with -fno-rtti and typeid. I've commented out... it wont change the logic of the program since typeid was only used to compose a print message
22:52.31CIA-62BRL-CAD: 03kunigami * r46238 10/osl/trunk/compile.sh: osl was being wrongly build in /dest/dest/
IRC log for #brlcad on 20110818

IRC log for #brlcad on 20110818

00:26.06CIA-62BRL-CAD: 03kunigami * r46239 10/brlcad/trunk/src/liboptical/ (render_svc.cpp render_svc.h): the osl that I commited on svn defines a few more pure virtual functions. added definitons for these functions copying from /osl/src/testshade/
01:33.06abhi2011brlcad: regarding the bb function in librt, there was a issue with wdb_put_internal() always freeing the passed rt_db_internal *
01:33.28abhi2011well making the rt_db_internal * parameter constant makes no difference
01:34.39abhi2011the compiler discards the const qualifier and throws a warning : warning: passing argument 3 of ‘wdb_put_internal’ discards qualifiers from pointer target type , which is due to the same parameter not being declarared as const in wdb_put_internal()
01:35.45abhi2011so I currently allow it to be freed and look it up again afterwards using db_lookup()  and rt_db_get_internal()
01:37.28abhi2011however after this, when I try to walk the tree for a combination,  using db_functree(dbip, dp, comb_func, leaf_func, &rt_uniresource, NULL) the comb_func gets called as expected when the combination is detected
01:37.54abhi2011but the leaf_func for the leaves of the combination, is not called
01:40.16abhi2011instead db_lookup() reports missing primitives, so I don't think the primitives' information is still available for adding to the in-mem dbip , using db_functree()
01:43.04abhi2011here is the modified code : http://bin.cakephp.org/view/1374634731   not committed yet as it does not work yet
02:11.55bhinesleyabhi2011: it doesn't have to work to commit, it just has to build strict
02:29.05bhinesleyabhi2011: there must not be any solids in your combination
02:35.17bhinesleyredacts his last statement
02:35.47bhinesleyI don't know what's happening, so personally, I would examine the tree in gdb
04:07.36*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
06:56.10*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
07:44.25*** join/#brlcad kunigami (~kunigami@201.53.206.27)
09:51.45*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
10:34.10*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
10:40.29*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
11:41.44*** join/#brlcad merzo (~merzo@193.254.217.44)
11:44.45*** join/#brlcad juanman (~quassel@201.255.22.2)
11:44.51*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
11:57.49kunigamiis it possible to a script permanently set an environment variable? after building osl I'd like brl-cad to know where it is installed. any other option to do that? (maybe a config file...)
11:59.35*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:07.34*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
12:09.39starseekerkunigami: which part of BRL-CAD needs to know where osl is?
12:10.35kunigamistarseeker: the cmake at liboptical and  at other/osl/shaders
12:15.27CIA-62BRL-CAD: 03kunigami * r46240 10/osl/trunk/compile.sh: added option to compile each library alone
12:15.43*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
12:49.09starseekerkunigami: I'd suggest looking at what we do for the src/other libraries
12:49.44starseekerhowever, if it's always going to be installed first, you probably want find_library
12:50.01starseekeror write a FindOSL.cmake file
12:56.44*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
12:56.46*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:09.00CIA-62BRL-CAD: 03tbrowder2 * r46241 10/brlcad/trunk/sh/conversion.sh: added an OPATH (object path); added 's' to seconds displays; wrapped a long line for ease of checking output format
13:09.38CIA-62BRL-CAD: 03tbrowder2 * r46242 10/brlcad/trunk/NEWS: updated for change to conversion.sh
13:10.18CIA-62BRL-CAD: 03tbrowder2 * r46243 10/brlcad/trunk/NEWS: corrected my last entry
13:11.07CIA-62BRL-CAD: 03tbrowder2 * r46244 10/brlcad/trunk/NEWS: wrapped overflowing entry
13:22.58kunigamistarseeker: but src/other libraries are build together with brl-cad, so it can set cmake variables that brl-cad sees. osl is build separately and is not necessarily build in any default place or a fixed place relative to brl-cad, so unless osl itself informs cmake, I don't see how find_library or FindOSL would be able to find it
13:41.25CIA-62BRL-CAD: 03kunigami * r46245 10/osl/trunk/openexr/configure: missing pthread flag on tests
13:42.51CIA-62BRL-CAD: 03kunigami * r46246 10/osl/trunk/openexr/exrenvmap/main.cpp: missing string.h library
13:43.25CIA-62BRL-CAD: 03kunigami * r46247 10/osl/trunk/openexr/exrmaketiled/main.cpp: missing string.h library
13:44.56CIA-62BRL-CAD: 03kunigami * r46248 10/osl/trunk/oiio/src/ico.imageio/icooutput.cpp: missing zlib.h header
14:15.15*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
15:06.46*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
15:06.54*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
15:13.45*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
15:24.24starseekerFindOSL would work like any other find_package file
15:24.40starseekerassuming you're installing osl somewhere standard
15:31.31dlistarseeker, what does this mean? http://pastebin.com/hHMAsVYd
15:45.07starseekerdli: I can't see that site - can you use another pastebin?  (mozilla's should work)
15:45.37dlistarseeker, never mind, I guess it's due to gentoo cmake-utils eclass changes, fixed already
15:45.51starseekercool
15:46.29dlistarseeker, pushed to overlay, when will 7.20.4 be released?
15:46.52dlistarseeker, either I should try to make cmake work for 7.20.2 or just wait for 7.20.4
16:02.36starseekerwould recommend waiting for 7.20.5
16:02.40starseekerer 7.20.4
16:03.03CIA-62BRL-CAD: 03starseeker * r46249 10/brlcad/trunk/src/librt/primitives/ (part/part.c table.c): Add a bbox routine for part
16:06.30*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
16:06.47CIA-62BRL-CAD: 03starseeker * r46250 10/brlcad/trunk/NEWS: Tightened the bounding boxes for rpc primitives, particularly axis aligned rpcs - should slightly speed up rpc raytracing.
16:10.31*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
16:16.58*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
16:20.17*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
16:22.46*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
16:30.23*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
17:28.58*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
17:33.13*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
17:42.05CIA-62BRL-CAD: 03kunigami * r46251 10/osl/trunk/osl/src/cmake/externalpackages.cmake: on ubuntu, llvm is installed in /usr/lib/llvm-2.8/include - how to specify this path to cmake such that it works for any library version?
17:42.47*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
17:52.18CIA-62BRL-CAD: 03starseeker * r46252 10/brlcad/trunk/ (3 files in 3 dirs): epa bbox routine - also improved bounding boxes for epa, similar arrangement to the rpc.
18:02.18CIA-62BRL-CAD: 03starseeker * r46253 10/brlcad/trunk/ (3 files in 3 dirs): Add improved bounding box logic for ehy, based on epa improvements.
18:08.08kunigamiI'd like to use svn external do bring libz and libpng together with osl. Is it "svn propset svn:external https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/other/libz osl" ?
18:18.20kunigamicommand that worked: svn propset svn:externals 'https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/other/libz libz' .
18:22.39CIA-62BRL-CAD: 03starseeker * r46254 10/brlcad/trunk/src/librt/primitives/ (eto/eto.c table.c): Add bbox routine for eto.
18:24.36CIA-62BRL-CAD: 03n_reed * r46255 10/brlcad/trunk/src/libgcv/wfobj/ (obj_grammar.yy obj_parser.cpp obj_parser_state.h): storing lemon parser-handle in combined state object
18:30.50CIA-62BRL-CAD: 03kunigami * r46256 10/osl/trunk/: adding libz and libpng as external dependence of osl/trunk
18:41.52CIA-62BRL-CAD: 03kunigami * r46257 10/osl/trunk/compile.sh: added compile targets for libz and libpng
18:47.35CIA-62BRL-CAD: 03starseeker * r46258 10/brlcad/trunk/src/librt/primitives/ (hf/hf.c table.c): add an hf bbox routine - not too worried about this one as hf is on its way out.
18:48.47kunigamihmmm osl is seg faulting with the local builds :( maybe it didn't like some of the versions.
18:57.43CIA-62BRL-CAD: 03kunigami * r46259 10/osl/trunk/: svn propset svn:externals is not additive. have to specify all external dependences at once
18:59.44CIA-62BRL-CAD: 03starseeker * r46260 10/brlcad/trunk/src/librt/primitives/ (dsp/dsp.c table.c): dsp bbox routine - this is another one that has to dupliate a lot of prep, so don't double up on the work - leave the prep calculations as-is.
19:08.04CIA-62BRL-CAD: 03kunigami * r46261 10/brlcad/trunk/src/liboptical/ (liboslrend.cpp liboslrend.h osl_rt.cpp sh_osl.cpp): removed unnused code, debug messages and the old AddShader, which is not to be used
19:11.47CIA-62BRL-CAD: 03bhinesley * r46262 10/brlcad/trunk/doc/docbook/system/mann/en/edit.xml: Started manual; more specifics on the argument style are needed. WIP
19:11.52CIA-62BRL-CAD: 03kunigami * r46263 10/brlcad/trunk/src/liboptical/ (CMakeLists.txt Makefile.am osl_rt.cpp): deleting the stand-alone osl rt. It was already out-dated and it has no use since sh_osl is functional
19:12.47*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
19:16.33CIA-62BRL-CAD: 03bob1961 * r46264 10/brlcad/trunk/src/libged/erase.c:
19:16.34CIA-62BRL-CAD: This reverts the fix for r45409 (i.e. ged_splitGDL was no longer splitting
19:16.34CIA-62BRL-CAD: things correctly. This caused a noticeable performance issue as well as the
19:16.34CIA-62BRL-CAD: results of 'who' being wrong). The segmentation fault problem was resolved in
19:16.34CIA-62BRL-CAD: _ged_eraseFirstSubpath.
19:16.35plaeskunigami: it could be running against system library
19:16.58plaesldd is your friend ;)
19:17.58kunigamiyup, ldd tells me it is using brlcad version. but that was the objective. I'm testing in a system with minimal system libraries to check if the libraries we're providing are enough
19:33.36CIA-62BRL-CAD: 03starseeker * r46265 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: gah - extrude bbox logic is pretty close to worst case - don't see any immedate way to do a bbox better, so just try to do a 'self-contained' version that doesn't use stp structures and cleans up after itself.
19:34.40CIA-62BRL-CAD: 03starseeker * r46266 10/brlcad/trunk/src/librt/primitives/table.c: whoops, add to table.c
19:36.03CIA-62BRL-CAD: 03kunigami * r46267 10/osl/trunk/jpeg-8c/Makefile.in: missing file...
19:39.07starseekerhumph - the way submodel is set up, I can't do a bbox routine for it without adding an rtip parameter
19:41.51CIA-62BRL-CAD: 03kunigami * r46268 10/osl/trunk/tiff-3.9.5/Makefile.in: doh! missing file...
19:48.09CIA-62BRL-CAD: 03kunigami * r46269 10/osl/trunk/tiff-3.9.5/ (23 files in 23 dirs): hmm! actually there are a lot more Makefile.in
20:37.05CIA-62BRL-CAD: 03kunigami * r46270 10/osl/trunk/compile.sh: set linker path for linux env and make oiio use tbb
20:54.37kunigamihere's the backtrace of the segfault: http://paste.ubuntu.com/669543/ -- the program does not even finished to load... it seems to be a runtime linking error
21:00.31*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
21:31.43*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
21:37.47bhinesleystarseeker: what handles the generation of html files from docbook format? Using synopfragment tags would be really nice for my uses, but they're not getting formatted correctly.
21:38.15bhinesleyI'll take a look at it if you can point me in the right direction
21:39.12starseekerum... the docbook stylesheets probably control that
21:39.46starseekerwe haven't customized any of our output from docbook yet - that's a bit of a job
21:40.02bhinesleyseems odd that they wouldn't format their own tag correctly
21:41.07bhinesleyinvestigates
21:46.27CIA-62BRL-CAD: 03starseeker * r46271 10/brlcad/trunk/src/librt/primitives/ (cline/cline.c table.c): add bbox routine for cline
21:51.02*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
21:56.41CIA-62BRL-CAD: 03starseeker * r46272 10/brlcad/trunk/src/librt/primitives/ (superell/superell.c table.c): break out bbox logic for superell
22:16.57CIA-62BRL-CAD: 03starseeker * r46273 10/brlcad/trunk/src/librt/primitives/ (4 files in 2 dirs): metaballs already had most of the bbox functionality broken out - make it conform to the new functab setup and have it call the sphere routine itself to make it standalone.
22:45.23CIA-62BRL-CAD: 03starseeker * r46274 10/brlcad/trunk/src/librt/primitives/ (brep/brep.cpp table.c):
22:45.24CIA-62BRL-CAD: Do the simple thing with rt_brep_bbox and call the openNURBS routine - a quick
22:45.24CIA-62BRL-CAD: check results in a pretty good bbox, although we'll stick with the bvh result
22:45.24CIA-62BRL-CAD: for prep. The fact that bi->brep is NULL'ed by prep is a bit worrisome, leading
22:45.24CIA-62BRL-CAD: to questions about whether this routine will work after raytrace - why are we
22:45.24CIA-62BRL-CAD: NUll'ing the bi->brep during prep?
23:12.47CIA-62BRL-CAD: 03starseeker * r46275 10/brlcad/trunk/src/librt/primitives/ (hyp/hyp.c table.c): Go with the epa/ehy approach for hyp too. Might actually be slightly larger surface area for some views when hyp is rotated, but MUCH better than sphere for axis aligned cases.
23:40.33CIA-62BRL-CAD: 03starseeker * r46276 10/brlcad/trunk/src/librt/primitives/ (revolve/revolve.c table.c): Make a stab at implementing a stand-alone bbox function for revolve - again, too much extra logic to want to have prep call it.
23:44.08CIA-62BRL-CAD: 03bhinesley * r46277 10/brlcad/trunk/ (3 files in 2 dirs):
23:44.09CIA-62BRL-CAD: Wrote synopsis for 'edit translate'. It looks fine in brlman, but there is a
23:44.09CIA-62BRL-CAD: mysterious line break in the html manual browser, and no line breaks in several
23:44.09CIA-62BRL-CAD: places where there should be. First priority is to fix the issue. Failing that,
23:44.09CIA-62BRL-CAD: I can simply remove the synopfragment tags (which are what is breaking the
23:44.09CIA-62BRL-CAD: formatting) and rearrange things a bit. Added synopsis for 'edit', and cleaned
23:44.10CIA-62BRL-CAD: up indentation.
23:46.45*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
23:54.00CIA-62BRL-CAD: 03starseeker * r46278 10/brlcad/trunk/src/librt/primitives/ (pnts/pnts.c table.c): Points apparently don't have any prep, but go ahead and add a bounding box function.
IRC log for #brlcad on 20110819

IRC log for #brlcad on 20110819

00:34.04CIA-62BRL-CAD: 03bhinesley * r46279 10/brlcad/trunk/doc/docbook/system/mann/en/edit-translate.xml:
00:34.05CIA-62BRL-CAD: Adding a few line breaks manually to make the synopsis fragments line up (like
00:34.05CIA-62BRL-CAD: they're supposed to by default). Still not sure how to eliminate the one one in
00:34.05CIA-62BRL-CAD: between the first and second lines (also not supposed to be there by default,
00:34.05CIA-62BRL-CAD: according to examples in "DocBook 5" by O'Reilly), but it has to go.
00:52.54CIA-62BRL-CAD: 03starseeker * r46280 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c:
00:52.55CIA-62BRL-CAD: Make the minimal changes to be able to add a bbox function for pipe that doesn't
00:52.55CIA-62BRL-CAD: pass an stp pointer. Undoubtedly more optimization could be done here - the
00:52.55CIA-62BRL-CAD: bbox process doesn't need to malloc and free the lp/bp storage, at least in
00:52.55CIA-62BRL-CAD: principle) but for now go simple.
00:53.30CIA-62BRL-CAD: 03starseeker * r46281 10/brlcad/trunk/src/librt/primitives/table.c: update table.c
00:54.14starseekerbhinesley: if it looks OK in a regular browser, then it's probably tkhtml's fault
00:54.49starseekerrecalls some issue with search html...
01:01.02*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
01:05.20CIA-62BRL-CAD: 03starseeker * r46282 10/brlcad/trunk/src/librt/primitives/ (rhc/rhc.c table.c): add bbox routine for rhc - this should also do much better with axis aligned rhcs.
01:06.29*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
01:07.12starseekerphew.  probably not totally ideal, but with the possible exception of submodel I think that should cover all the primitives for which a bounding box makes sense
02:47.00CIA-62BRL-CAD: 03abhi2011 * r46283 10/brlcad/trunk/src/librt/bbox.c: Modified rt_bound_internal() to use db_functree()
04:27.26bhinesleystarseeker: it's not line breaking where it should (in any browser); but a simple fix there. However, the magic line break from nowhere only appears in the manual page browser. So it does indeed seem to be a tkhtml (er hv3) issue.
04:45.44*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
05:06.28CIA-62BRL-CAD: 03bhinesley * r46284 10/brlcad/trunk/doc/docbook/system/mann/en/edit-translate.xml:
05:06.28CIA-62BRL-CAD: hv3 was breaking the line on the first <a> tag it saw, which happened to be in
05:06.28CIA-62BRL-CAD: the middle of the synopsis. I added a dummy link around a nonprintable character
05:06.28CIA-62BRL-CAD: (to keep docbook from complaining) at the begining of the synopsis, and now
05:06.28CIA-62BRL-CAD: everyone is happy. Also, added replaceable tags around the synopsis fragment
05:06.28CIA-62BRL-CAD: references and a few other things I'd missed.
07:10.56*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
09:40.22*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
09:43.29*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
09:53.43*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
11:22.04*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:20.16starseekerbhinesley: so translate is complete?
13:13.10*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:41.33*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
14:22.25*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-177.wlan.tudelft.nl)
14:42.42*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
14:56.49starseekerreflects that someday he may have to dig deeper into the tkhtml display logic, but he dreads the prospect...
15:42.13bhinesleystarseeker: I can't find any problems with it. There is one feature that I had originally planned on which is not implemented; an oversight(using the batch operator "." as an argument to an individual coordinate specifier "-x/-y/-z"). However, it isn't actually necessary, as you can achieve the same end another way that is just as easy.
15:42.55bhinesley"translate -k -x . -a 3 7 8" is identical to "translate -k . -a -x 3"
15:44.45bhinesleya complex use "translate -k -z 3 -y . -a -z . -y 7" would have to be broken down into 2 commands
15:45.55bhinesley"translate -k . -a -y 7" and "translate -k -z 3 -a ."
15:51.50bhinesleyI don't know... what do you think?
17:23.52CIA-62BRL-CAD: 03bhinesley * r46285 10/brlcad/trunk/src/libged/edit.c: clarify/cleanup/spellcheck comments
17:26.01CIA-62BRL-CAD: 03bhinesley * r46286 10/brlcad/trunk/src/libged/edit.c: Remove temporary log of tests.
17:31.50CIA-62BRL-CAD: 03bhinesley * r46287 10/brlcad/trunk/src/libged/edit.c: Make all functions HIDDEN (except ged_edit); their scope can be changed when they're needed. Fixed one function definition that was hosed in r46285.
17:39.31*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:14.44CIA-62BRL-CAD: 03bhinesley * r46288 10/brlcad/trunk/doc/docbook/system/mann/en/edit-translate.xml:
18:14.45CIA-62BRL-CAD: brlman was doing funny things; if I'm understanding things correctly, it looks
18:14.45CIA-62BRL-CAD: like DocBook doesn't permit 'replaceable' in synopfragmentref's. In any case,
18:14.45CIA-62BRL-CAD: this fixes formatting problems and makes a complicated syntax look a little
18:14.45CIA-62BRL-CAD: clearer.
18:29.23*** join/#brlcad DarkCalff (DC@173.231.40.98)
18:33.03*** join/#brlcad Don_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
18:36.17*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:43.51CIA-62BRL-CAD: 03bhinesley * r46289 10/brlcad/trunk/src/libged/edit.c:
18:43.51CIA-62BRL-CAD: The reference manuals will point to the command "edit help" as the authorative
18:43.51CIA-62BRL-CAD: list of which subcommands are available. Therefore, only usable commands should
18:43.51CIA-62BRL-CAD: be shown. I added the capability to enable/disable commands via the command tab,
18:43.51CIA-62BRL-CAD: so that it's a simple matter of setting a flag. rotate and scale are disabled,
18:43.52CIA-62BRL-CAD: help and translate are enabled.
18:45.26*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
18:46.59*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
19:08.28*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
19:47.22*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
20:37.42CIA-62BRL-CAD: 03starseeker * r46290 10/brlcad/trunk/ (18 files in 13 dirs): OK, for the first time a successful build of 32bit on a 64bit Linux box.
21:04.57CIA-62BRL-CAD: 03starseeker * r46291 10/brlcad/trunk/CMakeLists.txt: Can't configure for 64bit then 32bit, all the find_library and find_package results are for the wrong arch. Hault configure and inform the user what needs to be done.
21:34.34CIA-62BRL-CAD: 03starseeker * r46292 10/brlcad/trunk/doc/docbook/system/mann/en/ (CMakeLists.txt edit-translate.xml edit_translate.xml): Hmm, docbook man page output was getting named edit_translate.nged, so install rule didn't know to look for it. go ahead and use edit_translate.xml for the name, fixes install issue.
22:22.12*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
23:32.52CIA-62BRL-CAD: 03abhi2011 * r46293 10/brlcad/trunk/src/mged/setup.c: Linked the simulate command to the libged wrapper and libged function in the function table
23:33.28CIA-62BRL-CAD: 03bhinesley * r46294 10/brlcad/trunk/src/librt/primitives/hf/hf.c: quiet compiler warning about unused var
23:34.43CIA-62BRL-CAD: 03abhi2011 * r46295 10/brlcad/trunk/src/mged/cmd.h: Declared the simulate command wrapper here
23:35.18CIA-62BRL-CAD: 03abhi2011 * r46296 10/brlcad/trunk/src/mged/cmd.c: Defined the simulate command wrapper here
23:40.19abhi2011hmm getting an error due to mime type not set in a new c file that I am adding : src/libged/simulate.c
23:43.06starseekerabhi2011: http://brlcad.org/wiki/Mime-types
23:43.36CIA-62BRL-CAD: 03bhinesley * r46297 10/brlcad/trunk/doc/docbook/system/mann/en/edit.xml: (log message trimmed)
23:43.36CIA-62BRL-CAD: Started on description of translate command, and realized that it would be
23:43.36CIA-62BRL-CAD: better if the edit page covered the general syntax more in depth, first. This
23:43.36CIA-62BRL-CAD: way, subcommands will be easier to digest, and maintain the manuals. I'll still
23:43.36CIA-62BRL-CAD: leave the long synopsis in the translate manual, however, to limit having to
23:43.37CIA-62BRL-CAD: flip back and forth. The edit synopsis is complete; I'll have to update several
23:43.38CIA-62BRL-CAD: key words throughout descriptions in both manuals to refer to the new terms used
23:45.23abhi2011starseeker: thanks, I will manually add the eol and mime type for now
23:47.21CIA-62BRL-CAD: 03abhi2011 * r46298 10/brlcad/trunk/src/libged/simulate.c: The Mged simulate command is implemented here(as a libged function)
23:52.20CIA-62BRL-CAD: 03abhi2011 * r46299 10/brlcad/trunk/src/libged/simphysics.cpp: The C++ code for using a physics engine will go in here
23:54.18CIA-62BRL-CAD: 03bhinesley * r46300 10/brlcad/trunk/doc/docbook/system/mann/en/edit_translate.xml:
23:54.18CIA-62BRL-CAD: Clean up the description for the translate command, and move a paragraph to the
23:54.18CIA-62BRL-CAD: edit command temporarily. This tiny translate description might actually be
23:54.18CIA-62BRL-CAD: adequate, once the edit manual is done. The main thing left for the translate
23:54.18CIA-62BRL-CAD: command is the examples, which should be mostly a cut/paste job.
23:54.51CIA-62BRL-CAD: 03bhinesley * r46301 10/brlcad/trunk/doc/docbook/system/mann/en/edit.xml: missed a file in r46300
23:54.53CIA-62BRL-CAD: 03abhi2011 * r46302 10/brlcad/trunk/include/ged.h: The libged function that implements the simulate command is declared here
23:57.18CIA-62BRL-CAD: 03abhi2011 * r46303 10/brlcad/trunk/src/libged/CMakeLists.txt: Finally, added 1 new .c and 1 .cpp file in libged to the CMake list
IRC log for #brlcad on 20110820

IRC log for #brlcad on 20110820

00:01.07bhinesleyabhi2011: you can commit all your files at once if you want to, by using a `svn commit -m "msg"` from the parent directory of the files. Perhaps do a `svn status` to see what files would be included, and `svn diff` to confirm changes first.
00:02.04bhinesleyabhi2011: just a friendly fyi, in case you didn't know :)
00:02.23abhi2011bhinseley:  thanks,  yes, being a bit careful with my first commits :)
00:02.35bhinesleyunderstandable :)
00:05.56abhi2011bhinseley: so the gsoc coding phase is over ?
00:06.42bhinesleyabhi2011: well, the official stop date is on Monday. The recommended stop date has passed.
00:07.29bhinesleyI'm writing manuals for the last command I wrote
00:07.33abhi2011ok
00:08.29abhi2011so as I understand, you were migrating commands from mged to archer , those which were left
00:12.37bhinesleyThat's correct. I migrated a few, and then I started on the oed-related commands. I suggested a complete redesign rather than simply migrating them. brlcad liked it, we expanded on it a bit more, and I've been working on it ever since.
00:13.46abhi2011cool :9
00:13.51abhi2011*:)
00:14.12abhi2011I mean :)
00:14.19bhinesleyhehe, I follow
00:14.28abhi2011german keyboards !
00:14.45bhinesleyweird layout of the keys?
00:14.59abhi2011yep : qwertz :P
00:33.56abhi2011ok so a question, I want to link to the Bullet static libraries and headers
00:34.51abhi2011bullet is installed in /usr/local/include/bullet and /usr/local/lib
00:35.22abhi2011so what are the changes I would need to make to the CMake build system to allow the proper compilation flags to be added
00:36.03abhi2011these flags must be  added  :  -I/usr/local/include/bullet  -L/usr/local/lib -lBulletDynamics -lBulletCollision -lLinearMath
03:01.57starseekerabhi2011: are you asking what to do to your local CMakeLists.txt file to build a BRL-CAD file that needs those libraries?
03:03.56starseekera "proper" way to do it would be to add a FindBULLET.cmake file, e.g. http://code.google.com/p/mgep/source/browse/trunk/CMakeModules/FindBullet.cmake?r=506
03:04.09starseekerthen call find_package(BULLET)
03:05.11starseekerhah - cool:  http://code.google.com/p/osgbullet/
03:06.17starseekeror actually, there's already a FindBullet.cmake included in CMake itself - better and better
03:06.26starseekerabhi2011: so just do find_package(Bullet)
03:06.56starseekerBULLET_INCLUDE_DIRS will hold the include directory, and BULLET_LIBRARIES will hold the libs
08:35.45*** join/#brlcad merzo (~merzo@114-136-132-95.pool.ukrtel.net)
09:43.18abhi2011starseeker: yes i am asking what to do the local CMakeLists.txt file  so I can build a BRL-CAD file that needs those libraries
10:22.18abhi2011ok its unable to find the headers still
10:23.01abhi2011i think the BULLET_INCLUDE_DIRS will have to be added to BRLCAD_INCLUDE_FILE
10:23.18abhi2011or the brlcad include path
10:23.59*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
11:01.13*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
11:45.08starseekerabhi2011: in your CMakeLists.txt, include_directories(${BULLET_INCLUDE_DIRS})
11:51.22abhi2011starseeker: ok, I am doing all the changes in the top level CMakeLists file, the one in the brlcad directory
11:51.36abhi2011in the stage 4 of 9 section , where the libs are detected
11:59.28*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:12.25abhi2011hmm BULLET_INCLUDE_DIR is not found by cmake : http://bin.cakephp.org/view/1479183805
12:12.38abhi2011is it an environment variable ?
12:12.54abhi2011if so , then its not set, I can try setting it
12:33.12*** join/#brlcad kunigami (~kunigami@201.53.206.27)
12:47.47abhi2011ok I put in the install folder manually : include_directories("/usr/local/include/bullet")
12:50.57abhi2011now the linker flags need to be inserted : -L/usr/local/lib -lBulletDynamics -lBulletCollision -lLinearMath
16:38.33abhi2011hmm I can see the FindBullet.cmake file in /usr/share/cmake/modules, will try to point CMAKE_MODULE_PATH to it
16:43.41abhi2011ok, i copied FindBullet.cmake to brlcad/misc/CMake and it has found FindBullet.cmake, but now it complains that /home/abhi/socis/brlcad/misc/CMake/FindPackageHandleStandardArgs.cmake is missing
16:44.30abhi2011probaby I should add the CMake directory /usr/share/cmake/modules instead and let find all the *.cmake files there
16:52.03abhi2011I think I will need to SET(CMAKE_MODULE_PATH "${BRLCAD_CMAKE_DIR}; "/usr/share/cmake/modules"; ${CMAKE_MODULE_PATH}") but that would not be portable
18:07.02abhi2011ok FIND_PACKAGE(Bullet) works to locate the include directories now, apparently bullet was installed in a non std location
18:08.07abhi2011linking still doesnt seem to be occurring however
23:33.53*** join/#brlcad plaes (~plaes@gn237.zone.eu)
IRC log for #brlcad on 20110821

IRC log for #brlcad on 20110821

01:12.52*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
01:12.59*** join/#brlcad Don_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
03:18.39CIA-62BRL-CAD: 03abhi2011 * r46304 10/brlcad/trunk/src/mged/titles.c: Check if illuminated solid still exists or it has been killed, illump and es_edflag both need to be checked
03:18.44*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
06:09.47*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
06:51.47*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
12:57.30CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3080 10/wiki/User:Abhijit: /* Log */
12:59.44CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3081 10/wiki/User:Abhijit: /* Log */
13:24.19*** join/#brlcad kunigami (~kunigami@201.53.206.27)
13:48.49abhi2011starseeker: is there any way to check what flags are being used by the compiler when mged is being linked during the cmake build
13:50.08abhi2011if the entire command used to compile is printed then I could make out if its looking at the wrong place for the libs with the -L option
14:48.35starseekermake VERBOSE=1
16:43.25*** join/#brlcad ibot (~ibot@rikers.org)
16:43.25*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
17:25.10abhi2011ok some progress on the linking issue
17:25.54abhi2011so in the top level cmake file I have specified : FIND_PACKAGE(Bullet)
17:25.56abhi2011LINK_DIRECTORIES("/usr/local/lib")
17:28.19abhi2011apparently include_directories("/usr/local/include/bullet") is no longer needed since I am using the FindBullet.cmake file that comes with the standard cmake modules
17:56.19abhi2011in the libged CMakeLists.txt file I have added BRLCAD_ADDLIB(libged "${LIBGED_SOURCES}" "libwdb librt libfb libbu libanalyze ${REGEX_LIBRARY} ${WINSOCK_LIB} ${M_LIBRARY} BulletDynamics BulletCollision LinearMath ")
17:56.37abhi2011and include_directories(....${BULLET_INCLUDE_DIR})
18:04.15abhi2011however when linking libged it asks for the -fPIC flag now : (btTypedConstraint.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
18:04.41abhi2011will try adding it using C_FLAGS in cmake
18:06.30*** join/#brlcad DarkCalfz (DC@173.231.40.98)
18:53.55*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:59.30CIA-62BRL-CAD: 03bhinesley * r46305 10/brlcad/trunk/doc/docbook/system/mann/en/edit.xml: The edit manual is complete, unless I think of something else to add as I'm finishing up the translate manual.
20:02.49abhi2011ok I have finally got Bullet linked with libged : http://bin.cakephp.org/view/1033978153
20:03.45abhi2011Bullet produces static libs which were causing issues while compiling libged ..related to the fpic flag
20:04.02abhi2011so now I have bullet dynamic libs
20:04.09abhi2011and libged compiled ok
20:05.01abhi2011its not recommended to link dynamically with bullet however, so have to look into why  later
20:41.35*** join/#brlcad kunigami (~kunigami@201.53.206.27)
20:47.39*** join/#brlcad DarkCalf (DC@173.231.40.98)
21:13.21*** join/#brlcad DarkCalff (DC@173.231.40.98)
21:16.39*** join/#brlcad DarkCalf (~DC@173.231.40.98)
21:23.50*** join/#brlcad merzo (~merzo@25-83-132-95.pool.ukrtel.net)
21:24.17*** join/#brlcad DarkCalf (DC@173.231.40.98)
21:25.49*** join/#brlcad DarkCalff (~DC@173.231.40.98)
21:28.32CIA-62BRL-CAD: 03bhinesley * r46306 10/brlcad/trunk/src/libged/edit.c: Deleted mock manuals for the edit command and the translate subcommand.
21:29.31*** join/#brlcad DarkCalfz (DC@173.231.40.98)
21:29.34CIA-62BRL-CAD: 03bhinesley * r46307 10/brlcad/trunk/doc/docbook/system/mann/en/edit_translate.xml: Added several examples.
21:34.47*** join/#brlcad DarkCalfz (DC@173.231.40.98)
21:36.53*** join/#brlcad DarkCalfz (DC@173.231.40.98)
21:40.06*** join/#brlcad DarkCalff (DC@173.231.40.98)
21:42.20CIA-62BRL-CAD: 03bhinesley * r46308 10/brlcad/trunk/doc/docbook/system/mann/en/edit.xml: Remove testing junk left behind.
21:42.38CIA-62BRL-CAD: 03bhinesley * r46309 10/brlcad/trunk/doc/docbook/system/mann/en/edit_translate.xml: Several corrections and clarifications.
21:43.37bhinesleystarseeker: I think that about does it for the documentation
21:58.32*** join/#brlcad DarkCalfz (~DC@173.231.40.98)
22:08.57*** join/#brlcad DarkCalf (DC@173.231.40.98)
22:29.11*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
22:29.44abhi2011yipee ! just ran a bullet simulation inside mged and it gave the right values !
22:29.48abhi2011so things have linked correctly
22:33.54CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3082 10/wiki/User:Abhijit: /* Log */
22:53.29abhi2011cant commit this code yet however because it will fail to compile on machines which do not have bullet installed or installed in a non-std location
22:54.27abhi2011have to add a condition in the libged/CMakeLists.txt file to exclude compiling simphysics.cpp if bullet is not detected
23:47.28CIA-62BRL-CAD: 03Kunigami 07http://brlcad.org * r3083 10/wiki/User:Kunigami/GSoc2011/Reports: /* Reports */
IRC log for #brlcad on 20110822

IRC log for #brlcad on 20110822

02:06.02*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
02:38.05starseekerbhinesley: excellent!
02:47.17*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
05:11.11abhi2011ok I have got objects updating inside mged now using rt_matrix_transform() according to bullet output
10:44.25*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
11:48.08abhi2011ok I was wondering how conditional compiling is implemented in the build system
11:48.43abhi2011so I have some files which are based on Bullet's libraries, but if Bullet is not installed then the compile will fail
11:49.19abhi2011yet if these files are not compiled then a function which is called from libged will not exsist and that too would cause the build to fail
11:50.05abhi2011perhaps there is a way to compile a dummy function in a separate file if bullet is not detected , so both the above errors can be avoided ?
11:53.19kunigami1abhi2011: you can do something I did for OSL. take a look at Cmakelists.txt at liboptical
11:53.39abhi2011kunigami1: thanks I ll take a look
11:59.46abhi2011ok so you use a top level cmake flag to enable or disable osl : BRLCAD-ENABLE_OSL
12:00.13*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:57.10starseekerIF(BULLET_FOUND) could be my first guess
13:07.34*** join/#brlcad Elrohir (~kvirc@p5B149541.dip.t-dialin.net)
13:50.19kunigami1abhi2011: by the way, to set the BLCAD-ENABLE_OSL flag there, you can call cmake with -DBRLCAD-ENABLE_OSL=ON
13:54.14CIA-62BRL-CAD: 03erikgreenwald * r46310 10/brlcad/trunk/src/libged/simulate.c: #if 0 out some unused code
13:54.48CIA-62BRL-CAD: 03erikgreenwald * r46311 10/brlcad/trunk/src/mged/cmd.c: remove unused variable
14:00.21*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-185-238.wlan.tudelft.nl)
14:39.24``Erikfwiw, I believe today is "pencils down" for gsoc
14:40.42``Erikabhi: awesome, very awesome
14:47.32abhi2011yep preparing the cmake logic for commit now :)
15:33.59CIA-62BRL-CAD: 03d_rossberg * r46312 10/brlcad/trunk/src/librt/ (bbox.c primitives/rpc/rpc.c):
15:33.59CIA-62BRL-CAD: For the Windows build: MSVC is not C99
15:33.59CIA-62BRL-CAD: moved variable declarations upwards
15:43.15CIA-62BRL-CAD: 03bob1961 * r46313 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): The rectangle used for selection was no longer being drawn due to a previous modification (i.e. not drawing rectangle if its lwidth is 0). This restores the desired behavior in Archer.
15:44.55plaescongrats on the new logo
16:40.40*** join/#brlcad DarkCalf (DC@173.231.40.98)
19:01.35*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:36.45brlcadstarseeker: for submodels, each callback is basically a mini program in itself meaning they have to open the subdatabase files (like rt and company) to do their processing
19:36.58brlcadresponding to backlog so comments may be OBE
19:45.27brlcadabhi2011: there should be no reason to prefer static over dynamic libraries when linking bullet (and you shouldn't be adding /usr/local/* to the default link/search paths (e.g., LINK_DIRECTORIES)) .. that's something to be specified during cmake
19:46.07brlcad(i.e. that's a "non-std" location in itself)
19:47.16brlcadplaes: thx!  it is pretty nifty
19:47.40plaesyup, nice and simple
19:53.04brlcadkunigami1: you can't export variables to a parent context so you'd have to wrap that in a script
19:53.53plaesare these images here created with brlcad: http://ronja.twibright.com/3d/ ?
19:54.07brlcadabhi2011: you can't just mark a variable as 'const' and expect it to work -- that's why I said you'd have to make a copy.  if you're calling a non-const function but need the object to remain unmodified, you have to make your own copy of that object beforehand
19:54.12brlcadplaes: yes
19:55.36plaeshow do I save such images? :)
19:57.04brlcadwhat do you mean?
19:57.56*** join/#brlcad DarkCalf (DC@173.231.40.98)
19:58.03plaeswell, I know that the models are made by brlcad, but how do I save such black-and-white images
19:58.58brlcadrtedge
19:59.17plaes\o/
19:59.20brlcadrt is the usual renderer, but there are a handful of other rt* renderes
19:59.54brlcadrt and rtedge both work within mged equivalently
20:00.04brlcadsome of the others are external to mged
20:00.14brlcadall can be run external
20:01.09plaeslots of cool stuff still hidden in all these programs ;)
20:01.22brlcadnods
20:04.36plaesbuilding stuff with primitives is like "simulating" machining.. ;)
20:06.20plaesfirst build a part on the computer and then try it out in real life - http://timmu.store20.com/galerii/?galerie=frees
20:17.45abhi2011brlcad: ok , yes I understand now
20:19.43abhi2011I was checking with the db_functree() function and i saw that it tries to lookup the primitives for a combination in the dbip which I pass to it, which is of course what it should do
20:20.31abhi2011and it fails as expected as the dbip does not have the primitive in it , as its the in mem db_i I made in the function
20:22.20brlcadplaes: that's a pretty nifty old machine there
20:22.39abhi2011so its back to square one , which is how to get union tree for the constituent primitives when passed just the rt_db_internal for a region containing those primitives
20:29.20brlcadabhi2011: that's why I said earlier that in order to call db_functree(), you need to use the unmodified dbi from the original dbip ... not your in-mem copy
20:29.50brlcadto use the inmem, you'd need to recursively call db_functree() on the original dbi and copy them into the inmem, just so you could look them up again
20:30.02brlcadbasically a big pain and probably unnecessary
20:30.25brlcadmuch easier to create a new comb, add your primitive, then have all objects go through the other existing bb routine
20:30.42abhi2011brlcad: ok yah that would work, I was trying to find a way to not pass an extra parameter as the idea was to just pass a rt_db_internal
20:31.08abhi2011yes so I tried making a comb too
20:31.14abhi2011however it needs a tree as well
20:31.27abhi2011if you lines 414 to 418 in bbox.c
20:31.32abhi2011*if you see
20:31.44brlcadyou don't need an extra parameter
20:32.18abhi2011the unmodfiied db_i is globally available then ?
20:32.35abhi2011the original db_i i mean
20:33.21brlcadI think you might be a bit confused by the different approaches being discussed
20:34.22abhi2011well there are 2 approaches : either use db_functree() or make a comb :)
20:35.10abhi2011since making a comb is easier , lets focus on that  then
20:36.14abhi2011so the idea was that make a rt_comb_internal with 1 leaf for shapes , for combinations, well they are already a rt_comb_internal
20:36.43brlcadso far, sounding good
20:36.50abhi2011ok :P
20:37.33abhi2011so the basics challenge in making a rt_comb_internal out of a shape is : the tree parameter in the rt_comb_internal structure
20:37.50CIA-62BRL-CAD: 03bob1961 * r46314 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Updated ArcherCore::selectTreePath to make the selected tree item visible.
20:38.10abhi2011or rather the tree member
20:38.12brlcadnot a challenge at all erally :)
20:38.38abhi2011umm but I would need the tree for the shape right, I cant get that from the rt_db_internal
20:38.56brlcadyou need a tree, yes
20:39.09brlcadfilling in a tree is simple
20:39.34brlcadif the rt_db_internal is already a comb, you can just access the comb's tree
20:39.50brlcadif the rt_db_internal is a primitive, you'll make a comb and add that primitive to the comb's tree
20:40.21abhi2011so something like combp->tree  = intern->tree
20:40.23brlcadsee the comb.c file, for the comb command, shows creating an rt_comb_internal and filling it in
20:40.34abhi2011where intern is the rt_db_internal
20:40.41abhi2011for the primitive
20:40.53brlcadthat doesn't look or sound right
20:41.16brlcadintern->tree is not valid
20:41.39abhi2011yes rt_db_internal does not have a tree member, so the tree in the rt_db_internal has to be accessed
20:42.01abhi2011ok that part should be easy
20:42.11brlcadIFF intern is a comb, then intern->idb_ptr is an rt_comb_internal
20:42.20abhi2011oh! :P
20:42.56abhi2011umm no I knew that
20:43.22abhi2011IFF intern is a primitive, then where is the tree , will find that out
20:43.29brlcadso you'd call something like rt_bound_tree(intern->idb_ptr->tree) if it's a comb or rt_bound_tree(my_comb->tree) if it's a primitive
20:43.29abhi2011:)
20:43.46abhi2011yes I understand that
20:44.03brlcadyou have to make my_comb
20:44.08abhi2011yes
20:44.13brlcadsee comb.c :)
20:44.19abhi2011yep :)
20:44.32brlcadyou'll need a tiny subset similar to what _ged_combadd() does
20:45.02brlcadlook for the GETSTRUCT lines to see where an rt_comb_internal is allocated
20:45.19abhi2011ok
20:46.46abhi2011by the way , on a different note,  I am curious about the other approach : that is using db_functree(), you said the original db_i need not be passed
20:47.09abhi2011so then it can be got using a global variable or a function ?
20:52.24brlcadno, I think you're misunderstanding something I was saying -- you are passed a db_i to your function -- you can just use it
20:52.32brlcadyou just need to make a copy of it if you're going to pass it to some other non-const function
20:54.55abhi2011well , the function is like this : int rt_bound_internal(struct rt_db_internal *ip, point_t rpp_min, point_t rpp_max), so there is no db_i passed
20:55.53brlcadsorry, I was using "db_i" to mean db_internal
20:56.21brlcadnot to be confused with a database instance db_i
20:56.24abhi2011oh ok , I though you meant struct db_i
20:56.28abhi2011yah i get it :)
20:57.35brlcadyou only needed a db_i to call rt_dirbuild() iirc, so that primitive bounding boxes get calculated
20:58.11abhi2011yes, this db_i however was constructed from the original .g database file
20:58.20abhi2011so it had all the primitives
20:58.21brlcadthat approach is still fine, it's just combs that are even simpler with rt_bound_tree(ip->idb_ptr->tree)
20:58.41abhi2011yes
20:58.46abhi2011<PROTECTED>
20:59.00abhi2011meanwhile, I got bullet running in mged
20:59.04abhi2011and the cmake logic done
20:59.08brlcadoutstanding
20:59.33abhi2011about to commit that : had some changes to top level cmake file , hope starseeker is standing by :P
20:59.35brlcadsounds like more work is needed on the cmake logic, but shouldn't be too difficult
20:59.48brlcadwhat's the diff look like?
21:00.05abhi2011I ll pastebin it 1 sec
21:01.19abhi2011basically added logic to compile a dummy simulate.c file that does nto bullet headers, if bullet is absent
21:01.46abhi2011in the top level there is logic to find the bullet library and link /usr/local/lib
21:03.10brlcadpresuming you saw my earlier comment, assuming /usr/local/lib is no good
21:04.04abhi2011oh ok, I think I missed that
21:04.31abhi2011reading now :)
21:04.40brlcadI mean, /usr/local is probalby the only "non-default" system locations that could be added, but adding it should be systematic for include headers, libs, and bins
21:05.11brlcadand it still shouldn't be subdir aware like /usr/local/lib/bullet/.
21:06.03brlcadlibs not in "system" paths should be declared to cmake or handled by some Find*.cmake routines
21:07.46abhi2011ok, I would have thought that /usr/local/lib would be searched by default by cmake
21:07.57abhi2011so I would not need to specify it
21:08.18abhi2011well I am using the stock FindBullet.cmake module
21:09.09abhi2011its installed by cmake, and it finds and sets the ${BULLET_INCLUDE_DIR},  ${BULLET_LIBRARIES} correctly
21:09.44abhi2011but its not setting the ${BULLET_LIBRARY_DIR} variable, which is what I would link to , to keep things standard
21:10.35abhi2011here is the top level CMakeLists.txt diff : http://bin.cakephp.org/view/1810550039
21:10.46abhi2011will try to get rid of LINK_DIRECTORIES("/usr/local/lib")
21:13.17abhi2011this is the libged/CMakeLists.txt file that also required changes : http://bin.cakephp.org/view/860235467
21:16.44abhi2011ok , so I am thinking maybe I can remove the LINK_DIRECTORIES("/usr/local/lib") line in the top level CMakeLists.txt file
21:17.09abhi2011as long as a user does not enable bullet , the rest of the build will be fine
21:17.27abhi2011if he does enable bullet, then there will be a linking error
21:17.53abhi2011so the exact location where the user has installed the libs can be specified using a cmake command line flag
21:18.20abhi2011that would eliminate any hardcoded library paths
21:21.55abhi2011of course that begs the question as to why ${BULLET_LIBRARY_DIR} is not being set by the stock FindBullet.cmake module , its probably not looking at the right place
21:26.28brlcadso several comments
21:26.50brlcadsure, searching /usr/local/lib might be expected .. but that has nothing to do with bullet and shouldn't be part of your patch/commit
21:27.12brlcadcertainly shouldn't be specific to an if(BRLCAD-ENABLE_BULLET) section
21:27.58brlcadwhich brings up my second point, and enable/disable toggle for that seems unnecessary -- it should test for bullet and, if found, use it.  otherwise, the command implementation is disabled at compile-time
21:30.08abhi2011brlcad: ok I understand
21:30.26brlcadabhi2011:  you also do not need simulatedummy.c -- that should be logic contained within the simulate.c file (#ifdef) OR put it all in a subdir with it's own CMakeLists.txt file
21:30.45brlcadprobably should put it all in a subdir anyways just because you have multiple implementation files
21:31.13abhi2011ok , yes that will be easier
21:32.25abhi2011yes I thought about the #ifdef , but I havent found a compile time symbol that is defined if bullet was found
21:33.38abhi2011ok,  I think there will be some symbol which will be defined if the bullet headers are detected, will go through the headers
21:33.48brlcadif one is not defined, you can define one
21:33.59brlcadbut make sure one isn't already defined
21:34.04abhi2011yes, but bullet is detected by cmake
21:34.16brlcadyes, so? :)
21:34.20abhi2011i cant define a symbol to be used in a c file , in the cmake logic
21:34.26brlcadsure you can
21:34.29abhi2011umm...but as usual i am off mark :P
21:34.37abhi2011ok thats totally cool :)
21:34.56abhi2011ok will find out about it
21:35.15brlcadsee include/brlcad_config.h in your build directory for a list of symbols already being defined during cmake
21:35.26abhi2011ok
22:02.07*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
22:15.15*** join/#brlcad kunigami (~kunigami@201.53.206.27)
23:00.39*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
23:28.47CIA-62BRL-CAD: 03brlcad * r46315 10/brlcad/trunk/src/libged/edit.c: quellage, may be unitialized
IRC log for #brlcad on 20110823

IRC log for #brlcad on 20110823

00:19.38*** join/#brlcad kanzure_ (~kanzure@131.252.130.248)
00:59.51CIA-62BRL-CAD: 03starseeker * r46316 10/brlcad/trunk/ (41 files in 39 dirs): (log message trimmed)
00:59.51CIA-62BRL-CAD: Stub in a way for view information to be passed to plot routines. Inactive at
00:59.51CIA-62BRL-CAD: the moment, and the struct being passed in just has a single token value - this
00:59.51CIA-62BRL-CAD: is setting up the path through which information can be passed, not actually
00:59.51CIA-62BRL-CAD: doing it (yet). This will introduce a binary compatibility, so it may need to
00:59.52CIA-62BRL-CAD: be reverted, but I'm committing it at this time to preserve the information for
00:59.53CIA-62BRL-CAD: future use; the commit diff is a good starting point when determing what
02:04.48*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
02:13.51starseekercrud s/compatibility/incompatibility
02:15.47abhi2011ok I have modified the cmake logic and put the simulation files in libged/simulation
02:16.30abhi2011added 1 symbol to indicate bullet was found or not
02:27.45abhi2011here is the diff of the 3 cmake files, 2 existing, 1 added  : http://bin.cakephp.org/view/295759995
02:29.39abhi2011minimal changes to the top level file
02:30.36starseekerabhi2011: you don't need the MESSAGE line for the Bullet find pakage
02:30.38starseekerpackage even
02:31.56brlcadstarseeker: hm
02:31.57starseekeralso, I would expect the BRLCAD_ADDLIB line to use "${BULLET_LIBRARIES}" instead of individually listing them - does that not work?
02:32.03brlcadisn't scale sufficient?
02:32.29starseekerbrlcad: not for what I'm experimenting with at the moment
02:32.38starseekerif that doesn't pan out, then possibly
02:32.44abhi2011starseeker: ok I will remove the message line
02:33.09brlcadI'd had similar thoughts to add view information to the plot callback for levels-of-detail, but data-wise the callback still only needs a single scaling factor
02:33.41abhi2011well ${BULLET_LIBRARIES} contains the static libraries with the .a extensions as thats what applications normally use
02:34.06abhi2011however when I tried linking against the static libraries I was getting an error related to the -fPIC flag
02:34.12starseekerbrlcad: I'm experimenting with some view-dependent logic at the moment - too early to know if it's viable or not
02:34.37abhi2011I ll try it once more, though I think -static needs to be specified when compiling mged
02:34.48abhi2011to alllow bullet to link to it statically
02:35.04brlcadstarseeker: er, like rtedge-style plotting?
02:35.27starseekerbrlcad: no, some level-of-detail stuff for bots
02:35.48abhi2011starseeker: therefore I compiled the dynamic libs for bullet with .so extensions and use those which requires individually specifiying the libs
02:35.59starseekerbrlcad: I can revert that commit if it's a problem - it's way too early to know if what I'm thinking will work or not
02:36.10brlcader, but how is it view-dependent (beyond scale)
02:36.37starseekerview direction and matrix
02:36.55starseekerwindow size, etc
02:37.06brlcadbut how? :)
02:37.25brlcadwindow size I can see easily, but that is encompassed by scale
02:37.27starseekersigh... OK, fine:  http://vdslib.virginia.edu/
02:38.22starseekerknew he shouldn't have committed that...
02:38.33brlcadi'm not looking for a bunny out of a hat, I'm really just curious how
02:38.48brlcadLoD doesn't need view dir
02:39.27starseekerthis isn't a standard "decimate the mesh" approach - http://www.cs.virginia.edu/~luebke/publications/pdf/vds.cad.pdf
02:41.00starseekerthe 1.0 code apparently isn't around anymore, but thanks to debian an earlier version is:  http://bzflag.bz/~starseeker/vdslib-0.9-6.1.tar.gz
02:41.28starseekeris looking at the polyview example app they have in there, and intending to do what they're doing with bots and vlists
02:42.22abhi2011ok I have modified libged/simulation/CMakeLists.txt  to link to the static libs but I get an error : http://bin.cakephp.org/view/372893931
02:42.27abhi2011same one as before
02:43.01starseekergot libvds, libstdvds and polyview compiling today, and polyview kinda worked
02:43.02abhi2011something to with 32 bit libraries on 64 bit platforms
02:43.57starseekerabhi2011: urm.  what does the file command tell you about your bullet libraries?
02:45.36starseekerbrlcad: it may be that once I fully understand what vds is doing scale will turn out to be sufficient for our needs, but I was going to first verify in the most straightforward way I could that I could duplicate what polyview is doing inside MGED
02:46.56abhi2011libBulletCollision.a   gives : libBulletCollision.a: current ar archive
02:47.10starseekerhmm
02:47.19abhi2011libBulletCollision.so.2.78: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
02:47.36abhi2011those are the static and dynamic counterparts of the same basic library
02:47.42brlcadstarseeker: interesting approach, I hadn't seen that paper before (or at least not that I remember)
02:47.45starseekerOK, but the bullet find_package isn't returning the dynamic lib?
02:48.13abhi2011no , the stock FindBullet.cmake does not
02:48.25brlcada quick read through the paper, there are several issues it claims that are somewhat non-issues these days (e.g., memory use for the lod)
02:48.55abhi2011I could make a FindBullet.cmake specifically for returning dynamic libs
02:49.01brlcadand issues caused by his approach (distant object popping, trouble with the folding)
02:49.01starseekerbrlcad: I got triggered by a comment from Bob when he was working with one of the big BoT models about how the interactivity sucked so bad, so I went hunting this weekend for something that might be viable (since it's for sure anybody dealing with a big BoT model would have the same issue)
02:49.16starseekerabhi2011: that might be worth doing
02:49.36starseekerabhi2011: we do custom Find*.cmake files when the stock ones don't suffice - there are several in misc/CMake
02:50.19starseekerbrlcad: yeah, the mesh probably won't be perfect, but if it's "close enough" and interactive it will beat the heck out of one refresh every 30 sec. when zooming
02:50.27abhi2011ok yes I can make a custom one, I wonder whats up with the compiler though, it should have allowed static linking
02:50.48starseekerabhi2011: are you compiling 32 or 64 bit? (-m32 or -m64?)
02:51.06abhi2011maybe  bullet builds the 32 bit version by default
02:51.06brlcadabhi2011: the subdir should match the command name
02:51.14starseekerbrlcad: apparently it was a SIGGRAPH thing back in the late 1990s
02:51.21starseekers/thing/paper
02:51.31abhi2011starseeker: i avent checked that , will check now
02:51.37brlcadstarseeker: I noticed
02:51.46abhi2011brlcad: ok I ll change it
02:51.51starseekerwas hoping to try it before he got told why it wouldn't be a good idea :-P
02:51.58brlcadheh
02:52.48brlcadit's not evidently a bad idea, just odd -- not many folks did research on view-dependent LoD
02:52.48starseekerit took a little time to propagate the rt_*_plot change, and I didn't want to leave it uncommitted, so I figured do it in one fell swoop that could be easily undone
02:53.13brlcadand from my quick read, it's still not entirely clear that it is exactly view-dependent from our plot-perspective
02:53.48starseekerit might not be - I was going on what the polyview app was feeding via vds functions
02:53.49brlcadyou feed an initial mesh at a given LoD along with the view params, then it generates a quadree simplification based on the current view
02:55.22starseekerright - but since our plotting routines call the functab for each primitive to get the lines to draw, I was assuming that the simplification output (in vlist form) was what would need to come back from rt_bot_plot
02:55.29brlcadyou could still keep plot view agnostic, returning a plot at some predetermined scale, then have a function churn through the view-dependent simplification
02:56.10starseekermaybe, but that starts to get deep into the tangle of code that is the draw logic
02:56.25starseekerwas trying to stay below that rats nest, at least for the first trial
02:56.53brlcadthat's where injecting view-dependent information is going to be a mess ... plot() for some of the prims is already a nightmare
02:57.10brlcadbut yeah, that seems to be the way the algorithm wants it anyways
02:57.16brlcadyou got to have the mesh to start with
02:57.17starseekerbrlcad: but we don't have to use it unless we want to
02:57.31brlcadhm?
02:57.36starseekerfor now, every primitive except BoT will totally ignore the view info
02:58.37brlcadthat's my point, though -- the algorithm doesn't know or care about object types, and shouldn't need to
02:58.44starseekerthe main problem I was looking at was caching the vds tree
02:58.55brlcadthe same logic that'd let you simplify a bot will simplify any plot() data set
02:58.56starseekeruh... which algorithm?
02:59.04brlcadthis view-dep lod paper
02:59.07starseekeroh - not sure about that, actually
02:59.14starseekerit may need face data as well as edges
02:59.29brlcadsure, it wants manifold surfaces
02:59.39brlcadseveral  of the plot impls go through nmg anyways
02:59.56starseekersure, so for those it might be viable - but (say) ell or eto won't care
03:00.12starseekerwasn't going to tangle with nmg in the first round
03:01.47brlcadthat's actually a good point
03:01.55brlcadthe paper did require topology
03:02.45brlcadwhich .. BoTs ain't got
03:03.01brlcadtess() would be more appropriate than plot()
03:04.04brlcadthen it is back to being agnostic to entity type
03:04.40brlcadthat said.....
03:04.58brlcadbob's problem is fixed with a *very* simple scale-based LoD reduction :)
03:05.34starseekerexcept how do we know how to draw the bots at various scales?
03:05.45starseekerthis seemed like a systematic way to address that cleanly
03:07.13brlcadeasy, you pass the scale you want to the bot
03:07.27starseekerand then the bot does... what?
03:07.38brlcadif the super-detailed bot is being drawn tiny, the scale factor will be tiny
03:08.11starseekerright, but that still begs the question of which subset of edges from the BoT to draw at that scale
03:08.21brlcadthe scale factor is basically used to collapse edges or introduce new edges
03:08.44brlcadso at scale near zero, it's a point or a single tiny vlist segment
03:09.00brlcadat near one, it's whatever "full detail" means
03:09.04starseekerright, but the details of that collapsing are the difficulty
03:09.18starseekerthat problem is probably a subset of what vds is doing, actually
03:09.21brlcadyou have that info directly from the scale value
03:09.28brlcadthat scale is in relation to the model size
03:09.50brlcadso tessellating as we do now, we make ton's of segments that are effectively all overlapping
03:10.11brlcaddetecting that next_point == curr_point within tolerance is easy
03:10.27brlcadwe just don't/didn't even have the scale to even know that
03:11.45starseekerisn't sure next_point == curr_point is enough, but I suppose I don't understand enough about how plot is doing its drawing
03:12.13starseekerbbiab
03:12.14brlcadit's not really == .. it's within tolerance given the current scale
03:12.56brlcadNEAR_EQUAL(curr_point, next_point, collapse_distance)
03:15.30brlcadthe only thing you don't explictly know with just a scale size is the number of pixels since that's really what (should) drives the edge collapse
03:16.33brlcadso you encode that implicitly in the scale (e.g., 1.0 immplies 1024x1024 spacing of edges scaled to that object's bbox)
03:16.56brlcador you pass the interpixel spacing (i.e., the collapse_distance) instead of scale
03:19.57brlcadOR you pass both and you get arbitrary on-demand LoD :)
03:20.22brlcadabhi2011: ../../../src/libged/simulate.c:63:1: error: C++ style comments are not allowed in ISO C90
03:28.31abhi2011brlcad: yes I removing those comments
03:30.06brlcadstarseeker: another thought -- you could get a boost within libdm itself, agnostic to any primitive plot() implementation
03:32.31brlcadlibdm knows the view size and pixel size so there are several optimizations that could be made right off the bat -- like not even calling plot if object is smaller than a pixel, and reducing the plot vlist eliminating edges that are less than half a pixel distance in length
03:33.52brlcadthat's probably a couple hours effort in an afternoon to get something that simple working .. hmm!
03:38.54brlcadlooks like drawH_part2() is where the action is at
04:03.46CIA-62BRL-CAD: 03brlcad * r46317 10/brlcad/trunk/doc/docbook/system/mann/en/Makefile.am: file was renamed to edit_translate.xml
04:26.24CIA-62BRL-CAD: 03brlcad * r46318 10/brlcad/trunk/include/ (bu.h magic.h raytrace.h): if NO_BOMBING_MACROS is enabled, then it will leave empty if-statements throughout the code making the compiler unhappy. sacrifice a no-opish ((void)0) to keep the compilation gods happy.
05:15.35CIA-62BRL-CAD: 03brlcad * r46319 10/brlcad/trunk/src/libged/Makefile.am: update Makefile.am at the same time as CMakeLists.txt, add simulate.c and simphysics.cpp to unbreak autotools build.
05:16.08CIA-62BRL-CAD: 03brlcad * r46320 10/brlcad/trunk/src/tclscripts/mged/CMakeLists.txt: no packages presently exist in mged dir
05:26.04plaeshum.. how do I "exit" from oed back to the viewing state?
05:26.30*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
05:30.13plaesaha.. reject
05:33.52CIA-62BRL-CAD: 03brlcad * r46321 10/brlcad/tags/zlib_1_0_4/: there is no reason for keeping a tag of zlib 1.0.4
05:45.58brlcadpressing escape in the graphics window will do it too
05:57.59CIA-62BRL-CAD: 03brlcad * r46322 10/brlcad/tags/ (12 files in 12 dirs): similarly no reason to keep around the old cvs branch tags that were useful for tracking branch start points, end points, and branch termination. relegated the legacy into svn history.
06:23.48plaeshmm.. rtwizard doesn't set the path properly
07:15.20*** join/#brlcad merzo (~merzo@193.254.217.44)
07:25.09CIA-62BRL-CAD: 03d_rossberg * r46323 10/brlcad/trunk/CMakeLists.txt:
07:25.09CIA-62BRL-CAD: quell cmake warning
07:25.09CIA-62BRL-CAD: and apparently trimmed trailing spaces
07:25.18*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:57.09*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
08:20.48*** join/#brlcad Unknown_Monkey (~max@netblock-208-127-49-10.dslextreme.com)
08:22.38Unknown_Monkeyhey I installed brlcad on my ubuntu machine and when i run mged and I draw a cone or anything It doesnt show up the screen is blank and when I click on the window the cone drawing shows up but then it disappers
08:24.37*** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862)
08:27.30Unknown_MonkeyDarkCalf: can you help me
12:19.46CIA-62BRL-CAD: 03brlcad * r46324 10/brlcad/tags/ (itcl3-2/ libpng_1_0_2/ tcl8-3/ tk8-3/): revmoed additional 3rd party dependencies that don't really belong amongst our other tags
13:09.05*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:35.15CIA-62BRL-CAD: 03abhi2011 * r46325 10/brlcad/trunk/src/libged/simulate.c: Removed C++ style comments in C file to conform to C90
13:37.36CIA-62BRL-CAD: 03abhi2011 * r46326 10/brlcad/trunk/src/libged/simphysics.cpp: Changed mode to C++ in the file style section at the bottom
13:41.17CIA-62BRL-CAD: 03n_reed * r46327 10/brlcad/trunk/src/conv/obj-g_new.c: Fixed missing header and implicit return statement that g++ complained about.
13:42.43CIA-62BRL-CAD: 03brlcad * r46328 10/brlcad/tags/ (10 files in 10 dirs): more removal of cvs branching artifacts where it was necessary to tag before and after merging, pushed into the depths of svn history
14:07.26CIA-62BRL-CAD: 03n_reed * r46329 10/brlcad/trunk/src/libgcv/wfobj/ (10 files): Replaced flex scanner with re2c equivalent.
14:12.51starseekerwoot!
14:13.17starseekerditches view stuff and hits the re2c/lemon logic
14:16.07CIA-62BRL-CAD: 03starseeker * r46330 10/brlcad/trunk/src/other/ (CMakeLists.txt byacc/ flex/ m4/): We're not using them right now, re2c/lemon work is progressing, and svn has our back if we have to return to this route - clear out m4/byacc/flex
14:31.24CIA-62BRL-CAD: 03starseeker * r46331 10/brlcad/trunk/src/other/ (450 files in 13 dirs): Check in vanilla copies of re2c-0.13.5 and the latest lemon from sqlite.org. No build system logic yet, baselining with the vanilla sources.
14:40.27CIA-62BRL-CAD: 03starseeker * r46332 10/brlcad/trunk/src/other/ (20 files in 3 dirs): Add first stages of CMake logic for re2c and lemon building
14:59.43CIA-62BRL-CAD: 03starseeker * r46333 10/brlcad/trunk/ (4 files in 2 dirs): Add more CMake logic for re2c/lemon, this time relating to deciding whether or not to build local copies - this is Not Done, particularly the FindRE2C and FindLEMON files, but checkpointing.
15:18.34*** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no)
15:30.48CIA-62BRL-CAD: 03bob1961 * r46334 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Updated Ged::pane_mouse_ray to calculate the mLastMouseRayStart point (i.e. the point from which to fire a ray) so that all displayed geometry is in front of the ray firing point.
15:36.28abhi2011ok I have modified the cmake logic to detect bullet dynamic libs
15:36.37abhi2011all I had to do was remove the static libs
15:36.44abhi2011time for a whoosh! commit
15:37.06brlcadabhi2011: try to commit incrementally if you can without breaking the build
15:37.15abhi2011brlcad: ok :P
15:37.20brlcadlike one commit moves the files into a subdir, another fixes the bullet rules, etc
15:37.45brlcadyou shouldn't move modified files, for example
15:38.17brlcadedit, commit, then move, commit OR move, commit, then edit, commit
15:40.03abhi2011ok I have deleted 2 files : simulate.c and simphysics.cpp in libged however
15:40.20abhi2011moved them to libged/simulate directory
15:40.50abhi2011ok for those 2, I ll commit last
15:40.54brlcadthat's wrong  
15:41.10brlcadsvn will handle the move for you, and is preferred because it will preserve the commit history
15:43.04brlcadcd src/libged && svn revert simulate.c simphysics.cpp && mv simulate simulate.backup && mkdir simulate && svn add simulate && svn commit -m "stub in simulate dir" simulate && svn mv simulate.c simulate/simulate.c && svn mv simphysics.cpp simulate/simphysics.cpp && .... etc
15:43.42abhi2011ok
15:44.26CIA-62BRL-CAD: 03brlcad * r46335 10/brlcad/tags/ (merge-to-head-20051223/ stable-branch/): move cvs branch tagging artifact removal
15:45.07abhi2011ok then I ll checkout fresh again , and do the changes one by one
15:47.42abhi2011hmm, no i think just deleting the simulate directory and recreating through the commands you gave should be enough, ok will do that
15:47.57CIA-62BRL-CAD: 03brlcad * r46336 10/brlcad/tags/temp_tag/: remove what looks like a tag related to the merging of the bobWinPort work, some artifact tag that was retained through conversion from cvs.
15:52.03CIA-62BRL-CAD: 03brlcad * r46337 10/brlcad/tags/CMD/: nice.. remove very old version of remrt that was tagged in the early 90's. nice and easy to read.
15:56.45CIA-62BRL-CAD: 03brlcad * r46338 10/brlcad/tags/help/: remove mysterious 'help' tag from 7.8, no apparent purpose and certainly no need to keep it around now
16:03.56CIA-62BRL-CAD: 03abhi2011 * r46339 10/brlcad/trunk/src/libged/simulate/: stub in simulate dir
16:10.08CIA-62BRL-CAD: 03abhi2011 * r46340 10/brlcad/trunk/src/libged/ (5 files in 2 dirs): stub for 2 files moved to simulate dir
16:13.20CIA-62BRL-CAD: 03abhi2011 * r46341 10/brlcad/trunk/src/mged/cmd.c: stub for simulate cmd wrapper modification
16:23.12CIA-62BRL-CAD: 03brlcad * r46342 10/brlcad/tags/Original/: remove '98 tagging of the html docs
16:27.27CIA-62BRL-CAD: 03brlcad * r46343 10/brlcad/tags/release-7-0/: clearly not actually release 7.0 .. remove the cvs tag relic that was made on a few files just before the project was converted to open source.
16:30.44CIA-62BRL-CAD: 03brlcad * r46344 10/brlcad/tags/rel-5-0beta/: remove the rel-5-0beta cvs-to-svn relic as it's not actually the 5.0 beta release. the rel-5-0-beta tag has that so this one that just has tcl/tk can get gone.
16:31.29brlcadand with that, our tags should now be all in order, each representing some snapshot in time for a given production
16:40.40CIA-62BRL-CAD: 03abhi2011 * r46345 10/brlcad/trunk/CMakeLists.txt: Added detection of bullet dynamic libraries using the stock CMAKE FindCMake.cmake module
16:42.59*** join/#brlcad plaes (~plaes@gn237.zone.eu)
16:45.01CIA-62BRL-CAD: 03abhi2011 * r46346 10/brlcad/trunk/src/libged/ (4 files in 2 dirs): Changes in the CMake build logic and source files to allow the simulate command to link to bullet
16:45.22abhi2011and that completes the changes to link to bullet for the mged simulate command
16:46.37abhi2011hope I didnt break anything
16:52.26abhi2011so if anyone installs bullet (has to be told to specifically compile shared libs) and tries out the simulate command then let me know :)
17:02.36CIA-62BRL-CAD: 03n_reed * r46347 10/brlcad/trunk/src/libgcv/wfobj/Makefile.sample: Adding local makefile to demonstrate necessary build steps.
17:42.33*** join/#brlcad molto_crescendo (~molto_cre@BZ.BZFLAG.BZ)
17:42.57brlcadI wonder
17:43.45molto_crescendookay
17:49.48starseekerbrlcad: wonder... what?
17:50.10brlcadstarseeker: never mind :)
17:51.13starseekerheh - k
18:00.25starseekerwheee - that was fun!
18:10.02CIA-62BRL-CAD: 03starseeker * r46348 10/brlcad/trunk/src/other/lemon/CMakeLists.txt: need lempar.c in the same directory as the lemon binary
18:10.48molto_crescendoyep, same directory
18:11.18CIA-62BRL-CAD: 03brlcad * r46349 10/brlcad/trunk/src/other/Makefile.am: bison/flex/m4 removed, stay in sync with CMakeLists.txt
18:12.27CIA-62BRL-CAD: 03brlcad * r46350 10/brlcad/trunk/src/other/Makefile.am: add lemon and re2c dirs
18:16.59brlcadabhi2011: nice work regardless, hopefully get a chance to test it later this wek
18:17.03brlcads/wek/week/
18:23.35``Erikweeeee, earthquakes
18:23.36brlcadabhi2011: one cleanup, the "
18:24.27brlcadabhi2011: the simulate "library" can just be named simulate (not libgedsim) since it's not intended to be installed/used as a standalone library but as a module to libged
18:25.01abhi2011brlcad:  ok
18:49.39*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:28.50CIA-62BRL-CAD: 03starseeker * r46351 10/brlcad/trunk/ (391 files in 59 dirs): Get the new obj-g building as part of BRL-CAD.
19:29.20CIA-62BRL-CAD: 03brlcad * r46352 10/brlcad/trunk/TODO:
19:29.21CIA-62BRL-CAD: primitive testing has uncovered off-by-one raytrace errors during identical
19:29.21CIA-62BRL-CAD: subsequent invocations of rt due to some floating point issue during parallel
19:29.21CIA-62BRL-CAD: processing. single processor results in zero errors yet parallel gives subtle
19:29.21CIA-62BRL-CAD: changes. should investigate to see if there's a code issue though the problem
19:29.21CIA-62BRL-CAD: persists back as far as at least 7.8 (on 64-bit Linux).
19:38.03brlcadstarseeker: I presume you put boost there because of conflicts or uncertainty with src/other/boost ?
19:41.13starseekeryep
20:58.45*** join/#brlcad Elrohir (~kvirc@p5B14AEDB.dip.t-dialin.net)
20:59.49CIA-62BRL-CAD: 03starseeker * r46353 10/brlcad/trunk/src/other/boost/ (88 files in 30 dirs): Clear old boost libs
21:22.25CIA-62BRL-CAD: 03n_reed * r46354 10/brlcad/trunk/src/libged/ (CMakeLists.txt simulate/CMakeLists.txt): get the build working - probably not the 'right' fix (starseeker)
21:40.51CIA-62BRL-CAD: 03n_reed * r46355 10/brlcad/trunk/src/mged/setup.c: Need to use HAVE_BULLET in mged too - no ged_simulate, no simulate command.
21:52.46CIA-62BRL-CAD: 03n_reed * r46356 10/brlcad/trunk/src/conv/obj-g_new.c: Removed obsolete debug output.
22:00.40CIA-62BRL-CAD: 03n_reed * r46357 10/brlcad/trunk/src/libgcv/wfobj/obj_rules.re: Removed obsolete debug output.
22:30.31CIA-62BRL-CAD: 03starseeker * r46358 10/brlcad/trunk/src/other/boost/ (1467 files in 127 dirs): add the bcp reported subset of boost 1.47 needed for spirit.hpp. Made a quick stab at CMakeLists.txt build logic for the libs, not sure if it's right.
22:33.30CIA-62BRL-CAD: 03starseeker * r46359 10/brlcad/trunk/src/libpc/CMakeLists.txt: because we have both boost and libs dirs now, include src/other/boost not src/other
22:36.31molto_crescendoexit
22:38.30*** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl)
22:39.37*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
22:45.28bhinesleyhmm... playing around with Blender. There is a setting to "manipulate object centers only". I didn't think of allowing translations based on angles (without actually rotating the object being translated).
22:46.08brlcadbhinesley: not sure I follow
22:46.30brlcada translation based on an angle means what exactly?
22:47.34brlcadlike only translating against an object's local coordinate system instead of global?
22:48.15brlcadso a box tilted 45 degrees and translated "by x" would go "up" at a 45 degree translation?
22:48.20bhinesleybrlcad: hard to explain. In Blender, you can set your 3d cursor where you would like the center of a rotation to take place. Then you enable "manipulate object centers only". When you "rotate", you're not really rotating. You're just moving the object to some other point.
22:48.52bhinesleybrlcad: no, it does local vs. global translations too, but that's not what I'm refering to.
22:49.27brlcadyeah .. okay .. confused then :)
22:51.30bhinesleybrlcad: say you place a box at 1,0,0 and the center of rotation at 0,0,0. If you rotate the box 90 degrees on the z-axis, you'll end up at 0,1,0 with the cube still facing the same directions.
22:51.40brlcadfinds http://blenderunderground.com/blender-3d-faq/#mi_centers to be unhelpful
22:52.24brlcadahh, good example
22:53.40brlcadsounds like a flag to the rotate command ;)
22:53.57brlcador a different "pivot" command
22:54.29brlcadsince you're really pivoting around a point, seems apropos
22:55.17bhinesleynods
22:55.36bhinesleyrotate is already too complex
22:57.03bhinesleyto the user it would "feel" like a special type of rotation, but under cover a pivot command would just call translate.
22:57.41brlcador call rotate twice
22:57.58bhinesleyhmm, not a bad idea.
23:02.13bhinesleycould be used to create polar arrays (i.e. lugnuts on a wheel)
23:02.38brlcadthe existing pattern tool already does that albeit manually in the implementation
23:03.06brlcadspherical and cylindrical
23:03.14bhinesleyah, nice
23:04.25bhinesleybrlcad: what is it called? is it in Archer?
23:04.26CIA-62BRL-CAD: 03brlcad * r46360 10/brlcad/trunk/TODO: potential lead, -B works with parallel enabled so something fishy is going on. possibly conversion from float to double ... but random numbers should not be involved!
23:04.45brlcadbhinesley: the interface is just atrocious
23:04.49brlcadso it's in mged ;)
23:05.22brlcadPattern tool under the Tools menu
23:05.27bhinesleyah, I see, thanks
23:07.16CIA-62BRL-CAD: 03starseeker * r46361 10/brlcad/trunk/src/ (CMakeLists.txt util/CMakeLists.txt): libpc ain't happy about the boost change - turn it off for now.
23:14.07CIA-62BRL-CAD: 03starseeker * r46362 10/brlcad/trunk/src/libgcv/wfobj/ (CMakeLists.txt boost_shared_ptr/): Well, can now use src/other/boost for obj-g anyway...
23:23.57CIA-62BRL-CAD: 03starseeker * r46363 10/brlcad/trunk/src/other/boost/boost/spirit/ (32 files in 11 dirs): hmm - may not have gotten everything. bcp --scan of the libpc headers resulted in a few more boost files.
IRC log for #brlcad on 20110824

IRC log for #brlcad on 20110824

00:29.04CIA-62BRL-CAD: 03starseeker * r46364 10/brlcad/trunk/CMakeLists.txt: Since it's proving convenient to make a build directory in the src dir for a cmake .. build, ignore the two most common cases when doing cpack
01:39.49CIA-62BRL-CAD: 03starseeker * r46365 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Be nice to source file flags set prior to the target being defined and bring them along for the ride.
01:46.38CIA-62BRL-CAD: 03starseeker * r46366 10/brlcad/trunk/misc/CMake/BRLCAD_CompilerFlags.cmake: Check if we have the no-unused flag
01:51.24CIA-62BRL-CAD: 03starseeker * r46367 10/brlcad/trunk/src/other/boost/ (1083 files in 93 dirs): One last round of additions - this is enough to let libpc build again, surprisingly - so good news everybody, boost can be upgraded without wiping out libpc
01:59.04*** join/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
02:00.31*** part/#brlcad cjdevlin (~devlin@d118-75-70-176.try.wideopenwest.com)
02:51.51*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096600997.dsl.bell.ca)
08:04.00*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
09:37.02jordisayolstarseeker: congratulations! text properly render on mged and archer when  compiling with cmake :-)
09:37.44jordisayolnow i'll move to cmake the scripts to build deb and rpm packages
09:40.52jordisayoland change some files names on misc/debian dir. Until now, I just need to modify "misc/Makefile.am" with the new files names. May I modify something else?
10:11.49CIA-62BRL-CAD: 03jordisayol * r46368 10/brlcad/trunk/misc/ (18 files in 3 dirs): Change some debian file names and mime-type names.
10:22.33CIA-62BRL-CAD: 03jordisayol * r46369 10/brlcad/trunk/ (5 files in 2 dirs):
10:22.33CIA-62BRL-CAD: Move deb/rpm building scripts to CMAKE.
10:22.33CIA-62BRL-CAD: Update debian/changelog to the next BRL-CAD release.
12:59.47CIA-62BRL-CAD: 03d_rossberg * r46370 10/osl/trunk/compile.sh: it's a bash script, neither sh nor tcsh works
13:01.27CIA-62BRL-CAD: 03d_rossberg * r46371 10/brlcad/trunk/src/liboptical/CMakeLists.txt: osl_rt.cpp was removed some days before
14:08.13*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
14:11.07*** join/#brlcad nick (~molto_cre@BZ.BZFLAG.BZ)
15:16.34*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
15:28.55*** join/#brlcad bhinesley (~bhinesley@99.104.175.216)
16:18.55*** join/#brlcad DarkCalff (DC@173.231.40.98)
16:26.55CIA-62BRL-CAD: 03n_reed * r46372 10/brlcad/trunk/src/conv/obj-g_new.c: Fixed buffer overflow in collect_grouping_faces_indexes. Realloc test was being done after bad index had already been used.
16:52.22CIA-62BRL-CAD: 03n_reed * r46373 10/brlcad/trunk/src/libgcv/wfobj/re2c_utils.c: Explicitly initializing vls to reassure valgrind.
17:44.29CIA-62BRL-CAD: 03n_reed * r46374 10/brlcad/trunk/src/libgcv/wfobj/ (obj_parser.cpp re2c_utils.c re2c_utils.h): Properly freeing scanner and parser objects.
17:51.52CIA-62BRL-CAD: 03starseeker * r46375 10/brlcad/trunk/misc/CMake/BRLCAD_CompilerFlags.cmake: revert r46366
17:57.39CIA-62BRL-CAD: 03starseeker * r46376 10/brlcad/trunk/src/CMakeLists.txt: turn libpc back on, as long as we're not on MSVC - not quite ready for that can of worms yet.
17:58.19jordisayolstarseeker: hi
17:59.27jordisayolstarseeker: now, compiling in linux with cmake, text in mged anf archer is properly rendered :-)
17:59.52starseekerjordisayol: awesome!
18:00.47jordisayolstarseeker: well, I supose that You do the necessary changes
18:01.52jordisayoli'm trying to compile it in opensuse in virtualbox, and I've got some errors
18:05.22jordisayolstarseeker: the error is this:
18:05.22jordisayol-- Check if the system is big endian
18:05.22jordisayol-- Searching 16 bit integer
18:05.22jordisayolCMake Error at /usr/share/cmake/Modules/TestBigEndian.cmake:44 (MESSAGE):
18:05.22jordisayol<PROTECTED>
18:05.22jordisayolCall Stack (most recent call first):
18:05.23jordisayol<PROTECTED>
18:05.24jordisayol-- Configuring incomplete, errors occurred!
18:05.46jordisayolstarseeker: is there a way to override it?
18:26.07*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:39.17starseekerjordisayol: I'm seeing that error on another platform actually - stand by
18:39.51jordisayolstarseeker: ok, thanks
18:55.43*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
19:07.10CIA-62BRL-CAD: 03starseeker * r46377 10/brlcad/trunk/misc/CMake/FindTERMLIB.cmake: Bad CMake module - don't pollute CMAKE_REQUIRED_LIBRARIES for other tests.
19:07.27starseekerjordisayol: give that a shot
19:15.31jordisayolstarseeker: now it works
19:15.34jordisayol;-)
19:38.02starseekerexcellent
19:38.11starseekersneaky devil, but it's gone now :-)
20:17.03CIA-62BRL-CAD: 03starseeker * r46378 10/brlcad/trunk/src/other/boost/boost/ (indirect_reference.hpp iterator/indirect_iterator.hpp): Hmm - different machine is showing more missing boost headers.
20:24.43CIA-62BRL-CAD: 03starseeker * r46379 10/brlcad/trunk/src/other/boost/ (742 files in 112 dirs): More boost stuff
20:26.44*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:27.13jordisayolI got another compiling error: http://paste.debian.net/127285/
20:27.23CIA-62BRL-CAD: 03starseeker * r46380 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: With the new boost, depth 50 isn't gonna cut it - some indications even 128 won't...
20:27.30jordisayolin opensuse 11.4 64 bit
20:31.10brlcadstarseeker: getting rt differences raytracing bot after something recent
20:31.13brlcadmaybe the bb?
20:35.39brlcadseveral other primitives too, i'll see if I can get a list
20:36.30starseekergrowl
21:11.46CIA-62BRL-CAD: 03n_reed * r46381 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Appeasing compiler by adding gratuitous code to lemon directives so that previously unused parameters get used in the generated output.
21:13.50CIA-62BRL-CAD: 03n_reed * r46382 10/brlcad/trunk/src/libgcv/wfobj/ (obj_rules.h obj_rules.re): Changed obj_parser_set_extra return type from void* to more appropriate void. Removed unused YY_INPUT macro.
21:22.06CIA-62BRL-CAD: 03n_reed * r46383 10/brlcad/trunk/src/conv/obj-g_new.c: Suppressing compiler warnings: compressed oversized usage string, added missing test_face prototype, removed unused variables, fixed bad branch statements.
21:29.18jordisayolon Fedora14 32bit got this error:
21:29.18jordisayol/home/jordi/Escriptori/b/src/other/togl/src/../include/GL/glew.h:1165:20: fatal error: GL/glu.h: No such file or directory
21:42.56*** part/#brlcad molto_crescendo (~molto_cre@BZ.BZFLAG.BZ)
22:14.32CIA-62BRL-CAD: 03jordisayol * r46384 10/brlcad/trunk/ (misc/debian/changelog sh/make_deb.sh sh/make_rpm.sh):
22:14.32CIA-62BRL-CAD: Change deb/rpm building dependencies.
22:14.32CIA-62BRL-CAD: Update debian/changelog.
22:23.32CIA-62BRL-CAD: 03jordisayol * r46385 10/brlcad/trunk/sh/make_rpm.sh: Change mime-type name on rpm builder script
22:56.07*** join/#brlcad merzo (~merzo@111-9-132-95.pool.ukrtel.net)
23:04.36starseekeris the glu.h header present on your system?
23:07.34CIA-62BRL-CAD: 03starseeker * r46386 10/brlcad/trunk/src/librt/primitives/bot/ (bot.c g_bot_include.c): Apparently rt_bot_bbox does not correctly calculate a minimal bbox - until it's clear why, restore old behavior.
23:34.59CIA-62BRL-CAD: 03brlcad * r46387 10/brlcad/trunk/BUGS: document a few more bugs encountered via the brep/csg/bot comparison testing. crashes during rtarea and/or gqa (but pix raytracing actually works...) for revolve, brep (revolve), and bot (hyp).
23:36.18CIA-62BRL-CAD: 03brlcad * r46388 10/brlcad/trunk/TODO:
23:36.18CIA-62BRL-CAD: document some of the NURBS issues encountered via the brep/csg/bot comparison
23:36.18CIA-62BRL-CAD: testing. need to speed up brep prep, need to tighten the bounding box (ideally
23:36.18CIA-62BRL-CAD: so that tools like csgbrep generate equivalent bounding boxes for the brep
23:36.18CIA-62BRL-CAD: version as the equivalent csg version -- good test cases).
23:45.14CIA-62BRL-CAD: 03brlcad * r46389 10/brlcad/trunk/sh/facetall.sh:
23:45.15CIA-62BRL-CAD: this script could use some love, but it can be pretty useful -- particularly
23:45.15CIA-62BRL-CAD: with these helper scripts. move the converted bot objects into place within the
23:45.15CIA-62BRL-CAD: hierarchy and show an easy way to count the size of all those polygons within a
23:45.15CIA-62BRL-CAD: .g file hierarchy.
23:46.15CIA-62BRL-CAD: 03brlcad * r46390 10/brlcad/trunk/sh/facetall.sh: killtree is probably more appropriate since the region will usually have children
IRC log for #brlcad on 20110825

IRC log for #brlcad on 20110825

00:17.49jordisayolstarseeker: yes, You're right. I'll try to find the rpm package containing this header, thanks
00:26.10*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
00:29.00*** join/#brlcad Yoshi477 (~jan@d72-39-60-53.home1.cgocable.net)
00:33.46CIA-62BRL-CAD: 03jordisayol * r46391 10/brlcad/trunk/sh/ (make_deb.sh make_rpm.sh): Changed more deb/rpm building dependencies.
00:36.17*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
01:06.22CIA-62BRL-CAD: 03starseeker * r46392 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/ResetCache.cmake):
01:06.22CIA-62BRL-CAD: Need more testing, but this setup swaps between 32 and 64 bit compilation
01:06.22CIA-62BRL-CAD: without requiring the nuking of the build directory files. In other words,
01:06.22CIA-62BRL-CAD: changing the BRLCAD-CPU_TYPE in cmake-gui and running configure should 'do the
01:06.22CIA-62BRL-CAD: right thing' automatically, and does on the system tested so far.
01:07.28starseekersweet
01:08.59CIA-62BRL-CAD: 03starseeker * r46393 10/brlcad/trunk/CMakeLists.txt: mark BULLET_INCLUDE_DIR as advanced
01:33.35brlcadstarseeker: nice list of extra deps there in jordi's stuff (sh/make_deb.sh)
01:36.00brlcadand nice fixup with RESET_CACHE_FILE :)
01:41.49CIA-62BRL-CAD: 03starseeker * r46394 10/brlcad/branches/STABLE/src/mged/ (mged.c setup.c): Add r45544 to stable - restores rt and rtarea output to mged.
01:45.54brlcadaha .. that's right -- not a vls init issue, it was a ged init issue, the struct gets reinitialized when a database is closed, but was never resetting the i/o handlers
01:51.24CIA-62BRL-CAD: 03starseeker * r46395 10/brlcad/branches/STABLE/src/librt/opennurbs_ext.h: Add the nurbs wireframe fix from 45532 and 45533 - prevents an infinite loop.
03:46.44CIA-62BRL-CAD: 03starseeker * r46396 10/brlcad/trunk/src/conv/obj-g_new.c: Mac didn't like NULL, go with 0
04:43.19*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
05:51.39CIA-62BRL-CAD: 03starseeker * r46397 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: Can't use a system lemon unless lempar.c is present in the same directory - check that too.
06:15.25CIA-62BRL-CAD: 03starseeker * r46398 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: lemon generates a .out file by default - could just add -q arg, but we may want that out file for debugging at some point so just go ahead and add it to the output list for now.
06:17.33starseekercome to think of it, our uce-dirent.h file is third party
06:25.45CIA-62BRL-CAD: 03starseeker * r46399 10/brlcad/trunk/src/mged/CMakeLists.txt: fix mged linking if bullet is around
06:45.59CIA-62BRL-CAD: 03starseeker * r46400 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: If all the flags fail, don't try it - need to be able to successfully tell the compiler 32/64 bit, otherwise configure specifically for something the compiler can't do should fail.
07:30.21*** join/#brlcad merzo (~merzo@193.254.217.44)
08:01.07*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:35.31*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
10:35.03*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-039.wlan.tudelft.nl)
11:28.17*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:40.47*** join/#brlcad abhi2011_ (~chatzilla@wlan-145-94-184-039.wlan.tudelft.nl)
12:50.22*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-039.wlan.tudelft.nl)
13:03.01*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:06.06brlcadit is, should get moved
14:36.30CIA-62BRL-CAD: 03starseeker * r46401 10/brlcad/trunk/src/other/uce-dirent/: uce-dirent is external, prepare a src/other home
14:51.29CIA-62BRL-CAD: 03starseeker * r46402 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: tweak so things are quieter on repeat runs of cmake
14:51.52CIA-62BRL-CAD: 03starseeker * r46403 10/brlcad/trunk/src/ (5 files in 2 dirs): move uce-dirent to src/other
15:01.25brlcadthinks we could probably do what that header is doing easier and more simply without it
15:02.27brlcadshouldn't even be needed on most modern non-windows platforms
15:04.12starseekerpossibly - it was a quick and functional solution for near-zero work at the time
15:18.29CIA-62BRL-CAD: 03starseeker * r46404 10/brlcad/trunk/src/other/lemon/README: Add a README file for lemon. probably should add the lemon docs as a text file too but that'll take a bit more reformatting
15:25.20*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-039.wlan.tudelft.nl)
15:31.59*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
16:09.48CIA-62BRL-CAD: 03starseeker * r46405 10/brlcad/trunk/src/libpc/CMakeLists.txt: Oh yeah, probably should uncomment the tests too.
16:12.33CIA-62BRL-CAD: 03starseeker * r46406 10/brlcad/trunk/CMakeLists.txt: don't want recursive behavior, so spot .. and ignore it in distcheck path handling.
16:13.52CIA-62BRL-CAD: 03starseeker * r46407 10/brlcad/trunk/ (10 files in 4 dirs): Update/add dist files and ignore lists for CMake distcheck
16:27.17CIA-62BRL-CAD: 03starseeker * r46408 10/brlcad/trunk/src/libpc/CMakeLists.txt: Bah, spoke too soon - test apps aren't happy.
16:35.16*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
16:46.43starseekercan't wait to see what happens on windows with obj-g </sarcasm>
19:02.36CIA-62BRL-CAD: 03n_reed * r46409 10/brlcad/trunk/src/conv/obj-g_new.c: Reformatted usage string to be less verbose.
19:17.01*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:00.22CIA-62BRL-CAD: 03starseeker * r46410 10/brlcad/trunk/CMakeLists.txt: These variables are not needed by default, but useful in some situations - put commented out lines in to illustrate how they would be set
20:45.29*** join/#brlcad merzo (~merzo@206-1-132-95.pool.ukrtel.net)
21:18.51*** join/#brlcad ScribbleJ (~chris@99-35-164-204.lightspeed.dwgvil.sbcglobal.net)
21:20.57CIA-62BRL-CAD: 03brlcad * r46411 10/brlcad/trunk/TODO: the nmg->brep conversion routine could use a more simple 2d bounding box technique that should give tighter fitting surfaces for quad faces. could go hog wild with a convex hull calculation too.
21:25.44ScribbleJI'm just getting started on trying to figure out brl-cad... is there a commonly used parts library anyplace, like for bolts, bolt holes, common shapes that aren't primitives, etc?
21:29.13CIA-62BRL-CAD: 03n_reed * r46412 10/brlcad/trunk/src/librt/primitives/bot/bot.c: Having rt_bot_ifree free normals and face_normals arrays along with the others.
21:32.14CIA-62BRL-CAD: 03n_reed * r46413 10/brlcad/trunk/ (include/wdb.h src/libwdb/bot.c): Marking unmodified parameters of mk_bot_w_normals as const.
21:37.34brlcadScribbleJ: hello
21:38.54ScribbleJHowdy!
21:39.14brlcadScribbleJ: two answers to that question -- 1) there is and it's rather extensive, but you don't have access to it (it's a proprietary parts database) and more usefully 2) there are various tools in brl-cad that will generate various common shapes
21:39.23brlcadbolt being one of the examples
21:39.37ScribbleJThose are both good answers.
21:40.16brlcadbolt, coil, fence, gastank, handle, human, picket_fence, tire, window, window_frame, and wire are the currently available "shape" tools (of varying quality and usefulness)
21:42.22brlcadthere is also a different bolt script floating around that someone in the community made that will apply threading and supports standard bolt specifications
21:44.25ScribbleJAll right.  I'm probably ahead of myself anyhow; I'll need to figure out how to do anything at all first. :)
21:44.41brlcadhave you seen the tutorial series on the website?
21:44.44ScribbleJI'm coming from having only used OpenSCAD and hoping I could find something a little more powerful.
21:44.53ScribbleJI have - I've read it but I need to walk through it I think.
21:45.43brlcadyeah, until some of the core commands are familiar (the ones on the mged quick reference), you'll have a tough time being productive -- the tutorials help you get there if you actually do them
21:46.31brlcadthe tutorials go through a lot of material, but even then only begin to scratch the surface of what you can do
21:54.36*** join/#brlcad b0ef (~b0ef@160.24.202.84.customer.cdi.no)
22:15.11CIA-62BRL-CAD: 03n_reed * r46414 10/brlcad/trunk/src/conv/obj-g_new.c: Fixed memory leak. A couple allocated arrays were being missed in the free_ti routine.
22:31.53CIA-62BRL-CAD: 03brlcad * r46415 10/brlcad/trunk/ (5 files in 4 dirs):
22:31.53CIA-62BRL-CAD: deprecate db_regexp_match() since it's nearly identical to bu_fnmatch(). it's
22:31.53CIA-62BRL-CAD: probably a minimally impacting change that could be removed, but the meaning of
22:31.53CIA-62BRL-CAD: the function's boolean return value is flipped making regexp substitution
22:31.53CIA-62BRL-CAD: clumsy. instead, mark it for removal and make the guts call bu_fnmatch(). this
22:31.53CIA-62BRL-CAD: was prompted by the existing implementation not supporting an expected feature
22:31.54CIA-62BRL-CAD: for 'not' character classes ala [^abc] which bu_fnmatch does support.
22:39.30CIA-62BRL-CAD: 03brlcad * r46416 10/brlcad/trunk/NEWS:
22:39.30CIA-62BRL-CAD: improved globbing of object names in mged by calling the libbu bu_fnmatch()
22:39.30CIA-62BRL-CAD: routine instead of the weaker librt db_regexp_match() function. this was
22:39.30CIA-62BRL-CAD: prompted by noticing that support for negated character classes (e.g., [^abc])
22:39.30CIA-62BRL-CAD: was not supported but it should also improve support for other operators such as
22:39.31CIA-62BRL-CAD: repetitions of character sets and anchoring to beginning and end of object
22:39.32CIA-62BRL-CAD: names.
22:47.50*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
22:54.12CIA-62BRL-CAD: 03brlcad * r46417 10/brlcad/trunk/NEWS:
22:54.12CIA-62BRL-CAD: go ahead and be specific since the four prims affected will fit, cliff tightened
22:54.12CIA-62BRL-CAD: the bounding boxes which 'should' improve performance but at a minimum will
22:54.12CIA-62BRL-CAD: affect the autoview size of those primitives when drawn alone (as well as the bb
22:54.12CIA-62BRL-CAD: command)
23:25.27CIA-62BRL-CAD: 03brlcad * r46418 10/brlcad/trunk/sh/conversion.sh:
23:25.28CIA-62BRL-CAD: accommodate the new options, but keeping them ordered similar to the intended
23:25.28CIA-62BRL-CAD: grouping. renamed the SAVE option to KEEP to avoid ambiguity. restore output
23:25.28CIA-62BRL-CAD: formatting so that column 70 isn't exceeded (keeping the output neatly
23:25.28CIA-62BRL-CAD: consistent). lastly, make KEEP respect the VERBOSE setting.
23:25.55CIA-62BRL-CAD: 03brlcad * r46419 10/brlcad/trunk/sh/conversion.sh: make sure the SEARCH binary exists too, set and use it as SGED
23:35.05CIA-62BRL-CAD: 03brlcad * r46420 10/brlcad/trunk/sh/conversion.sh: since the working file might no longer be deleted, give it a proper .g suffix.
23:35.40*** join/#brlcad ScribbleJ (~chris@99-35-164-204.lightspeed.dwgvil.sbcglobal.net)
23:40.38CIA-62BRL-CAD: 03brlcad * r46421 10/brlcad/trunk/NEWS:
23:40.38CIA-62BRL-CAD: tom browder updated the conversion.sh script with new options for KEEP and
23:40.38CIA-62BRL-CAD: OPATH, which respectively allow users to keep the working copy and specify the
23:40.38CIA-62BRL-CAD: object path to use for searching. combine two changes together and remove
23:40.38CIA-62BRL-CAD: multiline. (multiline news items are rare, usually reserved for multiple
23:40.39CIA-62BRL-CAD: contributors. also, reworded to fit to column 70.)
23:45.40CIA-62BRL-CAD: 03brlcad * r46422 10/brlcad/trunk/NEWS:
23:45.40CIA-62BRL-CAD: technically, memory issues are user visible, so document the recent fix from
23:45.40CIA-62BRL-CAD: nicholas reed where BoT object memory was not being freed during export. this
23:45.40CIA-62BRL-CAD: potentially could be a lot of memory for large bots and bots that are frequently
23:45.40CIA-62BRL-CAD: edited.
23:46.39brlcadabhi2011: how's the progress coming along?
23:47.25brlcadhaven't seen any bb updates or questions in a couple days
23:47.45abhi2011Well havent been able to work on it for the pass 2 days, but will code a bit today :)
23:47.57abhi2011a bit of thesis writing :P
23:48.02brlcadah, okay
23:48.59abhi2011I was wondering, the ultimate aim of the simulate command is to fire it through a mged script and then run rt on the scene  ?
23:49.37abhi2011so like simulate is run for say 1 step and then a scene is rendered and stored as a png image
23:49.48abhi2011then its run for 2 steps and again a scene is rendered
23:50.12abhi2011and then all these images will be combined using imagemagik to make a movie
23:50.25abhi2011for illustration purposes
23:57.54*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
23:58.38brlcadabhi2011: initially, sure
23:59.14brlcadactually, the aim is to perform the simulation itself -- there are a variety of ways to visualize that simulation
IRC log for #brlcad on 20110826

IRC log for #brlcad on 20110826

00:00.17brlcadthe goal, to me, is to get the sim working for the purpose of demonstrating contact/collisions and having objects respond
00:00.51brlcadso I can drop a box onto a ground plane, and watch it tumble after hitting the ground
00:01.01abhi2011ok
00:01.47brlcador simulate a virtual brl-cad pool table with accurate friction resistance, spin, n-body collisions
00:02.12brlcadthe goal is the sim itself :)
00:02.37abhi2011ok yes I understand
00:03.37abhi2011by the way I was trying to have some fun with the current state of the simulate command :P
00:03.44abhi2011so I was running the simulate command in a tcl loop in mged the other day, and the positions were not getting updated till the loop completes
00:04.02abhi2011but that I guess is due to the change you mentioned a while back that is required to made
00:04.25abhi2011before position updates can occur
00:05.39brlcadyep
00:07.00brlcadif you want to see the updates now, you could write a shell script that invokes mged for each iteration and renders a frame
00:08.08brlcador you could write a tcl proc that invokes your tcl script for just one timestep
00:08.47brlcadiirc -- it should update interactively, just not via the 'source' command
00:10.47abhi2011ok
00:11.20abhi2011I noticed the line SET(GEDSIM_LIB libgedsim) was added to the simulate/CMakeLists.txt file
00:11.49abhi2011so do I still proceed with changing the name of the build target to simulate ?
00:11.59abhi2011like so : BRLCAD_ADDLIB(simulate "${SIMULATE_SOURCES}" ${BULLET_LIBRARIES})
00:12.20brlcadsame reasonsing still holds true :)
00:13.08brlcadit's not a library, don't want to start a convention for libged commands
00:14.13brlcadit's only being built as a library due to cmake limitations -- and it might still get folded into the parent SOURCES with different rules later
00:14.29abhi2011yes, ok then I will proceed with the change to the target at both places, libged/simulate/CMakeLists.txt and libged/CMakeLists.txt
00:18.25abhi2011umm by parent sources you mean mged's code ?
00:18.36brlcadlibged
00:18.40abhi2011oh ok
00:26.00CIA-62BRL-CAD: 03brlcad * r46423 10/brlcad/trunk/TODO:
00:26.00CIA-62BRL-CAD: need to create a class that inherits from ON_Brep so we can cleanly implement
00:26.00CIA-62BRL-CAD: methods that openNURBS intentionally removes. that way we won't have to fork
00:26.00CIA-62BRL-CAD: and merge changes each time openNURBS is updated, our additions can be managed
00:26.00CIA-62BRL-CAD: more easily, and our changes can be consolidated.
00:49.15*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
00:58.34CIA-62BRL-CAD: 03brlcad * r46424 10/brlcad/trunk/src/librt/opennurbs_ext.h: if the child node being added is null, do nothing
01:03.24CIA-62BRL-CAD: 03brlcad * r46425 10/brlcad/trunk/src/librt/opennurbs_ext.cpp:
01:03.24CIA-62BRL-CAD: so the big crash is happening due to the surfaces being NULL after a call to
01:03.24CIA-62BRL-CAD: Split(). not yet at all clear how that's happening so add debug abort code,
01:03.24CIA-62BRL-CAD: return null, and protect against null derefences. would be cleaner to ensure
01:03.24CIA-62BRL-CAD: that subdivideSurfaceByKnots() will never return NULL (and someone (tm) should
01:03.24CIA-62BRL-CAD: fix that) but it's not immediately clear to me what the Split() failure means
01:03.25CIA-62BRL-CAD: yet.
01:13.13CIA-62BRL-CAD: 03brlcad * r46426 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: ws indent consistency cleanup
01:16.47CIA-62BRL-CAD: 03brlcad * r46427 10/brlcad/trunk/src/librt/pr.c: why hasn't this missing semicolon caused a build failure before now??
01:21.35abhi2011regarding the cmake target changes for simulate, I wanted to confirm that these were the desired changes
01:21.40abhi2011here is the diff : http://bin.cakephp.org/view/269125967
01:23.03abhi2011I removed SET(GEDSIM_LIB libgedsim) as the new target 'simulate' can be directly specified everywhere instead of another variable ${GEDSIM_LIB} ..or ${SIMULATE}
01:23.05CIA-62BRL-CAD: 03brlcad * r46428 10/brlcad/trunk/src/librt/primitives/ (4 files in 3 dirs): more missing semicolons.. wtf.
01:25.35brlcadabhi2011: most of the devs receive an e-mail for every commit that includes the diff -- if there's a problem, someone will usually say something or fix it
01:26.01brlcadso don't hesitate on committing unless you've not tested it or know it'll break something
01:26.44abhi2011ok, yes I have tested it, since its the build system, being careful :)
01:30.22CIA-62BRL-CAD: 03abhi2011 * r46429 10/brlcad/trunk/src/ (3 files in 3 dirs): Changed the name of the simulation sources build target to simulate, removed GEDSIMLIB
01:30.51brlcadbeing careful is good, but being productive is better ;)
01:31.36abhi2011true :)
01:31.42brlcadno worries, someone will let you know if it's messed up, and if it is then it definitely is your responsibility to fix (ideal) or revert (if you can't fix it immediately)
01:32.44CIA-62BRL-CAD: 03brlcad * r46430 10/brlcad/trunk/src/libwdb/pipe.c: aha! it was the (void *)0 change to the runtime-debug disabled mode macros (knew it would catch if-statements, did not expect it to catch missing semis). awesome side effect. :)
01:40.42brlcadwoot, raytrace works!
01:45.43CIA-62BRL-CAD: 03brlcad * r46431 10/brlcad/trunk/src/conv/patch/patch-g.c: last one, another semi missing.
01:57.52*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
01:59.42abhi2011hmm, trying to find out how you resolved that missing semi colon issue , looking at pipe.c and magic.c, so NO_BOMBING_MACROS is used when runtime debug is disabled ?
02:03.01abhi2011* is defined
02:03.31brlcaddisabling runtime debug sets NO_BOMBING_MACROS (among others)
02:03.53brlcadthe macros used to be empty when disabled, so no problem
02:04.06brlcadlikewise, when enabled, it was an if {} so no problem
02:04.19CIA-62BRL-CAD: 03starseeker * r46432 10/brlcad/trunk/src/ (4 files in 4 dirs): Make a stab at a CMake setup for libged commands in subdirectories.
02:04.32brlcadturned into a no-op statement, though, it became a syntax error and the missing semis could be detected
02:08.07abhi2011brlcad: ok
02:18.45CIA-62BRL-CAD: 03brlcad * r46433 10/brlcad/trunk/NEWS:
02:18.45CIA-62BRL-CAD: due to the slew of 'i seemed to encounter bad geometry' messages that print out
02:18.45CIA-62BRL-CAD: during raytracing, note that the fix for the m1151 geometry that made rt stop
02:18.45CIA-62BRL-CAD: crashing was probably due to bad geometry. either way, it was a crash case that
02:18.45CIA-62BRL-CAD: is no longer crashing.
02:32.18starseekerabhi2011: give that a a shot for ged simulate building - I can't test it on this machine (no bullet) but hopefully that will be cleaner
02:33.24brlcadheh, 5 hours to prep if it were single cpu
02:33.30brlcad(nurbs)
02:34.47starseekerwinces
03:43.06CIA-62BRL-CAD: 03starseeker * r46434 10/brlcad/trunk/CMakeLists.txt: Fix comment - we aren't interested in setting for debug on Windows at the moment - usual pattern there is to run from build directory and then create the .exe installer
04:00.59CIA-62BRL-CAD: 03starseeker * r46435 10/brlcad/trunk/src/libged/CMakeLists.txt: Ah, right - need to format this so that the BRLCAD_ADDLIB macro is OK with it.
04:11.24starseekerthere we go - simulate command builds on my home box now
07:19.20*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
07:29.56CIA-62BRL-CAD: 03jordisayol * r46436 10/brlcad/trunk/sh/make_rpm.sh: Add "ISO-8859-1 75dpi fonts" for fedora rpm building dependency.
09:21.13*** join/#brlcad merzo (~merzo@193.254.217.44)
09:53.15abhi2011starseeker: yes the changes built cleanly on my machine as well
11:44.20*** join/#brlcad kunigami (~kunigami@201.53.206.27)
12:13.43*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl)
12:36.27*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
12:43.57*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:01.05*** join/#brlcad plaes_ (~plaes@gn237.zone.eu)
14:06.29*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
14:28.28*** join/#brlcad kunigami2 (~kunigami@loco-gw.ic.unicamp.br)
14:37.35brlcadgmornin peoples!
14:44.25*** join/#brlcad CIA-62 (~CIA@cia.atheme.org)
15:10.03*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:26.57abhi2011goedemorgen brlcad :P
15:33.16abhi2011hmm RT_GET_TREE(tp, &rt_uniresource); doesnt appear to be setting a good magic number when I try to create a rt_comb_internal by manually filling up a tree
15:34.44abhi2011got something like this now : http://bin.cakephp.org/view/151711593
15:35.39abhi2011RT_GET_TREE() sets a wierd magic number like ((tp))->magic = 0x91191191
15:36.02abhi2011there is probably a version specific marco for setting a valid number
15:47.27abhi2011will try RT_TREE_INIT(tp);
15:49.57*** join/#brlcad kunigami (~kunigami@201.53.206.27)
16:18.27abhi2011brlcad: is there a reason why OP_DB_LEAF is not handled in rt_bound_tree() ?
16:19.06abhi2011I use it when filling up the values in a rt_comb_internal for primitives
16:28.18abhi2011tp->tr_l.tl_op = OP_SOLID does not work , and that is the closest case I can see(to primitives)
16:32.24abhi2011hm, maybe I should start with an union op in the tree
16:48.27CIA-62BRL-CAD: 03n_reed * r46437 10/brlcad/trunk/src/librt/prep.c: Removed dead code from rt_clean_resource_basic. It was an uncompiled duplication of the code in rt_clean_resource_complete.
17:04.04abhi2011ok I need to use OP_SOLID and somehow I need to convert the idb_meth member in rt_db_internal * to the a struct soltab *stp; so rt_bound_tree() can get the bb
17:04.22abhi2011aaaargh....almost there
17:22.29CIA-62BRL-CAD: 03n_reed * r46438 10/brlcad/trunk/src/librt/shoot.c: rt_res_pieces_clean was dereferencing rtip without checking for NULL value.
17:38.30abhi2011well it seems the struct soltab is not needed and nor is rt_bound_tree() for primitives,  a simple call to ip->idb_meth->ft_bbox(ip, &rpp_min, &rpp_max) suffices for getting the bb of primitives
17:38.33CIA-62BRL-CAD: 03n_reed * r46439 10/brlcad/trunk/src/conv/obj-g_new.c: Cleaning rt_uniresource after it's no longer needed.
17:52.45abhi2011its onto regions now
18:29.06*** join/#brlcad ScribbleJ (~chris@99-35-164-204.lightspeed.dwgvil.sbcglobal.net)
18:38.55*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:48.13abhi2011hmm, no , cant just insert a new OP_DB_LEAF case into rt_bound_tree() , seems even after I reach the leaf, the most information I can get from the leaf node is the name of the primitive, with no other information , like points etc
19:02.47abhi2011seems a rt_db_internal representing a region has only information about the operations that build the region and the primitive names, not the shape information about the primitives themselves
19:11.58CIA-62BRL-CAD: 03n_reed * r46440 10/brlcad/trunk/src/libgcv/wfobj/ (obj_grammar.yy obj_parser_state.h): indent/ws cleanup
19:13.28CIA-62BRL-CAD: 03n_reed * r46441 10/brlcad/trunk/src/libgcv/wfobj/ (7 files): Applied standard headers and footers.
20:12.29starseekerabhi2011: that bbox interface is brand new, and some of them (BoT for certain) aren't really correct yet
20:12.49starseekerabhi2011: if you want to use that, you probably need to start by fixing rt_bot_bbox
20:15.06CIA-62BRL-CAD: 03starseeker * r46442 10/brlcad/trunk/src/libgcv/wfobj/obj_parser_state.h: stray character
20:18.40abhi2011starseeker: oh shoot, no easy way out then :P
20:19.21starseekerabhi2011: well, fixing rt_bot_bbox is definitely the right way to go - the intent is for rt_*_bbox routines to be a fast way to get a correct bbox
20:19.58starseekerwould suggest looking at what rt_bot_plot does - it can draw lines, so it must have logic for visiting the data structure
20:20.24abhi2011ok, by the way do you have any idea about the other issue, about the op_db_leaf case
20:20.39abhi2011i though OP_SOLID would be used uniformly for primtives
20:20.46abhi2011in the tree nodes I mean
20:21.08starseekernot offhand - would have to study the code, and unfortunately I'm in the middle of house stuff
20:21.16starseeker(nice big storm on the way...)
20:21.30abhi2011ah yah i heard
20:22.38abhi2011irene ?
20:26.36*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
20:30.48*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:43.06*** join/#brlcad ScribbleJ (~chris@99-35-164-204.lightspeed.dwgvil.sbcglobal.net)
22:40.08CIA-62BRL-CAD: 03n_reed * r46443 10/brlcad/trunk/src/conv/obj-g_new.c: Removed call to perror after syntax error. Error message is already printed elsewhere, and errno is not set.
22:50.51CIA-62BRL-CAD: 03n_reed * r46444 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Making return codes clear.
22:50.57*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:30.41*** part/#brlcad roberthl (~robert@mediawiki/RobertL)
IRC log for #brlcad on 20110827

IRC log for #brlcad on 20110827

02:50.01*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
07:41.35*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
12:45.30*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
13:22.30CIA-62BRL-CAD: 03brlcad * r46445 10/brlcad/trunk/src/mged/dodraw.c: doesn't look like mged_bound_solid() is used outside of this file, so mark as static.
15:09.04*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
19:51.38*** join/#brlcad merzo (~merzo@12-152-132-95.pool.ukrtel.net)
20:35.40*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
23:25.24*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
IRC log for #brlcad on 20110828

IRC log for #brlcad on 20110828

09:01.02*** join/#brlcad DarkCalfz (DC@173.231.40.98)
09:19.28*** join/#brlcad plaes (~plaes@gn237.zone.eu)
10:24.09*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
10:38.15*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
10:38.15*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
10:38.51*** join/#brlcad CIA-62 (~CIA@cia.atheme.org)
10:39.08*** join/#brlcad plaes (~plaes@gn237.zone.eu)
10:39.43*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
10:39.43*** join/#brlcad kanzure (~kanzure@131.252.130.248)
10:40.33*** join/#brlcad DarkCalfz (DC@173.231.40.98)
10:40.33*** join/#brlcad kunigami2 (~kunigami@loco-gw.ic.unicamp.br)
10:40.33*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
10:40.38*** join/#brlcad merzo (~merzo@12-152-132-95.pool.ukrtel.net)
10:41.58*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
10:41.58*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
10:41.58*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
10:45.33*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
10:45.33*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
13:45.10*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:46.37abhi2011is there a way to calculate a transformation matrix to convert between co-ordinate systems
13:47.17abhi2011bullet's co-ordinate system assumes the y axis as up, but is right handed, just like mged
13:48.09abhi2011so objects fall towards the xz plane when gravity is applied
13:48.45abhi2011the transformation matrix has to map the translations and rotations to mged's co-ordinate system correctly
13:57.08abhi2011i ll try a simple rotation about the x-axis
14:55.21abhi2011trying to reset some primtives to the origin before the simulation starts
14:55.47abhi2011apparently rt_matrix_transform() applies a translation/rotation to the existing transform
14:56.22abhi2011there does not seem to be a functions that can directly set the absolute world transform of a comb/primitive
15:29.17*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
17:19.42*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
17:29.05*** join/#brlcad merzo (~merzo@77-191-133-95.pool.ukrtel.net)
18:28.00brlcadabhi2011: perhaps there's a way to specify the coordinate system to bullet
18:29.37brlcadotherwise, you can just apply the rotation before you feed values to bullet and the reverse when you read values and apply them back on geometry
18:32.40abhi2011brlcad: ok
18:33.57abhi2011about the bounding box function, I have been trying with combp = (struct rt_comb_internal *)ip->idb_ptr; and rt_bound_tree(combp->tree, tree_min, tree_max)
18:34.32abhi2011however rt_bound_tree() does not implement the OP_DB_LEAF case which causes the traversal of the tree to get stuck
18:35.50abhi2011so I was considering adding that case, but even if I rt_bound_tree() does get me to the leaf, it seems the leaf only had information about a primtive's name
18:36.22abhi2011not its shape information such as a pointer to its ft_bbox() method etc, or any geometry info
18:49.29brlcadabhi2011: so it sounds like there's some disconnect, that you're not setting up something correctly
18:50.59brlcadif I recall correctly, you had it working earlier, when you were mimicking what the bb command does (ala _ged_get_obj_bounds)
18:51.13brlcadnow you're basically saying that method doesn't work
18:51.22brlcadbut you had it working for combs, so what's changed?
18:55.53brlcadIF ip is a comb (which you have to check), then you still have to call rt_gettree() to "load" the members of that comb and calculate the primitive bb's (and THEN you can call rt_bound_tree() to get the overall comb bb)
18:56.57brlcadread src/libged/get_obj_bounds.c again -- it does what you're trying to do
18:57.12brlcadit just starts with a char*name instead of an rt_db_internal
18:58.39brlcadwhen your function is done and working, it should drop right into _ged_get_obj_bounds() and _ged_get_obj_bounds2()
18:58.58brlcad(or better still, into the callers of those functions so they can be eliminated)
19:30.08abhi2011brlcad: yes I just found that out, that I need to call rt_gettree() for combs, otherwise the members are not loaded
19:30.24abhi2011well now I ll get it working
19:35.28abhi2011ok I got the reason why I had said rt_bound_tree() was working before
19:36.15abhi2011it was with a standalone program which obtained a struct rt_i *rtip directly from the the database file , using rtip = rt_dirbuild(argv[1], title, sizeof(title));
19:36.54abhi2011this trip does have the primtives and can be safely passed to rt_gettree(rtip, argv[2]), to load all the primtives for a combination
19:37.19abhi2011but in the bb box function, I create an in-mem rtip
19:37.40abhi2011which does not know anything about the primitives
19:37.59abhi2011as it was not made from the original file
19:39.09abhi2011so calling rt_gettree()  as follows : ( when I am trying to find the bb for a comb of course), would lead to the members of that comb still not getting loaded
19:40.52abhi2011if (rt_gettree(rtip, "dummy") < 0){...
19:42.36abhi2011the only thing thats changed is the rtip between the 2 cases (the one where I build rtip using rt_dirbuild() and the bb function case which uses an in-mem rtip )
19:46.44abhi2011brlcad: thats why the original rtip that was made from the database file would be needed to get to the primtives, because rt_gettree() needs to get the original rtip
20:14.34brlcadI'm not sure much of that made sense to me :)
20:16.05brlcadrecounting what you did to me isn't necessary, I know what you did :)  it was a question to ask yourself to hopefully help you figure out what you now need to do to get things working
20:18.14abhi2011yes ok :) ,  I am certain now that the original dbip needs to be passed and I ll get the bb using it and wrap up the function
20:18.29abhi2011perhaps in the near future i ll  be able to remove it
20:19.02brlcadif it's a comb, your job is really easy
20:19.58brlcadthe only real work remaining is/was supposed to be figuring out how to calculate the bb for a primitive
20:20.14brlcadyou had *A* solution, just not the ideal solution
20:20.55brlcadso you could go with what you had (using the inmem) ... or figure out how to build an rt_comb_internal by hand with just that one primitive
20:22.31brlcadI'd suggest getting it to work for both comb and prims using the two methods you already know work, then trying to build the rt_comb_internal as a replacement method for prims
20:22.56brlcadthat way, the code will be at least functional and can be tested for any object type
20:43.09*** join/#brlcad merzo (~merzo@194-13-133-95.pool.ukrtel.net)
21:02.24abhi2011brlcad: yes, I will be building a rt_comb_internal for finding the bb of both prims and combs
21:03.46abhi2011the only other thing I will be doing is adding an extra paramter to rt_bound_internal()
21:04.42abhi2011will make it like :           rt_i rt_bound_internal(struct rt_i *rtip, struct rt_db_internal *ip, point_t rpp_min, point_t rpp_max)
21:05.06brlcadwhy?  you shouldn't need to do that
21:05.14abhi2011ah ha...:)
21:05.20abhi2011so that is because
21:05.39abhi2011the rtip that I pass to rt_gettree() should be the original rtip
21:05.53abhi2011not one created from an in-mem dbip
21:07.19brlcadit feels like we're talking in circles :)
21:07.53abhi2011the in-mem dbip has no geometry information about the primtives in the model, and consequently neither does the struct rt_i*  made from it
21:08.25abhi2011well, yeah I know it feels that way, and its my fault really
21:09.09abhi2011the rt_bound_tree(combp->tree, tree_min, tree_max) method never worked before actually
21:09.13brlcadsure, that you found out last week -- you'd have to add all of the comb's members (that's why you were researching db_functree())
21:09.22abhi2011yes exactly
21:09.35abhi2011and db_functree() runs against the same problem see
21:09.45abhi2011its unable to add the primtives
21:10.03brlcadbecause?
21:10.04abhi2011because it uses db_lookup() on the in-mem db_i
21:10.24abhi2011the one I create and pass to it inside the rt_bound_internal() function
21:10.24brlcadyou don't run functree on the inmem
21:11.11brlcadyoud run functree on the original dbi to add them to the inmem
21:11.11abhi2011yes, I should run it on the original  struct db_i
21:11.31abhi2011yes, but the original db_i is not passed
21:11.34abhi2011to the function
21:11.43abhi2011so I would need to pass it
21:12.30brlcadthat would be better than passing an rtip, but still seems unnecessary..
21:12.39abhi2011yes, umm why
21:12.51abhi2011there is no other way to add the primitives
21:13.14abhi2011other than picking them form the original struct db_i and putting them in the in-mem struct db_i
21:16.27brlcadthe why would be because the rt_comb_internal should already have a union tree * filled out
21:16.46brlcadthe inmem one you were trying didn't, but that's obvious why .. you only added the comb
21:18.25brlcadthe caller will be passing you an rt_db_internal that should be filled out, that tree should be passable to rt_bound_tree() as-is .. no?
21:18.42brlcadif it's not, it sounds like a problem in the caller code
21:19.24brlcad(like not calling dirbuild or gettrees or something .. don't think it matters which)
21:19.24abhi2011yes it should be passable to rt_bound_tree(), however the structure of the tree is wrong
21:20.09abhi2011the tree leads to the primtive node , but that node has just the primtive name
21:20.49abhi2011it does not have any geometry information and the tr_op is not OP_SOLID
21:20.55abhi2011its OP_DB_LEAF
21:20.59abhi2011which is not correct
21:21.18brlcadso why is that, sounds like something not getting set up right
21:21.30abhi2011yes so let me explain :)
21:21.39brlcadlike I said -- "it sounds like a problem in the caller code"
21:22.21abhi2011hmm yeah
21:22.33abhi2011the rt_db_internal() should have a complete tree
21:23.56abhi2011but the caller code is very straight forward : http://bin.cakephp.org/view/1978180787
21:24.36brlcadrt_bound_tree() is clearly used by src/libged/bb.c (via get_obj_bounds.c()) so if they can do the setup, you should be able to too (even if it requires the caller to do something first)
21:25.23abhi2011ok
21:25.28brlcadso if that caller code isn't working right, there's something else you need to have it do
21:26.35brlcadmaybe see what rt_gettree() does since that's what get_obj_bounds.c calls before calling librt
21:26.45abhi2011ah!
21:26.46brlcadyou may need to do some subportion of what it's doing
21:27.00abhi2011so its called before
21:27.11abhi2011yes I ll check it
21:27.13brlcadthere's no point in calling rt_gettree in the caller code because you don't have an rtip
21:27.33brlcadbut maybe there is some other rt function that sets up and initializes the rt_comb_internal properly
21:27.40brlcadvery likely :)
21:27.44abhi2011ok
21:28.00brlcadsomething related to loading a union tree *
21:29.48abhi2011yeah the first thing get_obj_bounds() does it  /* Make a new rt_i instance from the existing db_i sructure */ and finally calls rt_gettree() on it
21:31.05abhi2011which I could do in my caller code too :P, but lets see if there some other way
21:34.47brlcadyeah, if the caller had to do all of that, it would defeat the simplicity we're going for
21:35.13brlcadif you find out that you have to add a dbip parameter, that's fine -- but you should make sure first
21:37.25abhi2011well yes, there is no way to intialize the tree of an  rt_comb_internal() for a regions without doing walk on the database instance tree using the original db_i
21:38.09brlcadhow do you know that?
21:39.14abhi2011because only the original db_i would have the information about the geometry of the primitives
21:40.02abhi2011and that db_i would need to be used to look up any primitive names that we encounter while traversing the tree for a comb
21:40.21brlcadright, okay -- I misread what you were saying
21:40.50brlcadthe question is whether there is already a routine or simple method that will initialize it for you
21:41.02brlcadother than rt_gettree()
21:46.16brlcadif something doesn't exist, that actually might be a good case for adding a function that creates a non op_db_leaf union tree suitable for your function (which calling code would then be required to call beforehand)
21:47.31brlcadbasically something like rt_gettree() but specifically for combs, like maybe a new rt_comb_tree() function
21:48.15abhi2011ok
21:48.58abhi2011i did come across
21:48.59abhi2011db_comb_describe
21:49.07abhi2011and rt_comb_describe()
21:52.32abhi2011ok yeah, adding a function that creates a non op_db_leaf union tree would still require passing the original db_i to it, so all the geometry info about the model is available
21:53.00brlcadyes, something like:  union tree *rt_comb_tree(const struct db_i *dbip, const struct rt_db_internal *ip)
21:55.41abhi2011ok
21:55.45brlcadI hate to say it, because that's probably the way to go, but I think we're getting out of scope
21:55.51brlcada bit at least
21:56.27brlcadfiguring out how to implement that function properly would probably take a few days at best, a couple weeks at worst
21:56.33abhi2011yeah I dont see any other function in raytrace.h that could make a rt_comb_internal
21:57.10brlcadplus figuring out the important parts from rt_gettree() is probably a little bit out of depth
21:57.26brlcadthat's relatively complex code so it'd be a challenge
21:57.44abhi2011yah that would really go deep into 3D geometry I think :P
21:57.59brlcadnot really
21:58.06brlcadit gets deep into librt structures is all
21:58.13abhi2011ok
21:58.15brlcadat lot of recursion and complex data structures
21:58.41brlcaddoable, but not immediately relevant for the goals of this project
21:59.07brlcadso pass the dbip, but add a FIXME note to the comment header with the details we've talked about
21:59.31abhi2011ok
21:59.34brlcadstating the need for something like rt_comb_tree to get a portion of the rt_gettree() initialization
21:59.54abhi2011right
IRC log for #brlcad on 20110829

IRC log for #brlcad on 20110829

03:50.06CIA-62BRL-CAD: 03Jimblack 07http://brlcad.org * r3084 10/wiki/Main_Page:
05:06.55*** join/#brlcad ibot (~ibot@rikers.org)
05:06.55*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
07:18.40*** join/#brlcad merzo (~merzo@193.254.217.44)
09:35.05CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3085 10/wiki/User:Abhijit: /* Log */
09:35.25CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3086 10/wiki/User:Abhijit: /* Log */
11:10.13*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:38.19abhi2011brlcad: about passing the struct db_i* in rt_bound_internal()
12:40.13abhi2011it would be necessary to call rt_gettree() inside this function
12:40.33abhi2011to get the primtives for a comb loaded
12:40.55abhi2011is that fine, or would it be better to avoid calling rt_gettree() ?
12:41.37abhi2011if I do need to call rt_gettree(), then the 2nd parameter is the name of the comb/primitive
12:44.16abhi2011which is generally got using a directory pointer using dp->d_namep
12:45.42abhi2011the only way to get a directory pointer is to use again use name of the comb and then db_lookup()
12:48.17abhi2011I have been searching for getting the comb or primitive name from a struct rt_db_internal if at its possible
12:51.10abhi2011seems all of this can be avoided if the caller code simply calls rt_gettree() before passing the struct rt_db_internal*
12:51.23abhi2011then we do not even need to pass the struct db_i *
12:54.56abhi2011or the calling code can pass the name of the comb/primitive
13:18.20*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:16.20CIA-62BRL-CAD: 03starseeker * r46446 10/brlcad/trunk/TODO.cmake: Update todo items for CMake
14:48.43CIA-62BRL-CAD: 03starseeker * r46447 10/brlcad/trunk/src/other/CMakeLists.txt: mark BRLCAD_TERMLIB_BUILD as advanced
14:53.27*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl)
14:57.11*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:04.18CIA-62BRL-CAD: 03starseeker * r46448 10/brlcad/trunk/src/other/re2c/bootstrap/parser.hh: May need the parser.hh file too...
15:04.54CIA-62BRL-CAD: 03starseeker * r46449 10/brlcad/trunk/src/other/re2c/bootstrap/parser.hh: fix comment
15:08.16CIA-62BRL-CAD: 03starseeker * r46450 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: MSVC doesn't know what to do with D_FORTIFY_SOURCE, apparently
16:38.14*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl)
16:42.44brlcadabhi2011: gah
16:44.22brlcadthat's a problem, rt_db_internals are nameless ... forgot about that
16:44.30abhi2011oh shoot :P
16:44.42abhi2011yeah by the time its reaches the rt layer
16:44.46abhi2011names are no longer relevant
16:45.01brlcadthat's by design, so you can write a given rt_db_internal as many times as you want with different names
16:45.19abhi2011ok
16:45.21brlcadyou might have to resort one layer higher, with a struct directory *
16:46.26abhi2011yes , however a struct directory * is made using db_lookup(), which unfortunately also requires a name , and I cannot use a dummy name, I have to use the exact name of the comb the user passed
16:46.59brlcadhuh?
16:47.14brlcadlibged knows the name
16:47.26brlcadthe same name you used to get the rt_db_internal
16:47.36brlcadinstead of that, you'll just pass the directory
16:48.48abhi2011oh ok, so I pass the directory and the struct db_i *, something like this : rt_bound_internal(struct db_i *dbip, struct directory *dp , struct rt_db_internal *ip, point_t rpp_min, point_t rpp_max)
16:49.04brlcadif you pass the dp, you no longer should pass the ip
16:49.09brlcadyou can get the ip from the dp
16:49.12abhi2011yes right
16:49.15abhi2011ok
16:49.26abhi2011I was wondering :)
16:49.39abhi2011why we simply have a function which accepts the dp and the name
16:49.52abhi2011um no scratch that
16:50.05abhi2011dp and dbip is enough
16:50.38abhi2011i thought it would be easy to have a function that just accept the name of the comb/primitive and the dbip
16:50.49abhi2011that would be easy to pass by a user
16:51.37abhi2011something like rt_bound_internal(char*name , struct db_i *dbip, point_t rpp_min, point_t rpp_max)
16:52.14brlcadthat's libged's responsibility
16:52.22abhi2011oh ok
16:52.25brlcadlibged works with strings, names
16:52.34abhi2011ok
16:53.56abhi2011yeah I get it now :)
16:53.57brlcadreally, I want to just pass the rt_db_internal, but as we already discussed, another routine needs to be written first to fill out the comb's tree properly
16:54.04abhi2011yes
16:54.14brlcaddon't are about names (or even directory), just want the bb given geometry
16:54.28abhi2011yes true
16:54.37brlcadworking with a dbip+dp is a start, though
16:55.13brlcadthat can be refactored to call a lower-level calculate-my-bb-with-just-this-ip later
16:55.53abhi2011ok
16:57.59abhi2011I have a question regarding the transformation matrices of primitives
16:58.45abhi2011so in the commands that somehow transform the object, I can see that the commands generally call rt_matrix_transform()
17:00.00abhi2011and this function ultimately goes and put  a new matrix in the tl_mat member of the struct union tree
17:00.22abhi2011that exists in the tr_l member of a union tree*
17:00.40brlcadusually
17:00.46abhi2011however this is a transform matrix, not the matrix  representing the absolute world position
17:01.07abhi2011however bullet gives me the matrix that represents the transform in absolute world co-ordinates
17:01.50abhi2011so if the object were to start from (0,0,0) and with no rotations along any of the axes, then the transform matrix from bullet can be applied to get the object to its intended position
17:02.27abhi2011now the thing is, I generally copy an existing object in mged, and then apply bullet's transform on it
17:02.41abhi2011however this new object is no made at the origin
17:02.58abhi2011its made in the existing object's position
17:03.09abhi2011which is correct as far as copying is concerned
17:03.42brlcadwaits for the question
17:03.51abhi2011however , it would be great if I were able to reset any copies I make , to the origin
17:04.02abhi2011there are no such commands to do this in mged however
17:04.38abhi2011and if I apply bullet's transforms on a copy, which is not in the origin, then the translation adds to the existing position
17:04.57brlcadyou're going way too far down the rabbit hole
17:05.08abhi2011:)
17:05.11brlcadask a question :)
17:05.46brlcador at least ask me to explain how brl-cad tracks positions if you don't know what to ask :)
17:05.52abhi2011ok
17:06.39abhi2011yeah it would be better if you explain :)
17:07.02abhi2011my issue is how to apply the bullet transforms on a object which is not at the origin
17:07.48abhi2011since the transforms got from bullet specify the translations of the object with respect to the origin, not the position of the object at the start of the simulation
17:08.28brlcadso if you remember my earlier comments from when you first got started -- and why you've been messing around with bounding boxes for so long...
17:10.15brlcadgeometry in brl-cad is described in a rather pure mathematical sense, sometimes in implicit form and sometimes in an explicit form
17:11.13abhi2011yes
17:12.28abhi2011however the positions of the objects are stored explicitly somewhere in a comb/prims attributes
17:12.44brlcadyes and no  (sorry multitasking)
17:12.52brlcadcombinations, for example, have no position
17:12.59brlcadthey are just a grouping
17:13.06abhi2011ah yes right
17:13.08brlcadthey can apply a transformation to that grouping
17:13.20abhi2011ok
17:13.21brlcadthat have an *implicit* position
17:13.35abhi2011ok
17:13.41brlcadit's implied that the position of a combination is the position of all it's continuent submembers
17:13.48abhi2011yes right
17:14.06brlcadso if you calculate that bb of a comb, for example, you could pretend that one of the corners or that the center is that comb's "position"
17:14.30abhi2011ok
17:14.36brlcadthe same can be said of all of the primitives
17:14.57brlcadmany/most of them have an explicit position, but it's defined per primitive
17:15.18abhi2011ok
17:16.25starseekerremembers he needs to look at rt_bot_bbox again...
17:16.26brlcadfor a sphere, it's the center point; for a cylinder, it's the center of the base oval; for a torus, it's also at the center which doesn't even happen to be *on* the object (it's in the void in the middle)
17:17.00brlcadyou could get at that "position", but it's somewhat meaningless for this purpose
17:17.10brlcadall that matters really is having a consistent handle
17:17.13brlcadthat's where the bb comes in
17:17.33abhi2011ok
17:17.35brlcadget the bb for any object, then you can consistently consider the bb center to be a position
17:18.00abhi2011ok
17:18.02brlcadfrom bullet's perspective, all you're dealing with is a lot of boxes
17:18.09abhi2011yes true
17:18.24brlcadyou can implement an overlap/collision detection handler later
17:18.42abhi2011however a bb would not roll on a surface even if it represents a sphere
17:18.49abhi2011yes right
17:19.00brlcadsure it will
17:19.24brlcadat least, it should be able to
17:19.47brlcadyou're not using the "box" as *geometry*
17:19.54brlcadthat's just your handle
17:19.59abhi2011yes right I get that now
17:20.20abhi2011its the handle to the geometry in mged
17:21.31brlcadthe bbox routines you're working with are also not oobb's, they' aabb's
17:21.42abhi2011yes right
17:22.25brlcadso even for simple arb8's, you'll not be able to get objects doing anything more than translating without collision detection
17:22.39brlcadtranslation should be the first proof-of-concept step though
17:22.58abhi2011ok
17:23.49brlcade.g., take a 10x10x10 axis-aligned box at 0 0 100, drop it to a ground plane at 0 0 0
17:24.06brlcaddemo should either stop immediately or bounce :)
17:24.12CIA-62BRL-CAD: 03starseeker * r46451 10/brlcad/trunk/src/other/CMakeLists.txt: when doing win, also need xlib
17:24.17abhi2011yes ok
17:24.51abhi2011but say the user runs the sim for 100 steps
17:24.56brlcadthat initial collision detection could rely purely on bullet since the bb's are all axis-aligned
17:25.23brlcador you write a collision detection routine that just returns 1 if the bb's overlap
17:25.23abhi2011ok
17:25.33abhi2011right
17:25.52abhi2011about setting the position of the box
17:25.57abhi2011in mged
17:27.14brlcadso for starters, you should only work with comb's for now (in mged and in code), just to keep things simple
17:27.18brlcadone entity type
17:28.07brlcadno primitives by themselves
17:28.43abhi2011ok, and I set the comb position by simply obtaining how far the object has translated along z axis and using rt_matrix_transform() to translate the comb to the new position
17:29.06abhi2011I mean *how far the* comb* has translated
17:29.28brlcadyou know how to apply a translation matrix, I presume?
17:29.53abhi2011yes, just pass it to rt_matrix_transform()
17:30.12abhi2011with the proper elements set
17:30.46brlcadthere are loads of vector and matrix routines in vmath.h and libbn (bn.h and src/libbn)
17:31.24abhi2011ok
17:33.16brlcadfor example
17:33.57brlcadthe 'rot' and 'orot' (aka orotate) commands are how rotations are applied to geometry within mged
17:34.09brlcadsrc/libged/rot.c and src/libged/orot.c
17:34.45brlcadyou can see there how rot.c sets up a rotation vector and calls bn_mat_angles() to obtain a rotation matrix
17:35.47abhi2011yes, I have seen rot.c and orot.c, they both transform the object's existing orientation
17:35.56brlcadsimilarly orotate.c calls bn_mat_angles() but then also bn_mat_xform_about_pt() along with some routines to normalize the matrix before applying it to a comb
17:36.28abhi2011so I would need to get the transform of the comb wrt the position of the comb at the beginning of the sim
17:36.46abhi2011so if the comb is say at position 0,0,100 and at the end of it at 0,0,1
17:37.19abhi2011then I would need the translation matrix to be set for a translation of 0,0,99
17:37.21abhi2011and not the translation with respect to the origin of 0,0,1
17:38.36brlcadfor translation (what you need first), tra.c is keen which sets up a translation vector then calls vutil.c
17:39.15abhi2011yes I checked that yesterday, quite straighforward code
17:39.57abhi2011the mistake I was making was applying the wrong translations (with respect to the origin)
17:40.05brlcadactually, if it starts at 0,0,100, it won't end at 0,0,1 .. :)
17:40.37abhi2011yeah it will fall to 0,0,0
17:40.58abhi2011at the end
17:41.25abhi2011before bouncing around
17:42.08abhi2011if the ground plane is at 0,0,0
17:42.37brlcadif the box is 10x10x10, and you're using center as V and ground at 0,0,0, then it'll stop at 0,0,5 :)
17:43.02abhi2011yes , i was ignoring the height, yes right
17:46.06brlcadso what I imagine will happen is you'll get the bb's for all objects, pass those to bullet to set up the scene, perform one timestep and bullet is going to return some information indicating that the box moves down (a vector) OR that the box is in a new position (a new position)
17:46.14brlcadif it's a vector, you just apply it like tra
17:46.42brlcadif it's a point, you calculate the vector based on the previous position and apply that vector like tra
17:47.13abhi2011yes , I would need to create a rigid body and give it a collision shape in bullet, so I ll just use a box for now
17:47.49abhi2011yes right
17:49.03CIA-62BRL-CAD: 03starseeker * r46452 10/brlcad/trunk/src/other/incrTcl/itk/CMakeLists.txt: Ah, right - if itk is taking responsibility for its path setting, need to be more complete.
17:55.07*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
18:03.34CIA-62BRL-CAD: 03n_reed * r46453 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Only reporting first syntax error instead of all of them.
18:06.22CIA-62BRL-CAD: 03starseeker * r46454 10/brlcad/trunk/src/other/incrTcl/itk/CMakeLists.txt: more itk build logic cleanup
18:14.07brlcadnice ... in response to "why reinvent the wheel?"
18:14.12brlcad"Because after long enough time, there's always someone who's irked about the performance of the wheel and wants to replace it with conveyor belts or robot legs. Sometimes even square wheels. And because we've done round wheels for so long, old lessons have faded or been deemed outdated and so we try it. Then it turns out it's not that great except for very limited use cases, but we're too deep invested and stubborn so we'll try fixing it. After a lot of fightin
18:15.48brlcadthat probably trucated the end...
18:15.50brlcad"After a lot of fighting against windmills, we slowly reinvent and rediscover the reasons why we used a wheel in the first place. Then the cycle starts over. Same with most NIH projects, they start out as being radically different and then end up looking much the same after tackling the same challenges."
18:17.01starseekerheh
18:18.07starseekersupposes some of the CMake logic probably would fall into that category...
18:20.51starseeker"oh, so THAT
18:20.58starseeker's why that compile flag is there"
18:45.17brlcadstarseeker: you could change the -D_FORTIFY_SOURCE=2 to a #define and you'd elimiante the MSVC conditional
18:46.09starseekererm.  you mean #define D_FORTIFY_SOURCE 2  in brlcad_config.h?
18:46.17starseekerhow would that eliminate the conditional?
18:46.38*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
18:46.54brlcadyou're presently checking for a "c flag" (which is bogus, it's a cppflag) named "D_FORTIFY_SOURCE=2"
18:47.02*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:47.12brlcadthat turns into -D_FORTIFY_SOURCE=2 to gcc
18:47.17starseekerright
18:47.26brlcadpresumably /D_FORTIFY_SOURCE=2 for msvc or something similar
18:48.06brlcadeither way, I assume you hit some compilation error due to that since the D_FORTIFY_SOURCE is rather lame gcc-specific way to test that flag
18:48.06CIA-62BRL-CAD: 03n_reed * r46455 10/brlcad/trunk/src/conv/obj-g_new.c: Added check for valid number of command line arguments.
18:48.17brlcadthat is equivalent to #define _FORTIFY_SOURCE 2
18:48.25starseekernot an error, just a blathering warning from MSVC
18:48.26brlcad-DVAR=VAL
18:48.36brlcadis #define VAR VAL
18:49.24brlcadso that's my point, you could eliminate the blather by outputting the symbol instead of trying to pass it as a compile flag
18:49.40brlcadless logic, no conditionals
18:51.07brlcadif (MSVC) conditionals make baby jesus cry, el no le gusta
18:51.11starseekershould it still be conditionalized on debugging?
18:51.15brlcadsure
18:51.20starseekerhmm...
18:51.59starseeker<snort> I'd say MSVC takes care of the crying all by itself
18:52.51brlcadsure, but it still gets to the whole platform vs feature issue -- the conditional is only valid today and is a major pita to maintain, debug, and unwind later
18:54.11brlcadthere's always a better way and it's usually not even more code if refactored according to dry principle
18:56.34CIA-62BRL-CAD: 03starseeker * r46456 10/brlcad/trunk/ (3 files in 3 dirs): Make _FORTIFY_SOURCE a config.h define instead of a compile flag check.
18:56.47starseekerthat what you mean?
18:57.45brlcadexactly
18:58.19starseekerwonders why he didn't do that initially... did I misread the autotools logic?
18:59.09brlcadwouldn't have been an msvc issue for autotools build
18:59.27brlcadmost all *nix platforms support -DVAR=VAL
18:59.37brlcads/platforms/compilers/ so the test works
18:59.48starseekerah, right
18:59.48brlcadthat assumption is flawed for non
18:59.54brlcad"non gcc-like" compilers
19:00.21brlcadCHECK_C_FLAG_GATHER must be something you wrote?
19:00.25starseekeryes
19:00.35brlcadbecause stfw results only in references to brl-cad :)
19:01.44starseekeryeah, there are a few custom macros - I really should probably try to cut down / consolidate those at some point
19:03.32n_reedbrlcad: stfw... your initialisms are starting to get obscure
19:14.59brlcad~stfw
19:14.59ibot[stfw] Search The F*cking Web.  See http://justf*ckinggoogleit.com/
19:15.56n_reedAlready looked it up.
19:17.02n_reedJust that "pita" took me a sec because it wasn't in caps. "dry" I knew, but stfw...
19:17.22brlcadwow, you knew dry but now stfw.. that's pretty much backwards ;)
19:17.36brlcaddry is pretty obscure
19:17.54brlcadhalf million hits for stfw can't be that obscure
19:18.20n_reedwell i don't text or chat as a rule, but i have read 97 things, so...
19:23.26brlcadstfw is pretty chat-specific, maybe even irc-specific
19:23.34brlcad(but not likely)
19:25.50``Erikdry is pretty big with ruby and python folk O.o
19:26.59n_reedof which i'm neither; that makes sense though i guess
19:56.29starseekerO.o  http://labs.qt.nokia.com/2011/08/24/qt-quick-3d-tutorial-video/
20:03.52CIA-62BRL-CAD: 03n_reed * r46457 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Allowing "" as a user-defined object name.
20:05.14CIA-62BRL-CAD: 03starseeker * r46458 10/brlcad/trunk/src/mged/CMakeLists.txt: Fix space in mged CMakeLists.txt - also did this for bwish, got sucked into a previous commit.
20:29.41starseekerwoot! new obj-g (kinda) works on Windows
21:14.36abhi2011brlcad:  I have a question regarding solid table pointers : const struct soltab
21:15.40abhi2011so is there a way to get one from the struct rt_db_internal of a primtive
21:16.30abhi2011I need to insert it into the rt_comb_internal
21:16.40abhi2011while finding the bb of a primtive
21:26.06abhi2011or I can avoid making a rt_comb_internal and just use the bounds already got in the rtip (as rt_gettree() has been called)
21:31.07abhi2011there is a third option to use ip->idb_meth->ft_bbox() which is the new interface for finding bbs of primitives, but thats known to not work correctly for BOTs
21:39.01abhi2011hmm found rt_find_solid(), will use that
22:11.48*** join/#brlcad merzo (~merzo@24-13-133-95.pool.ukrtel.net)
23:11.30CIA-62BRL-CAD: 03n_reed * r46459 10/brlcad/trunk/src/conv/obj-g_new.c: MSVC compiler doesn't support %zu format. Changed all instances to %lu.
IRC log for #brlcad on 20110830

IRC log for #brlcad on 20110830

00:57.35brlcadn_reed: MSVC doesn't need to support %zu for those functions, that's OUR function
00:58.24brlcadbu_log() implements support for %z along with the other bu_* vararg functions, so what was there before was correct
01:00.08starseekerit didn't work though
01:00.38starseekeron MSVC anyway
01:15.02brlcadwhy
01:16.09brlcadit's perfectly valid code, so if msvc is complaining, the complaint should be scrutinized as to why
01:16.53brlcadeither there was some *other* stdlib printf-style function it encountered with a %zu (in which case the "fix" should have been just for that instance)
01:17.51brlcador it really is complaining just because it thinks it recognizes a varargs-style function with print specifiers (in which case if it's trying to be that clever, there should be options to turn the behavior off)
01:18.39brlcadgiven we have %zu's sprinkled in hundreds of places throughout the code, and have for several releases, I find it a little hard to believe that it's the latter...
01:19.45brlcadon a somewhat related note... msvc is an environment where we've not yet vetted "warnings mean error" because it reports too many false positives by default, if that's coming into play
01:23.35brlcadif it's just a warning being spit out, there are hundreds of other places so that'd be a good one to just ignore in the output or disable for that compiler
01:44.30*** join/#brlcad merzo (~merzo@24-13-133-95.pool.ukrtel.net)
01:57.25starseekerit was incorrect behavior - printing "zu" instead of the number in question
01:57.40starseekerdunno if it was one instance in the code or not though - have to ask n_reed
01:58.48starseekerit compiles fine and runs, just getting the strings messed up somewhere along the line on WIN32
02:36.46*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:43.21brlcadyeah, that sounds like a bonefide libbu bug then
02:43.37brlcadall printf-style printing is consolidated into just one or two functions
02:44.26brlcadyeah, src/libbu/vls.c:bu_vls_vprintf()
02:44.58brlcadooh, I think I see the issue
02:57.00CIA-62BRL-CAD: 03brlcad * r46460 10/brlcad/trunk/CMakeLists.txt: might help to actually test for size_t :)
02:59.38starseekerwinces
02:59.41starseekerthanks
03:01.46CIA-62BRL-CAD: 03starseeker * r46461 10/brlcad/trunk/src/conv/obj-g_new.c: Put zu back - hopefully actually testing for size_t fixed it (oopsie).
03:02.05brlcadnot likely, working ona  fix
03:13.37CIA-62BRL-CAD: 03brlcad * r46462 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: take a stab at implementing a new build test for c99 format specifiers. not all of them, though, only care about %z for now since it's the one currently causing havoc with msvc builds.
03:18.21CIA-62BRL-CAD: 03brlcad * r46463 10/brlcad/trunk/CMakeLists.txt:
03:18.21CIA-62BRL-CAD: arguable whether testing libc supports %z as a print width specifier is a
03:18.21CIA-62BRL-CAD: compiler characteristic or type testing but go with the latter. add the (new
03:18.21CIA-62BRL-CAD: and untested) BRLCAD_CHECK_C99_FORMAT_SPECIFIERS macro so we can toggle code
03:18.21CIA-62BRL-CAD: logic based on HAVE_C99_FORMAT_SPECIFIERS
03:18.57brlcadstarseeker: feel free to sanity check my feeble cmake foo there
03:25.08CIA-62BRL-CAD: 03brlcad * r46464 10/brlcad/trunk/src/libbu/vls.c: use bu_strlcpy() instead of strncpy() since it guarantees null-termination which we were doing manually
03:33.16starseekermain concern is that HAVE_STDINT_H may not be defined in that context without setting a flag...
03:54.13CIA-62BRL-CAD: 03starseeker * r46465 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: This test succeeds on a platform where I would expect it to succeed - may need more tweaking, but I *think* this will do it.
03:54.32CIA-62BRL-CAD: 03brlcad * r46466 10/brlcad/trunk/src/libbu/vls.c:
03:54.33CIA-62BRL-CAD: add in initial logic to replace instances of %z in format specifiers for
03:54.33CIA-62BRL-CAD: platforms that don't support that c99 feature. since msvc is presently the only
03:54.33CIA-62BRL-CAD: known platform with this busted feature behavior, scan the format specifier and
03:54.33CIA-62BRL-CAD: replace instances of %z with %I which is presently more commonly found on
03:54.33CIA-62BRL-CAD: win32/win64 environments.
03:58.20CIA-62BRL-CAD: 03brlcad * r46467 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: we definitely need stdio.h (for sprintf()) but it shouldn't be conditional (c89 is required)
03:58.48starseekerbrlcad: you were checking for 1 as a return from sprintf, but even on gentoo it returns 3 (I'm fairly sure my system is new enough to support zu...)
04:01.05brlcadhm
04:05.36starseekerwhat about printing 1234 as a size_t and looking for 4 instead of 3?
04:07.28CIA-62BRL-CAD: 03brlcad * r46468 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: in that same vein, we need string.h for strcmp
04:09.38brlcadstarseeker: BRLCAD_HEADER_STDC looks somewhat useless as-is
04:09.54starseekerbrlcad: yeah, probably
04:10.00CIA-62BRL-CAD: 03starseeker * r46469 10/brlcad/trunk/misc/CMake/BRLCAD_CheckFunctions.cmake: tweak so that number of chars in number doesn't match number of chars in specifer
04:10.01brlcadiirc, the point of AC_HEADERS_STDC is to halt if they're available
04:10.02starseekerIIRC it was marked as obsolete
04:10.14brlcader, not available
04:10.23brlcadso we know not to even try proceeding
04:10.25starseekerusually I just define it as 1...
04:10.50brlcadit?
04:10.57starseekerwasn't sure if any of our supported platforms wouldn't have STDC
04:11.24brlcadwe've had a minimum compilation requirement of c89 for a couple years now
04:11.31starseeker#define STDC_HEADERS 1
04:11.58brlcadyeah, that's useless to set unless it's used somewhere by a 3rd party relying on it getting set
04:12.03brlcadif we rely on it, we shouldn't
04:12.19starseekerI think it's just tcl (where I'm hhandling it anyway)
04:12.40brlcadwe shouldn't be testing anything c89 provides as a strict matter of principle (other than as a build environment sanity check like I mentioned, to halt)
04:13.16starseekerthe only reason it was ever there was because I was going for full parity with the autotools build
04:13.37brlcadthen it should halt, not set a #define :)
04:13.59starseekerbrlcad: I was going to yank it
04:14.44brlcad*shrug*  it's fine in that one place, but it should serve a purpose (sanity test)
04:15.14brlcadthat's particularly why configure.ac has that whole block that itemizes which headers are c89, which are c95, which are c99, etc ..
04:15.22starseekerdoubt it's worth maintaining unless there's a realistic chance we'll need it - IIRC it was a bit of a poin
04:15.25starseekerpain even
04:15.46brlcadabsolutely shouldn't waste time testing for c89 headers, setting HAVE_*_H defines, nor wrapping them in #ifdef blocks
04:16.36starseekeryeah, looks like only tcl/tk really cares
04:17.06brlcadit's just 16 lines of "code" ... if that's painful ... some threshold might need adjusting :)
04:17.28starseekermore painful trying to figure out what the AC macro in question was doing
04:17.38brlcadthat macro by itself is inconsequential
04:17.40starseekerstill doubts he fully duplicated all of its testing
04:18.01brlcadit's more making sure we don't check for c89 headers in other places like you'd just added to that new macro
04:18.53brlcadundoubtedly, looks like you test for but never even use HAVE_STRING_H_MEMCHR
04:19.12brlcadand HAVE_STDLIB_H_FREE
04:19.55brlcadunless you make it halt, just yank it
04:20.21CIA-62BRL-CAD: 03starseeker * r46470 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_CheckFunctions.cmake): nevermind about STDC_HEADERS - we don't really need it, only tcl/tk really use it so let them deal with it.
04:20.28brlcadmore effective would be a test for exactly all of the c89 headers
04:21.33brlcadstarseeker: where'd be a good place to replicate the header comment block from configure.ac to help prevent folks from adding unnecessary tests?
04:22.10starseekerprobably stage 5 in the toplevel CMakeLists.txt file
04:22.16brlcadoh, duh ..
04:22.32brlcadsprintf returns number of chars printed -- was thinking sscanf
04:22.42starseekermost of the tests are there and should go there - CheckFunctions was for special stuff that needed something more complicated than just checking the include file
04:23.37starseekeragain based on the autoconf tests - it may be that a lot of those could be reduced to header checks on modern hardware
04:24.43starseeker(around line 1031 in CMakeLists.txt)
04:25.04brlcadah, already there .. got it
04:25.39starseekermostly went with what was in configure.ac - "foreign" tests that crept in usually resulted from AC_* macros of one sort or another
04:25.49brlcadmaybe worth a build system regression?
04:26.09starseekeroh, checking for improper tests?
04:26.41brlcadyeah
04:27.10brlcadprobably fine
04:27.35starseekershrugs - yeah, at some point that might be worth doing
04:27.51starseekeris hoping like heck that once this is done the build system will require only occasional tweaking
04:31.52brlcadno chance
04:32.31brlcadthe only time the build system doesn't require changes is when the source code doesn't change
04:33.35brlcadeven for fully managed IDE environments like msvc, you want/need/have to change the build system all the time as the code evolves
04:34.39CIA-62BRL-CAD: 03starseeker * r46471 10/brlcad/trunk/CMakeLists.txt: Hmm... it might be that platforms with multiple CFG types shouldn't share the same output directories... try this.
04:35.28starseekergrowl
04:35.31brlcadthe best you can aim for is make the build system logic simple enough to maintain and clean enough to be extended by a new/inexperienced developer easily
04:35.51brlcadthat's why I kept saying "this is still code"
04:36.35brlcadall the same coding rules and guidelines still apply, dry principle, neat organized code, concise yet descriptive vars, etc
04:38.08CIA-62BRL-CAD: 03brlcad * r46472 10/brlcad/trunk/CMakeLists.txt:
04:38.08CIA-62BRL-CAD: checking order changed. update docs. need to check compiler characteristics
04:38.08CIA-62BRL-CAD: earlier within cmake so that flags are set properly. remember there was a
04:38.08CIA-62BRL-CAD: specific reason for delaying the compiler testing until after headers/libs/types
04:38.08CIA-62BRL-CAD: with the autotools build but don't remember what that reason was any longer (and
04:38.09CIA-62BRL-CAD: it's not documented) so go with the flow -- makes more sense to test the
04:38.10CIA-62BRL-CAD: compiler flags earlier anyways.
04:42.11CIA-62BRL-CAD: 03starseeker * r46473 10/brlcad/trunk/CMakeLists.txt: typo, wording tweak
04:47.52CIA-62BRL-CAD: 03starseeker * r46474 10/brlcad/trunk/CMakeLists.txt: more rewording
04:50.45CIA-62BRL-CAD: 03starseeker * r46475 10/brlcad/trunk/CMakeLists.txt: I suppose the date/timestamp code failing to generate a date should be fatal - that has to be fixed if it breaks.
04:55.18starseekerhmm - I may need to keey the #define DEBUG statement off of something other than CMAKE_BUILD_TYPE...
04:55.38starseekermakes a note to check what that's used for tomorrow...
05:03.14CIA-62BRL-CAD: 03starseeker * r46476 10/brlcad/trunk/CMakeLists.txt: don't need the math expression anymore
07:27.29*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
08:08.14*** join/#brlcad merzo (~merzo@193.254.217.44)
08:35.31*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
10:32.48CIA-62BRL-CAD: 03n_reed * r46477 10/brlcad/trunk/src/libbu/vls.c: Typo; statement with no effect.
10:42.18*** join/#brlcad n_reed_ (44378e88@gateway/web/freenode/ip.68.55.142.136)
11:30.51*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl)
11:53.23*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:24.28brlcadthx n_reed, didn't get a chance to compile-test it yet
13:05.45abhi2011phew finally the bb function works for all cases
13:06.38abhi2011seems the tree returned in a struct rt_db_internal  by the function rt_db_lookup_internal(), has the wrong op codes
13:07.15abhi2011even if I use the dbip got from a rtip : rt_db_lookup_internal(rtip->rti_dbip, dp->d_namep, &dp, &intern, LOOKUP_NOISY, &rt_uniresource)
13:07.59abhi2011had to resort to getting the region for a passed comb (if the comb is a region) : regp = _rt_getregion(rtip, dp->d_namep);
13:08.18abhi2011once I get the region, then rt_bound_tree(regp->reg_treetop, tree_min, tree_max) always works
13:09.34abhi2011cant understand why the tree returned in the struct rt_db_internal by the function rt_db_lookup_internal() should have the wrong op_code
13:16.29abhi2011its certainly not due to a lack of preparing the rtip by using rt_gettree() etc
13:18.51*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:27.49brlcadabhi2011: what do you mean by wrong op code?
14:28.43abhi2011the code at the primitive node is set to OP_DB_LEAF (12) when it should be set to OP_SOLID (1)
14:30.11abhi2011so by the code i mean tr_a.tu_op
14:30.29abhi2011in the union tree of combp->tree
14:31.57abhi2011so one would expect this to work : http://bin.cakephp.org/view/716816388
14:32.09abhi2011but it returns the bb for a region as 0
14:33.41abhi2011because the tree could not be traversed completely due to the wrong code in tr_a.tu_op, which is used during the recursion in rt_bound_tree() as switch ( tp->tr_op)...
14:38.49abhi2011all the other functions which use rt_bound_tree()  find a matching a region by using for (BU_LIST_FOR(regp, region, &(rtip->HeadRegion))) {...
14:38.56abhi2011so they never encounter this problem
14:42.40CIA-62BRL-CAD: 03brlcad * r46478 10/brlcad/trunk/src/libbu/ (10 files):
14:42.40CIA-62BRL-CAD: rename all of the test programs to have a test_ prefix instead of a tester
14:42.40CIA-62BRL-CAD: suffix. makes them easier to identify and groups tests together. should help
14:42.40CIA-62BRL-CAD: keep things more organized moving forward as more unit tests are written.
14:45.46CIA-62BRL-CAD: 03brlcad * r46479 10/brlcad/trunk/src/libbu/ (test_basename.c test_htond.c test_progname.c test_timer.c): update file names in headers and usage
14:56.56brlcadabhi2011: the code is fine
14:57.17brlcadthat code just means that it's a leaf node (which it is) and that the node is still in db format (which it is)
14:57.56brlcadthe problem may just be that rt_bound_tree() needs to implement that switch case
14:58.51brlcadvery likely is the problem
15:00.58brlcadnice work on the new rt_bound_internal() though, looking great in that paste -- only issue I see are the exact (== 0) floating point comparisons at the bottom, those should be NEAR_ZERO())
15:51.33brlcadstarseeker: running cmake in debug mode and encountering some strange issues
15:52.37brlcadvariety of tests that fail but shouldn't, failures detecting 32bit/64bit, error about TEST_BIG_ENDIAN during debug but not during non-debug
15:56.49abhi2011brlcad: ok then I ll add a OP_DB_LEAF case to rt_bound_internal
15:57.02brlcadabhi2011: cool
15:58.09abhi2011just hope its that simple :P
15:59.36brlcadyou can't just pretend an OP_DB_LEAF is an OP_SOLID if that's what you're thinking
15:59.41brlcadyou have to add the logic for that case
16:01.26abhi2011yes i understand that, however I do expect the solid pointer to be present in tp->tr_a.tu_stp;
16:02.24abhi2011because a OP_DB_LEAF is the end of the line for the tree , there should no more recursion needed
16:02.32brlcadactually I believe that is exactly what OP_DB_LEAF means is not done yet
16:02.59brlcadif it's in db format, then a solid hasn't been loaded yet
16:03.04abhi2011yes
16:03.09abhi2011hmm
16:03.29abhi2011and rt_db_lookup_internal() always returns in db format
16:03.41brlcadlook around some other switch statements that use OP_DB_LEAF to see what they do
16:03.47abhi2011yes
16:05.58abhi2011umm but a question, why would the logic work if I get the same region using a match from : for (BU_LIST_FOR(regp, region, &(rtip->HeadRegion))) {...
16:06.07abhi2011somehow that is not in db format
16:06.50abhi2011the regions got from the rtip->HeadRegion contains a "all solids loaded" format which works with rt_bound_tree()
16:07.54abhi2011so something like this works : http://bin.cakephp.org/view/1320641560
16:08.23*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
16:08.26brlcadnot sure, but probably simply because it's just a different container -- gettrees happens to fill out a soltab because it needs it, yet the "other" one you get from lookup has not been loaded
16:09.24brlcadthe region search is a bit bogus, though .. not sure what that will do for models that have no regions defined
16:12.50abhi2011yes they would then have groups
16:13.21abhi2011but hmm, even for groups I search for regions that the group contains
16:13.36abhi2011it maybe that the group has just prims
16:41.06abhi2011hmm most cases using the OP_DB_LEAF simply play around with the prim name in tp->tr_l.tl_name , moving it from x to y :P
16:41.23abhi2011or they exists at the lowest db_* function level
16:42.22abhi2011dont see any case of converting a union tree with a OP_DB_LEAF op to a solid with usable geometry
16:45.35abhi2011I would have though that there would be a function which would accept a union tree with a OP_DB_LEAF in one of its leaves and look it up using the db_lookup() function, then fill it with the corresponding "all solids loaded" representation
16:45.41abhi2011something like that
16:46.39abhi2011maybe I can lookup the solid in the rtip using the tp->tr_l.tl_name, in the OP_DB_LEAF case
16:48.29brlcadeven if you can, that's pretty much self-defeating
16:48.36abhi2011yah :P
16:49.12brlcadbetter question to ask is how the OP_SOLID was created
16:49.48abhi2011very deep inside rt_gettree()
16:50.41abhi2011or rather rt_gettrees_muves()
16:55.22abhi2011hmm  db_walk_tree() in the above function preps the leaves
17:02.21abhi2011struct soltab *_rt_find_identical_solid() seems interesting
17:05.58CIA-62BRL-CAD: 03starseeker * r46480 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: Quiet potentially uninitialized warning.
17:54.44CIA-62BRL-CAD: 03brlcad * r46481 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am test_vls.c):
17:54.44CIA-62BRL-CAD: add a preliminary vls unit test to make sure our printing format specifier
17:54.44CIA-62BRL-CAD: behavior is consistent with stdio's behavior. particularly for non-standard
17:54.44CIA-62BRL-CAD: format specifier issues like %z and %ll, make sure something sane is happening.
18:10.58CIA-62BRL-CAD: 03starseeker * r46482 10/brlcad/trunk/ (CMakeLists.txt src/conv/obj-g_new.c): Ah, right - we include tcl headers, so we define STDC_HEADERS for them. Document that.
18:28.11CIA-62BRL-CAD: 03brlcad * r46483 10/brlcad/trunk/src/libbu/test_vls.c: expand to include more types, legths, and some precision tests.
18:30.19CIA-62BRL-CAD: 03brlcad * r46484 10/brlcad/trunk/src/libbu/vls.c: bu_strlcpy() size includes the null character, make sure len is adjusted accordingly
18:44.49CIA-62BRL-CAD: 03brlcad * r46485 10/brlcad/trunk/src/libbu/str.c: consistency in the >= logic -- looks like it is/was right, but was misleading how it was using the operator
18:48.32CIA-62BRL-CAD: 03brlcad * r46486 10/brlcad/trunk/src/libbu/vls.c: revert back to strncpy() until we can get a proper debug in.
18:54.42CIA-62BRL-CAD: 03erikgreenwald * r46487 10/brlcad/trunk/src/libbu/test_vls.c: mark unused variable
18:59.20``Erikhuh, for all asc2g runs: db_dirbuild(/usr/tmp/brlcadbuild/share/brlcad/7.20.3/db/xmp.g): improper database, _GLOBAL object attribute 'units'= is invalid
19:05.19brlcadyeah, that's probably r46486 off-by-one
19:10.10CIA-62BRL-CAD: 03brlcad * r46488 10/brlcad/trunk/src/libbu/vls.c: len is not -1
19:15.11*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:16.09abhi2011there is some code supporting the 'E' command which involves case OP_DB_LEAF
19:16.30abhi2011seems the directory pointer is lookedup using dp=db_lookup()
19:16.43abhi2011and then a solid is added using eptr = add_solid(dp, tp->tr_l.tl_mat, dgcdp);
19:18.28abhi2011hmm nope, its seems libged related , struct _ged_client_data has to be passed to add_solid()
19:18.38brlcad``Erik: does that fix it?
19:23.55starseekerbrlcad: fixes it here
19:25.59abhi2011brlcad: I think the only way to convert the OP_DB_LEAF would be to try and look it up using db_look()
19:26.16abhi2011prep.c uses that for example
19:27.04brlcadabhi2011: sounds reasonable
19:27.09abhi2011otherwise the only other way is to pick some code from rt_gettree() which is going to take quite a while
19:27.22brlcaddb_lookup() would be needed to get a handle on geometry anyways (at some point)
19:28.16CIA-62BRL-CAD: 03brlcad * r46489 10/brlcad/trunk/src/libbu/test_vls.c: put ac and av to good use
19:28.49abhi2011ok
19:29.17brlcadyou just shouldn't need an rtip
19:29.24brlcadit's a db operation
19:30.31brlcad(rt_gettree() obviously uses an rtip, but that's because it's specificially "getting geometry trees ready for ray tracing")
19:32.52``Erikbrlcad: yup
19:33.45brlcadcool, thx
19:35.07``Erik(hopefully their eyes don't bleed too much from my cmake patch) O:-)
19:48.54CIA-62BRL-CAD: 03brlcad * r46490 10/brlcad/trunk/src/libbu/test_vls.c: test more width, precision, and format specifier flags to make sure vls does what libc does
19:57.00starseekerbrlcad: http://www.cmake.org/pipermail/cmake/2011-August/046044.html
20:01.20brlcad"or the stuff from the previous try-compile might affect the next one"  <-- shouldn't happen, imho
20:01.58brlcadthat sounds like the bug to me or unexpected behavior at best
20:02.46brlcadgood to hear there's somewhat of a way to debug, but that's kinda beating around the bush
20:03.56starseekerbrlcad: I was going to ask if the behavior could be changed to saving the files of each test in its own subdirectory - did you want to respond yourself?  You'll undoubtedly make a more compelling case than I'll be able to
20:08.19brlcadI'd just say what I said here save the bush part, maybe ask why reuse the same directory (particularly given it makes the build tests stateful) .. the tests should be stateless, shouldn't matter if there was already output
20:08.33brlcad(it shouldn't read then write, it should write then read ...)
20:10.07brlcadotherwise, i'm not on that mailing list so I won't be responding anytime soon :)
20:10.25CIA-62BRL-CAD: 03brlcad * r46491 10/brlcad/trunk/src/libbu/test_vls.c: couple more tests
20:15.03starseekerurk https://sites.google.com/site/x32abi/
20:15.15starseekerjust in case 32/64 bit wasn't complicated enough...
20:29.01brlcad?
20:29.27starseekersounded like that might be yet a third option to the 32/64 bit option matrix...
20:29.35brlcadthat's just describing the 64bit abi
20:30.34brlcadoptions on how to run a 32-bit app on 64-bit platform (and do so portably per the abi)
20:31.00starseekerit says it's a "32bit psABI for x86-64 with 32bit pointer size" - does that just mean a 32 bit API for 64 bit hardware?
20:31.08starseekerah
20:31.18starseekerso no compiler flags needed (hopefully)
20:31.56brlcadthat's part of it, an implementation of part of the spec
20:32.48brlcadso you can run a 32-bit app with it's 32-bit pointers and have it play nicely
20:33.08brlcadnot something we'll likely have to care about
20:33.15starseekerphew
21:45.36CIA-62BRL-CAD: 03starseeker * r46492 10/brlcad/trunk/src/other/re2c.dist: add the new re2c file to the ignore list
22:29.20CIA-62BRL-CAD: 03n_reed * r46493 10/brlcad/trunk/src/other/lemon/CMakeLists.txt:
22:29.20CIA-62BRL-CAD: Lemon needs the template file in the same directory as the binary. On systems
22:29.20CIA-62BRL-CAD: using configurations, that means we need to copy this file into the
22:29.20CIA-62BRL-CAD: configuration binary directory, not just bin. May be more files where this is
22:29.20CIA-62BRL-CAD: true - TODO.
22:54.49*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
22:54.49*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
23:05.27*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
23:05.27*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
IRC log for #brlcad on 20110831

IRC log for #brlcad on 20110831

00:20.27*** join/#brlcad kanzure (~kanzure@131.252.130.248)
00:29.57abhi2011brlcad:  are globals allowed if its not possible to pass a variable to a function
00:30.44abhi2011I need a dbip in the rt_bound_tree() function but it cant be passed via parameters(assuming the currents parameters are not changed)
00:37.00*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
00:37.17abhi2011hm ok I ll just add it to the parameter list of rt_bound_tree()
00:37.54abhi2011oops no cant do that , its used in too many places already
00:59.35abhi2011global it is then
01:19.37CIA-62BRL-CAD: 03starseeker * r46494 10/brlcad/trunk/README.cmake: mention ccmake
01:27.59CIA-62BRL-CAD: 03starseeker * r46495 10/brlcad/trunk/CMakeLists.txt: Explain the DEBUG header definition a little more thoroughly.
01:28.36brlcadabhi2011: no, you cannot add globals to librt
01:28.55abhi2011yeah I made it an optional paramter
01:29.03abhi2011rt_bound_tree(struct rt_i * rtip = NULL, const union tree *tp, fastf_t *tree_min, fastf_t *tree_max)
01:29.12brlcadthere's no such thing as an optional parameter in C
01:29.16brlcadthat's a c++ism
01:29.24abhi2011ok
01:29.43brlcadwhat is it that you're trying to do?
01:29.58abhi2011i am trying to fill out the case OP_DB_LEAF:
01:30.22abhi2011so I am trying to lookup the encountered solid using stp = rt_find_solid(rtip, tp->tr_l.tl_name);
01:30.36abhi2011in that case
01:31.17abhi2011I havent come across any other way to convert the information present in a OP_DB_LEAF node to a OP_SOLID
01:32.00abhi2011in fact the only single information present is the prim name :P, which is really very less info to proceed on :P
01:32.20abhi2011other than doing a lookup of some sort
01:33.33brlcadwhat does that have to do with rt_bound_tree() though?
01:33.57brlcadi mean the rtip
01:34.11brlcadso you can call rt_find_solid within rt_bound_tree()?
01:34.16abhi2011yes
01:35.17abhi2011like this : http://bin.cakephp.org/view/820530027
01:36.48abhi2011the return internal from rt_db_lookup_internal() has really mucked things up
01:36.52brlcadso you can add a new parameter, but it'd need to be a different function (i.e., you'd need to copy most of rt_bound_tree()) because it breaks the API
01:37.02abhi2011yes
01:37.03abhi2011ok
01:37.29brlcadso back to the original idea
01:37.50brlcadjust add your own new function that converts the tp
01:37.57brlcadbefore it gets to rt_bound_tree()
01:38.26brlcadbasically a switch for just that case statement in a new function, called before rt_bound_tree()
01:38.36brlcadthat way you can pass an rtip or whatever else you may need
01:38.44abhi2011ok , this function will also recursively desend the tree
01:38.49abhi2011calling rt_gettree()
01:38.55abhi2011on any regions it encounters
01:39.00brlcadthat's fine -- maybe all the more reason to keep it separate
01:39.08abhi2011ok
01:39.13abhi2011that make sense
01:40.19abhi2011seems the delay in all this function will be much more than the way get_obj_bounds() does it
01:40.52abhi2011but ok, all this occurs before the simulation, so it should be ok
01:41.21brlcadthey're also not expensive operations
01:41.34abhi2011yes
01:41.47brlcadyou could probably convert a tp a hundred times over and still achieve 100fps updates
01:42.00abhi2011ok
01:42.58abhi2011yeah makes more sense to traverse recursively anyway, since it *is* a tree,no logical errors that way due to a model having no groups, or no regions etc etc
02:15.00*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
04:35.04CIA-62BRL-CAD: 03starseeker * r46496 10/brlcad/trunk/ (101 files in 13 dirs): (log message trimmed)
04:35.04CIA-62BRL-CAD: Took a stab at using http://www.projectpluto.com/win32a.htm (WIN32 native
04:35.04CIA-62BRL-CAD: curses) to get the terminal code working on Windows, but so far falling way
04:35.04CIA-62BRL-CAD: short of success. The termio_win32.c file doesn't seem to have much in the way
04:35.04CIA-62BRL-CAD: of contents, and termio.c doesn't want to build on windows (among other errors,
04:35.05CIA-62BRL-CAD: getting illegal indirection errors associated with copyTio). Even when using
04:35.06CIA-62BRL-CAD: termio_win32.c, MSVC doesn't want to generate a .lib file. The pdcurses demo
04:37.37brlcadneat
04:38.00starseekernot really - so far it's slapping me around for daring to think I could compile it :-/
04:38.28brlcadfwiw, plain ol pdcurses should be more than adequate for our needs
04:39.12starseekernods - the win32a variation has been actively maintained very recently, and is trying to be merged into the "mainline"
04:39.14brlcadwe don't actually use curses, so everything win32a implements/extends won't actually get invoked
04:39.20brlcadI noticed
04:39.25brlcadlooks good, if it works great
04:39.33brlcadif not, might try the fallback
04:39.39brlcadpdcurses is dead simple to compile
04:39.57starseekerpdcurses isn't the issue - it's getting our code to use it (so far)
04:40.21brlcadshouldn't even really need to modify our code
04:40.24brlcadjust link the lib
04:40.39starseekershakes his head - doesn't look like it
04:40.50starseekerif that were the case, the above would have worked a while ago
04:41.09brlcadthat presumes there's not bugs in win32a
04:41.10starseekerlibcursor needed BC and UC, which aren't provided by pdcurses
04:41.20starseekernods - fair enough
04:41.39starseekerand libtermio is a lot more annoying
04:42.09starseekersome of the compile errors for termio.c didn't appear related to termlib at all
04:42.36starseekerwould appreciate a second pair of eyeballs - I'm in a bit over my head
04:42.49brlcadthere's a lot of platform logic in there, it might need some minor mods
04:43.12starseekerI was planning to reverse-merge 46496 to leave the build in a working state, but if you want to take a wack at it I can leave it for now
04:43.23brlcadBC and UC aren't important, if it has tgetstr() then we're good
04:43.33brlcadtgetstr("bc", ...)
04:43.56starseekerseems to be in there
04:44.41starseekerhrm, actually...
04:45.28brlcadalso, presume you meant UP, not UC ..
04:45.41brlcadlibtermlib defines those two globals
04:45.49starseekerer, yeah
04:45.57brlcadbut they're not really needed
04:46.25brlcadso that'd be a two-line mod if pdcurses left them out for some reason (unlikely)
04:46.58brlcadI don't have a windows environment set up at the moment to test it
04:47.27starseekerbrlcad: you can bump nick off my box temporarily tomorrow ;-)
04:47.51starseekeris not reassured by this: (main pdcurses sources, not just win32a) http://pdcurses.cvs.sourceforge.net/viewvc/pdcurses/PDCurses/pdcurses/terminfo.c?revision=1.37&view=markup
04:48.00brlcadI'm backlogged with NURBS and GS work, it'll have to wait a bit
04:48.19brlcadthat's a good friday or weekend project
04:48.24starseekernods
04:48.34starseekerk - I'll revert it for now then, so the build still works for nick
04:49.05brlcadwhy is that not reassuring?  what's it's supposed to reassure?
04:49.10starseekershouldn't have tangled with it either, just an impulse
04:50.13CIA-62BRL-CAD: 03starseeker * r46497 10/brlcad/trunk/ (11 files in 10 dirs): Revert 46496 until more work can be done on it - leave trunk in a working state. Main point was to checkpoint, and revision history now has work done so far.
04:50.43starseekertgetstr is a stub
04:50.50starseekerdoubts we want a stub
04:52.06starseekeri.e. not a good sign
04:54.38starseekermakes a note at some point to try the ersatz editor against pdcurses - that would be nifty it if ended up working
04:55.05*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
04:55.18starseekersplits before he gets in any worse trouble ;-)
04:55.43brlcadheh
05:03.48starseekererk:  pdcurses term.h:  PDCurses doesn't operate with terminfo, but we need these functions for compatibility, to allow some things (notably, interface libraries for other languages) to be compiled. Anyone who tries to actually _use_ them will be disappointed, since they only return ERR.
05:04.14starseekerreally splits this time
05:27.27*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
06:18.45starseekermakes a note of this article for possible future reference: http://www.halcyon.com/~ast/dload/guicon.htm
06:46.26starseekerthis might be a useful guide for making an editor that doesn't use terminfo:  http://sandyeditor.sourceforge.net/
06:56.49*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:03.05starseekerwinces http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/win-command-prompt.html
07:03.33starseekertoo bad he didn't succeed, that sounds quite interesting
07:16.56starseekerhumph - ersatz against pdcurses is a no-go
07:19.07starseekerheavy terminfo use
07:45.29*** join/#brlcad merzo (~merzo@193.254.217.44)
14:01.38starseekerif I thought I could get away with it I'd CMakeify vim for cross-platform building and use that (maybe with vimacs mode...)
14:11.01``Eriknvi might be easier
14:20.20starseekerlooks like it needs terminfo of some sort too
16:04.20*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
16:08.10*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
17:10.33*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-185-119.wlan.tudelft.nl)
17:46.38CIA-62BRL-CAD: 03n_reed * r46498 10/brlcad/trunk/src/ (3 files in 2 dirs): Group names were being stored in volatile memory, causing garbage output. Now copying strings to memory we actually own.
18:16.12CIA-62BRL-CAD: 03n_reed * r46499 10/brlcad/trunk/src/conv/obj-g_new.c: Addressed compiler warnings.
18:44.56*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
18:47.41CIA-62BRL-CAD: 03starseeker * r46500 10/brlcad/trunk/src/tclscripts/mged/ (CMakeLists.txt exists.tcl tclIndex): add exists command to check whether a db object exists - maybe should be a libged cmd...
18:49.02CIA-62BRL-CAD: 03starseeker * r46501 10/brlcad/trunk/src/tclscripts/mged/ (CMakeLists.txt exists.tcl tclIndex): Nevermind, Bob is doing a libged version
19:06.37CIA-62BRL-CAD: 03starseeker * r46502 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: cmake -E rename isn't and won't be functional across multiple volumes - use cp or copy if we can find them, and rename as a last resort if we can't
19:19.22CIA-62BRL-CAD: 03bob1961 * r46503 10/brlcad/trunk/src/tclscripts/archer/ (CMakeLists.txt PipeEditFrame.tcl): Added the initial code for editing pipes in Archer. More to come.
19:20.42CIA-62BRL-CAD: 03bob1961 * r46504 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added the initial code for editing pipes in Archer. More to come.
19:23.52CIA-62BRL-CAD: 03starseeker * r46505 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: Er whoops, need mv/move, not cp/copy. builds once more
19:23.57CIA-62BRL-CAD: 03bob1961 * r46506 10/brlcad/trunk/src/tclscripts/archer/ (21 files): Calling GeometryEditFrame::updateGeometry.
19:31.06CIA-62BRL-CAD: 03bob1961 * r46507 10/brlcad/trunk/ (6 files in 5 dirs): Added ged_exists() in libged to check for the existence of a database object and make it available in mged and archer.
19:45.11CIA-62BRL-CAD: 03n_reed * r46508 10/brlcad/trunk/src/conv/obj-g_new.c: Freeing all group strings and containing array; should be leak-free again.
19:52.37*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
20:04.11``Erikstarseeker: "catch [get $name]" isn't good enough? O.o
20:08.20CIA-62BRL-CAD: 03starseeker * r46509 10/brlcad/trunk/CMakeLists.txt: X11 is an advanced option under Windows, mark it as such.
20:11.33starseekernope
20:38.53CIA-62BRL-CAD: 03starseeker * r46510 10/brlcad/trunk/ (4 files in 3 dirs): Start working on how to test for hypot on Windows - most of the warning messages we're getting in MSVC seem to relate to redefining that function in config_win (I think)...
20:40.55CIA-62BRL-CAD: 03starseeker * r46511 10/brlcad/trunk/ (CMakeLists.txt include/config_win_cmake.h.in): give this a hypot test a shot... don't know if it will work, untested
20:43.35*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:50.13CIA-62BRL-CAD: 03starseeker * r46512 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/test_srcs/hypot_test.c): try required libs and check_function_exists
20:54.50*** join/#brlcad juanman (~quassel@186.136.168.73)
20:54.52*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
21:12.17*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
21:30.33CIA-62BRL-CAD: 03starseeker * r46513 10/brlcad/trunk/ (3 files in 2 dirs): utter failure - cannot confirm hypot is present as a function, always get unresolved errors even when I manually feed it msvcrt. revert for now
21:42.39CIA-62BRL-CAD: 03bob1961 * r46514 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Add "exists" to the help object.
21:44.07CIA-62BRL-CAD: 03bob1961 * r46515 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Using the exists command in a few places. It's cleaner.
21:55.54CIA-62BRL-CAD: 03starseeker * r46516 10/brlcad/trunk/ (3 files in 2 dirs): Try again - take a hit from kicad and use check_symbol_exists this time, let's see how that does
22:10.13*** join/#brlcad Yoshi477 (~jan@bas1-guelph22-1177695115.dsl.bell.ca)
22:20.48starseekeryes, much better
22:49.28*** join/#brlcad Yoshi477 (~jan@bas1-guelph22-1177620315.dsl.bell.ca)
22:54.47*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
23:19.34CIA-62BRL-CAD: 03n_reed * r46517 10/brlcad/trunk/src/ (conv/obj-g_new.c libgcv/wfobj/obj_parser_state.h): Properly allocating and freeing the rest of the file strings.
23:19.42*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20110901

IRC log for #brlcad on 20110901

00:13.02*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
00:33.34CIA-62BRL-CAD: 03abhi2011 * r46518 10/brlcad/trunk/src/librt/bbox.c: Modified the BB function to get the BB for groups, combs and prims through tree traversal
00:39.47*** join/#brlcad juanman (~quassel@201.255.13.201)
00:39.51*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
00:55.00CIA-62BRL-CAD: 03starseeker * r46519 10/brlcad/trunk/include/raytrace.h: fix the rt_bound_internal header definition
01:18.01CIA-62BRL-CAD: 03starseeker * r46520 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: There's a TODO item to check for the -mss3 compiler flag - this does so and adds it, but raises the qeustion about the original concerns documented for sse flags
02:18.57*** join/#brlcad DarkCalff (DC@173.231.40.98)
02:28.19CIA-62BRL-CAD: 03brlcad * r46521 10/brlcad/trunk/src/conv/obj-g_new.c: don't peek into the struct, bu_vls_addr() was correct. vls_str is just the internal memory buffer allocated which may be offset and truncated.
02:33.04CIA-62BRL-CAD: 03brlcad * r46522 10/brlcad/trunk/src/conv/obj-g_new.c: ws consistency, indent, trailing ws
02:41.30CIA-62BRL-CAD: 03brlcad * r46523 10/brlcad/trunk/src/libgcv/wfobj/obj_parser_state.h: simplify, there's a libbu bu_strdup() function for copying strings (and if there wasn't, there's a libc function for that too, strdup()).
02:50.38CIA-62BRL-CAD: 03n_reed * r46524 10/brlcad/trunk/src/ (conv/obj-g_new.c libgcv/wfobj/obj_parser.cpp): Don't have to copy vector elements to array since C++ promises they are contiguous.
02:59.46CIA-62BRL-CAD: 03brlcad * r46525 10/brlcad/trunk/src/libgcv/wfobj/obj_parser.cpp: should be using c++ or (better) libbu memory management so error behavior is consistent during out-of-memory conditions. signatures don't match, though, so not a drop-in replacement as a registered callback function.
03:04.29brlcadstarseeker: if you're testing for hypot, you could just add it to brlcad_config.h instead of config_win.h .. the latter should nearly go away entirely with cmake
03:04.59brlcadwe couldn't test for them with autotools, so here's a place where cmake can outshine if it's cleaned up
03:05.42brlcadeverything it was just setting should be a functionality test (that either is tested every time or at least run if msvc)
03:17.08*** join/#brlcad n_reed (44378e88@gateway/web/freenode/ip.68.55.142.136)
03:18.18starseekerbrlcad: it's a little different... I need to define hypot to _hypot if hypot isn't a symbol... I don't actually know how hypot and math.h are set up elsewhere... hmm...
03:19.12starseekeragain rams his head into the hard reality that There Is No Good non-GPL Open Source Terminal Emulation For Windows
03:21.24starseekerbrlcad: is libtermlib in src/other portable to Windows?
03:29.35starseekeryeah, the test needed for windows will fail when it shouldn't on Linux
03:30.35starseekerand check_function_exists refused to work on windows
03:33.18starseekerhowever, even in the worst case I can certainly do the MSVC tests and add them to brlcad_config.h instead of config_win
03:33.56starseekerhave to be careful about maintaining the order in which they appear in the header though
03:35.07starseekersafe way to go would be to make some MSVC_TEST macros that would generate a config_win the way brlcad_config is being generated now
03:35.40starseekerwould eliminate the hardcoded file, but still maintain the position of config_win relative to brlcad_config in the include order
03:38.37starseekerhmm - have we ever looked at this?  http://en.wikipedia.org/wiki/Tera_Term
03:40.17starseekermight just be another putty...
03:42.12n_reedI think I've heard it mentioned in the same sentence as putty before
03:46.56CIA-62BRL-CAD: 03n_reed * r46526 10/brlcad/trunk/src/libgcv/wfobj/obj_parser_state.h: Changed remaining instances of local string copy to bu_strdup. This memory is freed in obj-g_new.c.
03:49.46starseekeryeah, same as putty - if they go local they use the cygwin term stuff
03:49.58starseekercygwin seems to be the only game in town
03:58.44CIA-62BRL-CAD: 03brlcad * r46527 10/brlcad/trunk/src/conv/obj-g_new.c: bu_free_array() does the same as free_lib_array() plus a sanity null
04:00.22n_reedclearly there is a bu routine for everything
04:02.18CIA-62BRL-CAD: 03brlcad * r46528 10/brlcad/trunk/src/conv/obj-g_new.c: reorder to avoid forward decl
04:05.04brlcadstarseeker: they're all just symbols that exist or don't exist, how's that different?
04:05.53brlcadthinks you're making it more complicated than it needs to be
04:06.21starseekera quick test I just did indicates neither hypot nor _hypot exist as symbols directly on linux
04:07.12brlcadI don't believe that
04:07.24brlcadmore than likely, the test was flawed
04:07.39starseekerme either, but the tests did not succeed (either CHECK_SYMBOL_EXISTS or CHECK_FUNCTION_EXISTS)
04:07.50brlcadand why did they fail exactly?
04:08.10brlcadmore exactly, if you wrote a little main with hypot, does it work?
04:08.37brlcadtaking cmake out of the picture first will tell you if it's a test setup problem
04:09.06*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
04:09.45``Erikum, with ffast-math, several math 'functions' become "magic" keywords to gcc
04:09.52brlcadfrom a pure feature test perspective, the way to platform-agnostically "do it right" would be to test for hypot, if not found then test for _hypot, if not found then error else #define _hypot hypot
04:10.29brlcadlast time I tested it, ffast-math won't pass benchmark validation
04:10.54``Erikcompile/link with the same flags should find 'em (as a "run" test), but a pure compile/link test might show weirdness in some circumstances
04:12.01brlcadeven with ffast-math, you can still capture a pointer to the function and it should compile/link
04:12.03``ErikI think fabs is in the same bucket
04:12.15``Erik(haven't read backlog, just got home)
04:14.41``Erik(or mebbe it was an -O level that changed 'em from libray funcs to intrinsics, hrm)
04:18.21starseekereither way, the simple test is not working, which means it's not just a snap of the fingers to do this
04:19.07starseekerthe hypot case was important because it's extremely noisy in VS10, but otherwise it's not terribly urgent
04:20.58starseekeroh, that remeinds me
04:21.02starseekerbrlcad: http://www.cmake.org/pipermail/cmake/2011-August/046059.html
04:22.15starseekerwriting a main with hypot does not work in isolation, I have to include math.h
04:22.37brlcadI still don't buy his reasonsing -- of course it'd leave a lot of dirs if there were a lot of tests
04:22.39starseekerbut math.h does not directly define hypot the way it does in MSVC - tis somewhere further down the include list
04:22.51brlcadbut then the user asked for all of those tests to get left around
04:23.01starseekerbrlcad: oh, I agree - my initial response was "yeah, it's a lot of dirs... so?"
04:23.39brlcadstarseeker: I expect hypot() to fail on windows
04:23.46brlcadit's a c99 function, msvc is not c99 compliant
04:23.57starseekerit did, until VS10
04:24.21brlcadit has/had _hypot()
04:24.34starseekeressentially, VS10 does the #define hypot _hypot in math.h for us
04:25.38brlcadso then back to the original assertion that it should be sufficient to test for hypot, if not found then test for _hypot, if not found then error else #define
04:26.03starseekerright - but the test for hypot that succeeds on Windows fails on Linux
04:26.04brlcadif that means a simple custom test, that's still a very simple test
04:26.24brlcadso why does linux fail?
04:27.04brlcad#include "math.h" ; int main(int ac, char *av[]) { return (int)hypot(1.0, 2.0); } fails?
04:27.12brlcadyou probably need -lm
04:28.29brlcador LIBM or whatever you tested earlier
04:29.17starseekeryeah, looks like it
04:29.45starseekerI can write a macro to do that, I guess
04:30.43brlcaddoesn't cmake already do that?
04:30.54brlcadhow are functions tested if you can't specify link libraries?
04:31.10starseekerthere's a global variable you temporarily populate
04:31.45*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
04:32.27brlcadsounds akin to how you do it in autotools for custom tests, but standard func tests had that already built into the macro (because it's pretty much necessary)
04:33.58starseekersome of the macros have the extra options to let you pass stuff - check_symbol_exists doesn't happen to be one of them, so a BRLCAD_CHECK_SYMBOL_EXISTS wrapper is in order
04:35.09starseekercan also add an option for a "fallback" symbol that is used for a define (e.g. BRLCAD_CHECK_SYMBOL_EXISTS(hypot "math.h" HAVE_HYPOT _hypot) or some such
04:35.41starseekerer BRLCAD_CHECK_SYMBOL_EXISTS(hypot "math.h" "${M_LIBRARY}" _hypot) rather
04:35.53brlcadcheck_library_exists didn't do it?
04:37.10brlcadI wouldn't recommend having a fallback -- even on windows, some of them have _funcs and some don't (and it has changed over the years across versions of msvc)
04:37.13starseekerhmm... that might have worked - wasn't my first thought, as I wasn't looking to confirm that the library exists but detect a symbol within it
04:37.32brlcadreally are two separate tests, might as well be named "foo" and "bar"
04:37.57brlcadcheck_library_exists tests whether a function is in the specified library
04:38.04starseekershakes his head - in this case, testing for _hypot and doing the #define hypot _hypot is conditional on the outcome of the first test
04:38.58brlcadthem being conditional doesn't mean they're not separate tests, it's what you do with the results that is conditional
04:39.21*** part/#brlcad n_reed (44378e88@gateway/web/freenode/ip.68.55.142.136)
04:39.40starseekertesting for _hypot is a total waste of time if we have hypot though
04:40.02brlcadof course, you test for hypot first
04:40.11brlcadit's just nested testing
04:40.33brlcadif test funcA fails, test funcB; if test funcB succeeds, "do something useful" .. which in this case is #define funcA funcB
04:40.35starseekeroh, I know why check_library_exists wasn't the right approach - with MSVC, there IS no math library
04:40.38starseekerM_LIBRARY is empty
04:40.50brlcadnot true
04:41.05starseekerour M_LIBRARY variable is empty
04:41.06brlcadthere IS a math library .. it's just not self-contained
04:41.13brlcadsure
04:41.18starseekerthat's what matters
04:41.21brlcadthere is not "m.dll :)
04:41.27starseekerright
04:41.55brlcadso you're not testing all the possible libraries that might have that symbol
04:42.20starseekeron Windows it's not necessary - we don't have to specifically link a math library
04:42.50brlcadirrelevant from a configuration perspective
04:43.28*** join/#brlcad BenDansie (~chatzilla@182-239-205-11.ip.adam.com.au)
04:44.14brlcadI'm not disagreeing, this is all old old news to me :) .. it's how to think about solving the problem in generic non-platform specific terms
04:44.28BenDansieHi all
04:44.44brlcadthis isn't really specific to windows, there are other symbols that behave exactly like this for other platforms/environments
04:44.48brlcadBenDansie: hello
04:44.57starseekerbrlcad: sure, but there are practical aspects to this - our Windows config is already a factor of 10 longer than any other platform
04:45.12starseekerall of these new tests we're talking about here will make that worse
04:45.24brlcadour source code is probably a factor 10 larger than other software too, not sure that matters
04:46.04starseekerI mean it takes forever to run a CMake config on Windows - from a development cycle standpoint, lengthening it further sucks
04:46.26brlcadlike the earlier discussion -- IFF after all the tests are added it really drags things down, then the tests could all get wrapped in *just one* big if-MSVC-then-do-these-tests conditional
04:46.28starseekerI'm not denying it may be worth it from a "cross platform cleanliness" standpoint, but it will have an impact
04:47.14BenDansieHope I'm not interrupting, but could someone lend me a hand with how to import an iges file and export to something else like stl or obj? I'm new to BRL-CAD. Would be greatly appreciated
04:47.58brlcadadding 10 min to the windows build at arl is frankly inconsequential, that's a limitation of that environment and specific to that platform
04:48.01brlcadthe build already takes a couple hours, barely a blip
04:48.15brlcadBenDansie: it depends what kind of iges file you have
04:48.30brlcadit'll either work or crash and burn
04:49.26brlcadthe iges importer hasn't been updated in quite a while so there are several "gotchyas" possible, some out of our control, some specific to iges versioning, some specific to what software exported the iges file
04:49.41BenDansieRight. The deal is I work for a multimedia company, and we've been supplied the .igs file straight from the cad designers. So we are figuring it out as we go to convert the file into something we can use.
04:50.06BenDansieSo assuming it works, what is the process? Trying to read through the documentation on the website
04:50.18brlcadwhat software are you trying to use the geometry in?
04:50.38brlcadiges-g has pretty extensive usage
04:51.16brlcadiges-g -d -o file.g file.igs
04:51.21brlcador -3 instead of -d
04:51.47brlcador maybe -p in addition to -d
04:51.53starseekerif it brings in spline/NURBS surfaces, that's not going to export to an stl file at the moment
04:51.54BenDansie3ds Max, which has an importer, but it fails on the larger of the two files we need.
04:51.55brlcadit totally depends what's in the .igs file
04:51.57BenDansiethanks
04:52.28brlcadthat doesn't bode well if 3dsmax fails :)
04:52.57BenDansieah. Rhino also fails, but due to memory. Rhino still being 32 bit
04:53.06brlcadI can take a quick look at trying the conversion myself if you care to share the datafile
04:53.08starseekerBenDansie: can you have them send you several smaller .igs files with pieces?
04:53.36brlcadcould be a simple matter of blowing out 32-bit memory, in which case you may need a 64-bit compile of BRL-CAD too
04:53.45brlcadthough I suspect our iges importer is leaner than 3ds
04:54.35brlcadnotes that exists is a nice parallel to "test"
04:54.52brlcadshould use a similar syntax
04:55.30brlcadstarseeker: that's up there with 'search' ;)
04:55.37brlcada lot simpler to implement though
04:55.56starseekererm... test being the unix command line program test?
04:56.11BenDansieWell, step one is to go back and grab the 64 bit version it seems... :)
04:56.42starseekerreads the man page...
04:58.10starseekerirk.  there are a few dragons here.  what does it mean for an object to be greater than or less than another object?  we don't support modification date for objects (at the moment, anyway)...
04:59.07starseekerthe -d, -f, etc options would probably translate into something like test -g sph obj1.s, test -g eto obj1.s, etc...
05:00.42starseekercould really go hog wild and do test -O obj1.s obj2.s for overlap testing :-P
05:01.34starseekeror I guess test obj1.s -O obj2.s would be more in keeping with the STRING1 = STRING2 theme
05:02.11starseekerwould have to be dbtest though - looks like test does something in tcl
05:04.06brlcadstarseeker: right, so the date-baesd tests cannot be implemented today (but will be with rel8)
05:04.32brlcadthe other >, < tests are lexicographical, though, are trivial to implemnet
05:04.50starseekersure, if we go with string comparisons of the names
05:05.01brlcadand EXACTLY regarding specialty options like overlap testing
05:05.06starseekerrather liked the idea of bounding box volumes...
05:05.10brlcadthat'd be the bomb
05:05.34brlcad"test" does existance, date, lexi, and more
05:06.11brlcadexists even works as an alternate name like search:find
05:06.33BenDansie"file is not in iges ascii format" - am I out of luck on this one?
05:06.41brlcaddoes foo exist lexicographically before bar?  well:  exists foo < bar
05:07.07brlcadBenDansie: no, there are binary and ascii versions of iges files
05:07.45brlcader, scratch that
05:07.50brlcadthinking of a different format
05:08.19starseekerconsiders exists vs. dbtest... hmm. exists might be a little too specific for something so general
05:08.55starseekerexists "works" lexicographically perhaps, but I wouldn't have thought of it out of context
05:09.15brlcadBenDansie: do you know if your file is binary or ascii?
05:09.44starseekeror we could make a ged tcl namespace and stuff all of our commands in there, then default to that namespace in mged
05:10.16starseekerrequire explicit tcl namespace calls or a "set namespace tcl" option or some such
05:10.33starseekerthen search really could be find and test could be test :-)
05:11.41BenDansieahah! making progress now. Seems the first time I tried I did the export filenames the wrong way around and wrote over the .igs
05:11.48brlcadif you read the manpage for test, most of the tests are "does this exist"
05:11.51BenDansiecopied the original again and got further
05:12.01brlcadthat's what makes "exists" a particularly good fit
05:12.53brlcadBenDansie: aha, that'll do it ;)
05:13.16starseekerchecks out the bsd test codebases... yay, another deliverable nobody asked for :-P
05:13.35brlcadI wouldn't even use bsd as a starting point
05:13.52brlcadthe tests are simple to write
05:14.38starseekerwas thinking the multiple expression evaluation logic
05:14.45brlcadah, perhaps
05:14.57BenDansieConverting solid entities:
05:14.58brlcadthat is pretty powerful stuff
05:14.59BenDansieNo parameter curve for eu x5a97f20
05:15.00BenDansieivert=x67c9b20, jvert=x67ca0c0, eu->vu_p->v_p=x67ca0c0, eu->eumate_p->vu_p->v_p=
05:15.00starseekerEXPRESSION1 -a EXPRESSION2 etc.
05:15.02BenDansiex67ca0a0
05:15.03BenDansieAdd_nurb_loop_to_face: Edgeuse/vertex mixup!
05:15.18brlcadBenDansie: don't use -n
05:15.20starseekersounds like it's importing NURBS
05:16.09brlcadnor -t
05:16.49brlcadif you run without any options, it should give an analysis of what is in the file
05:16.55brlcadiges-g -o file.g file.igs
05:17.05brlcadprobably saying, "try adding -3"
05:17.43brlcaddefault may even work if you're REALLY really REALLY lucky
05:22.31starseekersweet - public domain even:  http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/bin/test/test.c
05:23.35starseekerwill vacuum out the file specific stuff tomorrow and see about converting that into exists
05:26.23CIA-62BRL-CAD: 03brlcad * r46529 10/brlcad/trunk/TODO: the new 'exists' command is a beautiful corollary to the unix 'test' command.. embrace the familiar usage (make it the same where possible) and extend with geometry-specific features.
05:27.12brlcadI love how core unix commands are so short and sweet, easy to understand and modify
05:27.35brlcadgreat examples of how less is more
07:48.36*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
09:42.49*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
09:42.50*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
09:43.47*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
10:13.56*** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220)
10:46.37CIA-62BRL-CAD: 03Ontwe 07http://brlcad.org * r3087 10/wiki/Wiki_Support_for_unexperienced_users: New page: New Users often need help about [http://www.mediawiki.com Mediawiki]
11:03.37*** join/#brlcad merzo (~merzo@193.254.217.44)
12:31.49*** join/#brlcad piksi (piksi@pi-xi.net)
12:32.45*** join/#brlcad piksi (piksi@pi-xi.net)
12:42.44*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:07.11*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:15.45CIA-62BRL-CAD: 03erikgreenwald * r46530 10/brlcad/trunk/src/conv/obj-g_new.c: cast const char** to char ** to match type. Add missing third parameter to bu_free_array.
13:40.58CIA-62BRL-CAD: 03erikgreenwald * r46531 10/brlcad/trunk/src/libgcv/bottess.c: Convert big scary macros to functions. Change explicit static to HIDDEN. Add more optional output.
13:49.59CIA-62BRL-CAD: 03erikgreenwald * r46532 10/brlcad/trunk/src/libgcv/bottess.c: remove inline keyword
14:08.18CIA-62BRL-CAD: 03n_reed * r46533 10/brlcad/trunk/src/conv/obj-g_new.c: Should be passing char**, not char***, to bu_free_array.
14:15.07abhi2011anyone else getting an error during install like : CMake Error at include/cmake_install.cmake:36 (FILE):  file INSTALL cannot find  "/home/abhi/socis/brlcad/include/config_win_cmake.h".
14:34.37CIA-62BRL-CAD: 03erikgreenwald * r46534 10/brlcad/trunk/TODO: add marching cubes to libged facetize
14:38.51brlcadgah, we really need to get continuous integration going ..
14:38.56brlcadtoo many commit/compile failures
14:39.48CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Wiki Support for unexperienced users]]": content was: 'New Users often need help about [http://www.mediawiki.com Mediawiki]' (and the only contributor was '[[Special:Contributions/Ontwe|Ontwe]]')
14:41.25CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Ontwe]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
14:51.39CIA-62BRL-CAD: 0391.124.110.50 07http://brlcad.org * r3088 10/wiki/Google_Summer_of_Code:
14:53.11*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:00.11CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r3089 10/wiki/Google_Summer_of_Code: Reverted edits by [[Special:Contributions/91.124.110.50|91.124.110.50]] ([[User talk:91.124.110.50|Talk]]); changed back to last version by [[User:Sean|Sean]]
15:30.15starseekerabhi2011: ah, sorry - that's me
15:30.25starseekerabhi2011: one second...
15:32.52CIA-62BRL-CAD: 03starseeker * r46535 10/brlcad/trunk/include/CMakeLists.txt: Ooops, right - config_win_cmake is now a configure_file, treat it accordingly.
15:34.38starseekerthat should do it
15:34.44starseekerbhinesley: around?
15:43.47CIA-62BRL-CAD: 03d_rossberg * r46536 10/brlcad/trunk/src/librt/bbox.c:
15:43.47CIA-62BRL-CAD: for the Windows build: MSVC is not C99
15:43.47CIA-62BRL-CAD: moved variable declarations upwards
15:51.46CIA-62BRL-CAD: 03n_reed * r46537 10/brlcad/trunk/src/conv/obj-g_new.c: Freeing the rest of the arrays with bu_free_array.
16:20.53CIA-62BRL-CAD: 03n_reed * r46538 10/brlcad/trunk/src/libgcv/wfobj/re2c_utils.c: Using bu_vls_addr instead of accessing vls_str directly.
16:23.57abhi2011starseeker: all good now :)
17:22.12CIA-62BRL-CAD: 03erikgreenwald * r46539 10/brlcad/trunk/src/conv/stl/g-stl.c: add -8 (marching cubes) to usage
17:33.23brlcadstarseeker: so I have a clean checkout/configure going now and still seeing a slew of tests fail that should not be failing
17:34.52brlcaddlopen, getprogname (which might be "correct"), setprogname (also maybe "correct" with std99), strlcat, strlcpy, sizeof(socklen_t)
17:35.08*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
17:41.43*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:25.51*** join/#brlcad merzo (~merzo@98-229-132-95.pool.ukrtel.net)
19:05.58CIA-62BRL-CAD: 03brlcad * r46540 10/brlcad/trunk/CMakeLists.txt: distinguish compilation of 3rd party sources from our own build settings with different labels. Use 'Compile' instead of 'Build' since that helps disambiguate what the ON/OFF means (i.e., action not feature).
19:06.55*** join/#brlcad merzo (~merzo@98-229-132-95.pool.ukrtel.net)
20:32.51CIA-62BRL-CAD: 03abhi2011 * r46541 10/brlcad/trunk/src/libged/simulate/simulate.h: Added new header file to declare structures for passing sim parameters
20:33.42CIA-62BRL-CAD: 03abhi2011 * r46542 10/brlcad/trunk/src/libged/simulate/CMakeLists.txt: Added simulate.h new header to CMake
20:35.10CIA-62BRL-CAD: 03abhi2011 * r46543 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c): Changed simulate command logic to duplicate and pass regions to bullet
20:38.21CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3090 10/wiki/User:Abhijit: /* Log */
20:42.35CIA-62BRL-CAD: 03abhi2011 * r46544 10/brlcad/trunk/src/libged/simulate/simulate.h: Modified some comments to indicate the reason for simulate.h
21:00.12CIA-62BRL-CAD: 03bob1961 * r46545 10/brlcad/trunk/ (include/ged.h include/tclcad.h src/libtclcad/tclcad_obj.c): Moved and renamed a few mode related macros that are used only by libtclcad from ged.h to tclcad.h.
21:22.24starseekerbrlcad: out of curiosity, what does autotools configure say about those on the same machine?
21:23.41brlcaddon't know, blew away my autotools build
21:23.55starseekerah, k
21:24.03brlcaddon't want to mix the two for a few days just to make sure everything I'm seeing is "pure cmake"
21:24.24brlcadstill trying to verify that nothing in main dir isn't getting modified
21:25.36brlcadso far looking good after a  full build
21:28.16starseekerif you really want to go whole hog on that, strip all the svn:ignore stuff we've got
21:28.24starseekerdid that in the cmake branch
21:28.40starseekerwas planning to do it in trunk once we no longer support autotools
22:32.44CIA-62BRL-CAD: 03n_reed * r46546 10/brlcad/trunk/src/conv/obj-g_new.c: Distance tolerance changed from .0005 to .005.
22:33.29*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
22:46.07CIA-62BRL-CAD: 03starseeker * r46547 10/brlcad/trunk/ (CMakeLists.txt include/CMakeLists.txt): Improve handling of newlines for system conf files
22:49.51CIA-62BRL-CAD: 03starseeker * r46548 10/brlcad/trunk/CMakeLists.txt: use all the CPUs we can - go with 20 as a good number given current systems (2011)
23:16.04*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
23:35.32*** join/#brlcad n_reed (44378e88@gateway/web/freenode/ip.68.55.142.136)
23:51.02*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20110902

IRC log for #brlcad on 20110902

00:11.38CIA-62BRL-CAD: 03starseeker * r46549 10/brlcad/trunk/src/libdm/CMakeLists.txt: Apparently we don't need the termlib include dir in libdm after all.
00:49.03*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
02:43.11CIA-62BRL-CAD: 03starseeker * r46550 10/brlcad/trunk/ (5 files in 5 dirs):
02:43.11CIA-62BRL-CAD: Do for other files what we do for .dist - fatal error if we're trying to ignore
02:43.11CIA-62BRL-CAD: something that doesn't exist, unless it's a generated file (which will specify
02:43.11CIA-62BRL-CAD: itself in a src list with a full path, and thus can be recognized.) Actually
02:43.11CIA-62BRL-CAD: caught a number of bugs in the CMake logic, which are also fixed in this commit.
08:18.16*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
08:50.36plaesuhh.. r46548 -- passing 20 compile jobs for build is a bit too much
09:51.59``Erikplaes: yeah... I'd argue it should be single threaded unless otherwise requested... I'll alter that once I get into the office, mebbe about an hour from now... and roll up a newspaper to swat starseeker some :D
09:57.42plaes;)
09:58.21plaes\o/
10:55.42CIA-62BRL-CAD: 03erikgreenwald * r46551 10/brlcad/trunk/CMakeLists.txt: Remove -j20. Parallel builds should be at the builders explicit request to avoid accidentally hammering the machine.
11:16.03*** join/#brlcad merzo (~merzo@193.254.217.44)
11:19.33*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:24.26brlcadmeh, that was specifically for distcheck builds which only affects devs -- make is running the build so the dev user doesn't have an immediate means to specify parallel
12:25.02brlcadit should sense the number of cpus and use that by default
12:32.32``Erikcmake doesn't carry MAKE_FLAGS for you?
12:35.23brlcadnot that I'm aware of
12:35.26brlcadmaybe something like that could be added
12:36.32brlcadmaybe a poor-mans version like: http://www.cmake.org/pipermail/cmake/2010-October/040122.html
12:50.30*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:51.54``ErikI'm not keen on the automatically parallel thing, *shrug* if I set up a cron to do a distcheck on, say, bz, any parallel would cause a bit of service degredation. mebbe set NPROCS=1 and do "make NPROC=`sysctl -n hw.ncpu` distcheck" or something?
12:53.19``Erik('cept with the var names matching and all that)
12:55.02``Erikhm, survice is putting on another BRL-CAD training course on sept 19, this time in eglin (ft walton beach, florida) O.o
12:59.22CIA-62BRL-CAD: 03d_rossberg * r46552 10/brlcad/trunk/CMakeLists.txt:
12:59.22CIA-62BRL-CAD: WIN32 is an add_executable() flag => sort it out from the source file names too
12:59.22CIA-62BRL-CAD: because it's a CMake variable it has to be prefixed by a "x" e.g.
13:01.00brlcad``Erik: mebbe, it just needs *some* way to go parallel or nobody will perform a distcheck very often -- it'll take way too long
13:01.42brlcadbetter to be useful and dangerous than relatively useless and safe
13:03.11``Erik*shrug* or mebbe go parallel by default and have some way to force it to be low(ered) impact?
13:03.28brlcadif it can come from the initial command-line, even better, then it's both safe and useful but the goal should definitely be towards getting everyone running distcheck more frequently
13:04.09``ErikI'm thinking more towards having it run automatically, continuous integration style :)
13:04.43brlcadwe should *also* be doing that :)
13:05.24brlcadshouldn't be a crutch, imho though
13:05.58brlcadi should be able to invoke a distcheck on-demand without hesitation and get a result within 2x-3x of a regular build time
13:06.14brlcadif it's any longer or has more steps, most won't do it
13:06.51``Erikregular build is single threaded, though... I do "nice make -j17 build install" on the 16 core machines
13:07.17``ErikI wouldn't mind having to type "nice make -j17 distcheck", if that'd work on the subdir build
13:07.19brlcadI can't even do the on-demand part right now because there are extra steps (got to have a pristine checkout), but we talked about that one last night and it should be doable to get it going on any checkout
13:07.46brlcadyeah, that'd make sense except how the make distcheck rule is implemented
13:07.53brlcadmake -jXX distcheck won't work
13:08.11``Erikyeah, back to the MAKE_FLAGS ... :D
13:08.30brlcadjust calls a distcheck rule that reinvokes a cmake build rule -- so you can distcheck from msvc or xcode, etc
13:09.02brlcadthe cmake build rule knows nothing of the make -j flag that might have been set (though there might be some way to capture that)
13:09.30brlcadfinds this disturbing, and highly suspect: https://sourceforge.net/tracker/?func=detail&atid=640803&aid=3402908&group_id=105292
13:10.56``Eriksaw that, dunno what 'comodo' is, where the exe came from, if it's a false positive, mebbe a marketing move by that comodo company, ... :/
13:12.09``Erikcomodo seems to be a chinese company that sells services which involve them having remote admin access to your winderz boxen
13:15.28``Erikhttp://en.wikipedia.org/wiki/Comodo_Group  hm
13:16.32``Erikanim_cascade.exe is the only one marked
13:19.33CIA-62BRL-CAD: 03d_rossberg * r46553 10/brlcad/trunk/include/CMakeLists.txt:
13:19.33CIA-62BRL-CAD: there is no brlcad_config.h.in in the repository
13:19.33CIA-62BRL-CAD: it appears to be CMake generated and lives in the CMake binaries' directory
13:35.06brlcadyeah, I saw the pic -- incredibly unlikely but possible
13:35.35brlcadwho made the 7.20.0 binary?
14:37.49*** join/#brlcad n_reed (~nreed1@c-68-55-142-136.hsd1.md.comcast.net)
14:43.35brlcadn_reed: 0.0005 is what it's "supposed" to be .. there are just a LOT of places that value is inconsistent
14:44.24brlcadso you had it right ;)
14:44.50n_reedbrlcad: I'll change it back then.
14:45.39n_reedbrlcad: Richard told me yesterday that it was supposed to be .005.
14:46.27n_reedbrlcad: That is the tolerance that prints if you open a db model and type tol in mged.
14:51.37brlcadyeah, that's part of the inconsistency
14:52.45brlcadchanging tolerance values requires a fair bit of retesting to make sure it's backwards-compatible
15:34.29*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
15:39.18CIA-62BRL-CAD: 03n_reed * r46554 10/brlcad/trunk/src/conv/obj-g_new.c: Reverted to previous revision. .0005mm is the correct distance tolerance.
15:41.06brlcadabhi2011: a matter of nomenclature -- the word "region" has a very specific meaning within BRL-CAD
15:41.45brlcada region is a database combination with a flag set that indicates the combination occupies physical space
15:42.43brlcadall regions are combinations, but not all combinations are regions .. and no primitive is a region
15:43.08brlcad"groups" (aka assemblies) is a combination that contains one or more regions
15:45.12abhi2011brlcad: ok
15:46.18brlcadsimulate is pretty much agnostic to all of that, just working with "geometry objects"
15:46.35brlcadwhich can be regions, groups, combs, prims, etc :)
15:57.31CIA-62BRL-CAD: 03brlcad * r46555 10/brlcad/trunk/src/tclscripts/mged/ (pattern.tcl tclIndex): use the new 'exists' command instead of rolling our own
16:21.32CIA-62BRL-CAD: 03brlcad * r46556 10/brlcad/trunk/src/tclscripts/ (6 files in 2 dirs): more cases where the new 'exists' command can be put to use. use exists instead of db get or db get_type to test whether a database object already exists.
16:54.27CIA-62BRL-CAD: 03starseeker * r46557 10/brlcad/trunk/CMakeLists.txt: Get a bit fancier with the package name and version for RPMs - commented out by default, but available if desired.
16:59.31brlcadconforming to HACKING or different?  we need to be consistent for all our releases (for a whole variety of reasons)
16:59.57brlcadotherwise, it's basically "wrong" and should be fixed
17:02.28brlcadthe format as-is "should" fit most any distribution system I'm aware of including support for optional notes and annotations
17:09.47CIA-62BRL-CAD: 03abhi2011 * r46558 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): Modified simulate to look through all regions in the current DB and add them as rigid bodies to the sim, objects now fallto the ground correctly
17:31.13*** join/#brlcad n_reed (~nreed1@c-68-55-142-136.hsd1.md.comcast.net)
19:00.17CIA-62BRL-CAD: 03erikgreenwald * r46559 10/brlcad/trunk/src/libgcv/bottess.c: simplify some bit mangling
19:23.47CIA-62BRL-CAD: 03starseeker * r46560 10/brlcad/trunk/doc/docbook/system/mann/en/ (CMakeLists.txt exists.xml): Add preliminary man page for new version of the exists command.
19:24.18starseekerbrlcad: figured I'd let you have a go at that before I start getting TOO deep into the C code
19:31.43CIA-62BRL-CAD: 03starseeker * r46561 10/brlcad/trunk/doc/docbook/system/mann/en/exists.xml: whoops, extra char - stay consistent, 3 letters for those options
19:37.40*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:58.24CIA-62BRL-CAD: 03starseeker * r46562 10/brlcad/trunk/src/libged/exists.c: Start roughing out the test.c->exists.c translation. Not doing any major rewiring yet until we've got the options more solidly pinned down, but it's a start.
20:04.08abhi2011here is the obligatory bricks toppling over video : http://www.youtube.com/watch?v=TIgm0tNYseM
20:04.21abhi2011made entirely with mged and rt
20:06.48starseekercool!
20:07.03starseekerhow come the block at the right on the end doesn't end up flat? (just curious)
20:07.20starseekerdoesn't look like things quite go to equilibrium...
20:11.30abhi2011yes there is some penetration of the ground plane , probably due to a error with positioning it or the default collision detection not working as expected :P
20:11.56``Erikbullet ftw, awesome stuff
20:13.11abhi2011so whats the easiest way to convert the image sequence output by rt into a mpeg movie in linux
20:14.09abhi2011tried imagemagick, but its requires ffmpeg delegates or something similar
20:14.15``ErikI used ffmpeg a while back
20:14.22``ErikI hear the linux mplayer does well, too
20:17.18``Erikmaking a driving game? O.o
20:19.12abhi2011hehe yeah was trying to integrate bullet raycast vehicle into a moon buggy kinda thing
20:19.36abhi2011was quite smooth with a basic engine model
20:41.27*** join/#brlcad b0ef (~b0ef@166.195.251.212.customer.cdi.no)
21:49.15*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
22:02.28``Erikhuzzah, truck is fixed
22:02.44starseekerawesome
22:04.37``Erikidjit who rotated the tires didn't do a very good job of tightening the lug nuts, that was all
22:15.07*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096600997.dsl.bell.ca)
22:32.45*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
23:07.07brlcadabhi2011: hah, that's f'n awesome :)
23:07.24brlcadstarseeker: will do (reviewing the exists usage)
23:08.42brlcadabhi2011: so I see the view keeps changing on you as the simulation progresses -- that's due to something getting redrawn
23:09.07brlcadfor animation purposes, you can either set up a view script and just keep re-rendering that script for each frame
23:09.43brlcador you can capture the view size before and restore it after the command is updated (or don't erase and redraw, just redraw)
23:10.40brlcadabhi2011: I'd love to showcase that to the website if you can pull together a better video
23:10.54brlcadsuggest a 2x zoom
23:11.29brlcadand maybe a different starting configuration if only to avoid the block that penetrates the surface
23:48.01``Erik<PROTECTED>
23:48.18``ErikI think the ogl demos that come with bullet do it that way :/ not sure
IRC log for #brlcad on 20110903

IRC log for #brlcad on 20110903

01:44.48brlcadyeah, the two should be decoupled, but even at a low framerate, that penetration shouldn't happen -- implies something is amiss
01:44.55brlcadstill, that is fantastic
01:45.17brlcadhaven't seen a proper brl-cad animation since the old joint days, probably 8 years ago
03:59.59*** part/#brlcad n_reed (~nreed1@c-68-55-142-136.hsd1.md.comcast.net)
04:28.20*** join/#brlcad kunigami (~kunigami@201.53.206.27)
05:42.02abhi2011Thanks everyone :)
05:42.45abhi2011brlcad: Yes the view seems to change to accomodate all objects with the 1024 by 1024 image size
05:43.03abhi2011I ll play around with the rtcheck parameters to see whats up
05:43.49abhi2011I mean rt
05:45.12abhi2011Yeah I think the penetration will no happen if I specify a plane as the ground plane
05:46.15abhi2011currently I make a box shape with the same parameters as a arb8 shape in mged (the command looks for a gp.s arb8 shape and uses its bb for the ground plane)
05:46.39abhi2011but yeah that cant be an excuse, penetration shouldnt happen either way
09:12.51*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
09:52.50*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
12:27.38*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:56.30*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:58.13brlcadabhi2011: the "what's up" is that a view isn't specified, so it just autosizes the view based on what is being drawn
12:58.50brlcadthe view merely needs to be specified (if you run "saveview" within mged, you'll get a view script that you could re-use to render each frame consistently)
12:59.02abhi2011oh ok, I ll try that
12:59.23abhi2011I have 1 more question
12:59.30abhi2011so I have been trying to draw a stack of cubes
12:59.34abhi2011upon each other
12:59.36abhi2011in mged
12:59.44abhi2011so I run a tcl loop
12:59.54brlcadI suspect the penetration is because you're using AABBs
13:00.25brlcadyou're passing the aabb's to bullet as simple cubes .. bullet applies rotations to them which causes them to tumble
13:00.38brlcadyou correctly apply the tumble transformation to them
13:01.15brlcadbut don't feed bullet new aabbs (as they get bigger when the arb8 tumbles), so it's allowed to get too close to the surface
13:02.22brlcadI suspect if you changed the arb8s to all spheres, it wouldn't penetrate (but then the spheres would bounce off each other before they actually touch)
13:02.36brlcadat least until you get the custom collision handler implemented
13:02.37abhi2011yes, but bullet maintains it own aabbs too
13:02.55abhi2011thats how it eliminates a large number of objects in broadphase collison detection
13:02.55brlcadso sounds like three things todo
13:03.54brlcad1) you need some means to update the bb to bullet each timestep if that's not happening already, not just reusing the original bb
13:05.13brlcad2) you'll need to register a custom collision detection callback for bullet to call, this will be a callback you write that shoots a simple small grid of rays
13:05.33brlcad3) render with a view set ;)
13:13.24abhi2011ok
13:13.48abhi2011yes, actually I dont set the aabb at all in bullet
13:14.08abhi2011I just make a box with the same  dimensions as the aabb
13:14.29abhi2011I suspect bullet updates the aabb, but maybe not
13:15.11abhi2011so I was thinking about the sphere dropping on a plane scenario
13:15.35abhi2011what I would do now is create a cube aligned to the aabb of the sphere
13:15.39abhi2011and start the sim
13:16.08abhi2011when the cube touches the ground plane, then bullet would generate a bunch of contact points all along the bottom face of the aabb
13:16.27abhi2011however at this point I am arranging for a callback to my code
13:17.42abhi2011in this callback function, I ll use rtcheck or something similar to check the regions which overlap, which in this case would be a sphere region and a ground plane region
13:18.25abhi2011and I ll modify the contact point list to the 1 single point at the bottom of the sphere which actually makes contact from the region perspective
13:19.10abhi2011consequently the sphere region aabb may roll over as its contact points have been modified
13:19.32abhi2011note I am not talking about geometry here at all as discussed before
13:20.34abhi2011I am dealing simply with regions and their aabbs :)
13:21.14abhi2011all this is based on the fact that a tool does exist in brl-cad which can give me a list of contact points when 2 regions overlap in 3d space
13:37.40brlcadso a tool exists, but I think you'll find it even easier to shoot the rays yourself (where you can easily control the resolution)
13:38.12abhi2011ok
13:39.18brlcadas for the aabbs, that was my point -- you pass the aabb (which you feed to bullet as a box), bullet treats it as a box and begins to tumble and apply rotations
13:39.57brlcadonce you apply that rotation which came back from bullet, the bb needs to be recalculated and set AGAIN in bullet
13:40.22brlcadif you do that, then there will be no object bounding box penetration
13:40.50brlcadthen you can write the collision detection callback that will more accurately report the contact points when bb's overlap
13:41.44abhi2011ok yeah I can do that for sure, it would require calculating the aabb every simulation tick but that should be ok
13:42.01brlcadyeah, should be instantaneous until the objects get into the thousands
13:42.39brlcadthe collision detection callback is going to be what slows things down a little
13:43.18brlcadbut what I suggest is starting with the bare minimum, shooting two 3x3 grids of rays
13:44.22abhi2011ok, but 3 by 3 grid means, if the rays are far apart then they may miss many cubes
13:44.25brlcader, 3x3x3 grid of rays, a 3x3 for each axis, giving you 27 rays
13:44.35abhi2011ok
13:44.51brlcadthat's just a starting point to make sure things are working
13:44.55abhi2011ok
13:45.47brlcadthat number can EASILY be increased for better detection, but it will slow things down at a cubic rate
13:46.02abhi2011yes true
13:46.21abhi2011no point in resetting the contatc manifold multiple times in the same frame
13:48.06abhi2011though different rays would pass through the overlap region in different places, so new points would be generated by every ray within the overlap region
13:50.11brlcadyes, and the points generated would be precise including the contact point and hit point normal
14:42.53abhi2011by the way I came across a strange issue while moving objects into position in mged
14:43.07abhi2011so I generally use rt_matrix_transform()
14:43.43abhi2011seems if i directly pass it a matrix in the opengl format (after transposing it as brlcad is row major while opengl is column major)
14:43.56abhi2011then the rotations are applied first and then the translation
14:44.10abhi2011so the object ends up in a wierd place
14:44.44abhi2011currently i translate to the origin , do the rotation  and then translate again wrt orgin to get to the final position
17:22.31*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
17:26.43*** join/#brlcad abhi2011_ (~chatzilla@x033197.its-s.tudelft.nl)
17:30.23*** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl)
18:19.57*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:14.18*** join/#brlcad merzo (~merzo@170-171-133-95.pool.ukrtel.net)
19:33.52*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:56.07CIA-62BRL-CAD: 03jordisayol * r46563 10/brlcad/trunk/misc/debian/control: Change building dependencies from make to cmake for debian sources
21:04.40*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
IRC log for #brlcad on 20110904

IRC log for #brlcad on 20110904

00:48.39*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
01:34.29*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:01.29CIA-62BRL-CAD: 03jordisayol * r46564 10/brlcad/trunk/ (4 files in 2 dirs):
02:01.29CIA-62BRL-CAD: Correct wrong building dependencies.
02:01.29CIA-62BRL-CAD: Force cmake to compile all 3rd party sources in brlcad.
08:59.33*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
09:17.18*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:39.27abhi2011yeah i found why the blocks are penetrating the plane
12:39.34abhi2011the positioning is wrong
12:39.48abhi2011I was checking the rotation matrices
12:40.15abhi2011for a block lying on the ground plane there should not be any rotation about the z axis
12:40.30abhi2011and bullet returns it as that
12:40.43abhi2011however i am not properly transferring that rotation to mged
12:41.15abhi2011*correction : there should not be any rotation about the y axis
14:26.42CIA-62BRL-CAD: 03173.208.51.136 07http://www.solidgeometry.org * r3092 10/wiki/Lmfao_bookmarking_that_33: New page: [[Image:social_bookmarking_service_2557.jpg|thumb|]] Delightful is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that allows consumers to share links on ...
14:37.39abhi2011fixed, no interpenetration now, now for the movie
14:44.56*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
15:04.58plaesum.. spam ^^ ?
15:30.53CIA-62BRL-CAD: 03abhi2011 * r46565 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): Updated the positioning code to transfer positions and orientations correctly from bullet to mged
16:33.15*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
16:35.15abhi2011updated video : http://www.youtube.com/watch?v=SByoQQStH2s
16:35.27abhi2011still not quite the way I would like to render it
16:35.34abhi2011I made a view script and rendered this time
16:35.44abhi2011however I want a 1024 by 768 render
16:35.58abhi2011i get only 512 by 512
16:41.13CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3093 10/wiki/User:Abhijit: /* Log */
17:29.34starseeker<PROTECTED>
17:29.38starseekerwhoops
17:31.13starseekerhah, that rocks
17:31.40starseekervideo is a tad long - looks like an extra 10-15 sec after all the blocks stop moving?
17:33.06starseekerabhi2011: if you do that in mged, do the wireframes update and display interactively?
17:33.27starseeker(say, if you wanted to do a quick check of the behavior before you kicked off all the raytracing?)
17:37.11starseekercan't wait to see a raytracer based interaction :-)
17:49.00abhi2011starseeker: does not yet update interactively even if I run the simulate command in a loop or thru' a proc, that will require some changes to the way commands are run now currently
17:50.08abhi2011yeah, I ran for 600 steps when all the action gets over after 300, also made that movie in windows movie maker and didnt set the delay small enough so it looks in slow motion :P
17:51.21abhi2011yes integrating the raytracer is the next steps, things ll get pretty interesting now :)
19:39.18*** join/#brlcad merzo (~merzo@156-124-133-95.pool.ukrtel.net)
19:54.00CIA-62BRL-CAD: 0369.147.248.153 07http://brlcad.org * r3094 10/wiki/I_don_t_have_service_appropriate_now_I_will_as_soon_as_I_get_home_3_56: New page: [[Image:social_bookmarking_service_2281.jpg|thumb|]] StumbleUpon is a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] to buyers to find out new websites based o...
19:56.37CIA-62BRL-CAD: 03173.234.123.184 07http://ist.brlcad.org * r3095 10/wiki/HQ_Service_0: New page: [[Image:social_bookmarking_service_975.jpg|thumb|]] Whilst checking your daily internet site metrics within Google Analytics, you might be delighted to secure that is someone has shared s...
20:50.56CIA-62BRL-CAD: 03starseeker * r46566 10/brlcad/trunk/CMakeLists.txt: Ah, right - using cfg in the path messes with the file placements we need to run in build dir.
21:25.15CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
21:25.15CIA-62BRL-CAD: deleted "[[Lmfao bookmarking that 33]]": content was:
21:25.15CIA-62BRL-CAD: '[[Image:social_bookmarking_service_2557.jpg|thumb|]]Delightful is some
21:25.15CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service]
21:25.15CIA-62BRL-CAD: th...' (and the only contributor was
21:25.16CIA-62BRL-CAD: '[[Special:Contributions/173.208.51.136|173.208.51.136]]')
21:25.25CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.51.136]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
21:26.27CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[I don t have service appropriate now I will as soon as I get home 3 56]]": spam
21:26.40CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:69.147.248.153]] with an expiry time of infinite (anonymous users only, account creation disabled)
21:27.14CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[HQ Service 0]]": spam
21:27.27CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.123.184]] with an expiry time of infinite (anonymous users only, account creation disabled)
21:29.58CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:Cadev]]": spam?
23:39.08CIA-62BRL-CAD: 03173.208.24.246 07http://www.solidgeometry.org * r3096 10/wiki/Sunday_morning_televised_service_at_the_crystal_cathedral_Channel_40_25: New page: [[Image:social_bookmarking_service_4995.jpg|thumb|]] Web 2.0 describes the shift toward cooperative, shared, multimedia experiences on the Web. Particular sites, these kinds of whereas th...
23:49.47CIA-62BRL-CAD: 03173.234.187.29 07http://ist.brlcad.org * r3097 10/wiki/Not_long_after_support_had_to_stay_choir_practice_lol_39: New page: [[Image:social_bookmarking_service_3018.jpg|thumb|]] StumbleUpon remains a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] to users to uncover new internet site...
23:51.14CIA-62BRL-CAD: 03173.234.11.159 07http://brlcad.org * r3098 10/wiki/Que_puto_empinado_social_53: New page: [[Image:social_bookmarking_service_3786.jpg|thumb|]] StumbleUpon remains some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that allows you browse by way of r...
IRC log for #brlcad on 20110905

IRC log for #brlcad on 20110905

00:14.21CIA-62BRL-CAD: 0364.120.86.29 07http://ist.brlcad.org * r3099 10/wiki/Hunderte_gratis_Besucher_mit_Social_Bookmarking_26: New page: [[Image:social_bookmarking_service_1862.jpg|thumb|]] Toothsome yous any [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that permits owners to share links on th...
00:25.28CIA-62BRL-CAD: 03173.208.25.215 07http://brlcad.org * r3100 10/wiki/Service_was_lovely_71: New page: [[Image:social_bookmarking_service_5574.jpg|thumb|]] StumbleUpon is a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] with users to find new websites based on t...
00:30.48CIA-62BRL-CAD: 03173.234.94.105 07http://bz.brlcad.org * r3101 10/wiki/Shitty_service_at_friendlys_on_57_79: New page: [[Image:social_bookmarking_service_2992.jpg|thumb|]] Whilst checking your daily website metrics within Google Analytics, you might be delighted to find that is someone has shared a link t...
00:31.18CIA-62BRL-CAD: 03173.234.175.26 07http://www.solidgeometry.org * r3102 10/wiki/Okay_now_I_m_just_annoyed_Can_Social_Distortion_consider_the_stage_now_75: New page: [[Image:social_bookmarking_service_3643.jpg|thumb|]] StumbleUpon may be an essential device to increase your amount about visitors. StumbleUpon is a [http://lease-a-seo.com/social-bookma...
00:51.26*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
00:58.30CIA-62BRL-CAD: 03173.234.143.96 07http://brlcad.org * r3103 10/wiki/The_Bayou_Bonfouca_Bridge_on_LA_433_is_back_in_service_St_Tammany_87: New page: [[Image:social_bookmarking_service_5054.jpg|thumb|]] Delicious is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that is allows buyers to share links on t...
01:03.25CIA-62BRL-CAD: 03173.234.94.105 07http://bz.brlcad.org * r3104 10/wiki/I_am_not_anti_public_I_just_Do_Not_like_you_20: New page: [[Image:social_bookmarking_service_2366.jpg|thumb|]] StumbleUpon is any [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] to users to learn new websites based on ...
01:13.07CIA-62BRL-CAD: 03173.234.143.96 07http://ist.brlcad.org * r3105 10/wiki/Baby_Social_Worker_Doctor_is_my_favourite_Doctor_24: New page: [[Image:social_bookmarking_service_5000.jpg|thumb|]] Whilst checking your everyday web site metrics in Google Analytics, you might be thrilled to find that is someone has shared a link to...
01:17.55CIA-62BRL-CAD: 0364.120.117.41 07http://ist.brlcad.org * r3106 10/wiki/Lol_mi_no_put_on_me_service_yet_eno_beb_Oh_lol_when_74: New page: [[Image:social_bookmarking_service_1881.jpg|thumb|]] Tasty is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that allows consumers to share links on the w...
01:42.30CIA-62BRL-CAD: 03173.234.187.29 07http://bz.brlcad.org * r3107 10/wiki/Ppc_services_social_bookmarking_website_promotion_14: New page: [[Image:social_bookmarking_service_1744.jpg|thumb|]] Web 2.0 tools can link your students along with resources around the world. Web 2.0 explains the progress toward collaborative, share...
01:57.46CIA-62BRL-CAD: 03173.234.176.193 07http://ist.brlcad.org * r3108 10/wiki/In_two_weeks_yeah_haha_get_off_twitter_this_is_my_social_network_30: New page: [[Image:social_bookmarking_service_5335.jpg|thumb|]] Whilst checking your regular website metrics in Google Analytics, you might be delighted to find that someone has shared some link to ...
02:03.10CIA-62BRL-CAD: 03173.234.93.135 07http://brlcad.org * r3109 10/wiki/La_vida_social_no_me_dejo_escribir_mucho_estas_ultimas_horas_87: New page: [[Image:social_bookmarking_service_1607.jpg|thumb|]] Web 2.0 gear can link your students by resources around the community. Web 2.0 explains the progress toward collaborative, shared, mu...
02:04.54CIA-62BRL-CAD: 0364.120.38.9 07http://bz.brlcad.org * r3110 10/wiki/Amr_ta_On_em_alguma_rede_social_67: New page: [[Image:social_bookmarking_service_4116.jpg|thumb|]] While checking your every day internet site metrics from Google Analytics, you might be delighted to find that somebody has shared any...
02:05.06CIA-62BRL-CAD: 03173.234.245.28 07http://www.solidgeometry.org * r3111 10/wiki/At_your_service_sir_87: New page: [[Image:social_bookmarking_service_4617.jpg|thumb|]] While checking your regular website metrics with Google Analytics, you might be delighted to discover that someone has shared a link t...
02:33.55CIA-62BRL-CAD: 0364.120.38.9 07http://bz.brlcad.org * r3112 10/wiki/I_dont_have_no_service_26: New page: [[Image:social_bookmarking_service_4706.jpg|thumb|]] Label the website in keywords to assist other owners identify hers content. Trouble: Tolerably Easy Directions 1 Warning up for a [...
02:34.37CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.24.246]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:35.40CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:35.40CIA-62BRL-CAD: deleted "[[Sunday morning televised service at the crystal cathedral Channel 40
02:35.40CIA-62BRL-CAD: 25]]": content was: '[[Image:social_bookmarking_service_4995.jpg|thumb|]]Web 2.0
02:35.40CIA-62BRL-CAD: describes the shift toward cooperative, shared, multimedia experiences on the
02:35.40CIA-62BRL-CAD: Web. Parti...' (and the only contributor was
02:35.40CIA-62BRL-CAD: '[[Special:Contributions/173.208.24.246|173.208.24.246]]')
02:36.11CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.187.29]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:36.46CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:36.46CIA-62BRL-CAD: deleted "[[Not long after support had to stay choir practice lol 39]]": content
02:36.46CIA-62BRL-CAD: was: '[[Image:social_bookmarking_service_3018.jpg|thumb|]]StumbleUpon remains a
02:36.46CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service]...'
02:36.46CIA-62BRL-CAD: (and the only contributor was
02:36.47CIA-62BRL-CAD: '[[Special:Contributions/173.234.187.29|173.234.187.29]]')
02:37.12CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.11.159]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:37.22CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:37.22CIA-62BRL-CAD: deleted "[[Que puto empinado social 53]]": content was:
02:37.22CIA-62BRL-CAD: '[[Image:social_bookmarking_service_3786.jpg|thumb|]]StumbleUpon remains some
02:37.22CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking servi...' (and
02:37.23CIA-62BRL-CAD: the only contributor was
02:37.23CIA-62BRL-CAD: '[[Special:Contributions/173.234.11.159|173.234.11.159]]')
02:38.07CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:64.120.86.29]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:38.18CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:38.18CIA-62BRL-CAD: deleted "[[Hunderte gratis Besucher mit Social Bookmarking 26]]": content was:
02:38.18CIA-62BRL-CAD: '[[Image:social_bookmarking_service_1862.jpg|thumb|]]Toothsome yous any
02:38.18CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service]
02:38.19CIA-62BRL-CAD: th...' (and the only contributor was
02:38.19CIA-62BRL-CAD: '[[Special:Contributions/64.120.86.29|64.120.86.29]]')
02:38.39CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.25.215]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:38.54CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:38.54CIA-62BRL-CAD: deleted "[[Service was lovely 71]]": content was:
02:38.54CIA-62BRL-CAD: '[[Image:social_bookmarking_service_5574.jpg|thumb|]]StumbleUpon is a
02:38.54CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service]
02:38.54CIA-62BRL-CAD: with...' (and the only contributor was
02:38.55CIA-62BRL-CAD: '[[Special:Contributions/173.208.25.215|173.208.25.215]]')
02:39.04CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.94.105]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:39.16CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:39.16CIA-62BRL-CAD: deleted "[[Shitty service at friendlys on 57 79]]": content was:
02:39.16CIA-62BRL-CAD: '[[Image:social_bookmarking_service_2992.jpg|thumb|]]Whilst checking your daily
02:39.16CIA-62BRL-CAD: website metrics within Google Analytics, you might be delighted to fi...' (and
02:39.17CIA-62BRL-CAD: the only contributor was
02:39.17CIA-62BRL-CAD: '[[Special:Contributions/173.234.94.105|173.234.94.105]]')
02:40.02CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:40.02CIA-62BRL-CAD: deleted "[[Okay now I m just annoyed Can Social Distortion consider the stage
02:40.02CIA-62BRL-CAD: now 75]]": content was:
02:40.02CIA-62BRL-CAD: '[[Image:social_bookmarking_service_3643.jpg|thumb|]]StumbleUpon may be an
02:40.02CIA-62BRL-CAD: essential device to increase your amount about visitors.StumbleUpon is a...'
02:40.03CIA-62BRL-CAD: (and the only contributor was
02:40.04CIA-62BRL-CAD: '[[Special:Contributions/173.234.175.26|173.234.175.26]]')
02:40.22CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.143.96]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:40.44CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:40.44CIA-62BRL-CAD: deleted "[[The Bayou Bonfouca Bridge on LA 433 is back in service St Tammany
02:40.44CIA-62BRL-CAD: 87]]": content was:
02:40.44CIA-62BRL-CAD: '[[Image:social_bookmarking_service_5054.jpg|thumb|]]Delicious is some
02:40.44CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service]
02:40.45CIA-62BRL-CAD: tha...' (and the only contributor was
02:40.45CIA-62BRL-CAD: '[[Special:Contributions/173.234.143.96|173.234.143.96]]')
02:41.15CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:41.15CIA-62BRL-CAD: deleted "[[I am not anti public I just Do Not like you 20]]": content was:
02:41.15CIA-62BRL-CAD: '[[Image:social_bookmarking_service_2366.jpg|thumb|]]StumbleUpon is any
02:41.15CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service]
02:41.15CIA-62BRL-CAD: to...' (and the only contributor was
02:41.15CIA-62BRL-CAD: '[[Special:Contributions/173.234.94.105|173.234.94.105]]')
02:41.52CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:41.52CIA-62BRL-CAD: deleted "[[Baby Social Worker Doctor is my favourite Doctor 24]]": content was:
02:41.52CIA-62BRL-CAD: '[[Image:social_bookmarking_service_5000.jpg|thumb|]]Whilst checking your
02:41.52CIA-62BRL-CAD: everyday web site metrics in Google Analytics, you might be thrilled to fin...'
02:41.52CIA-62BRL-CAD: (and the only contributor was
02:41.52CIA-62BRL-CAD: '[[Special:Contributions/173.234.143.96|173.234.143.96]]')
02:42.04CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:64.120.117.41]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:42.25CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:42.26CIA-62BRL-CAD: deleted "[[Lol mi no put on me service yet eno beb Oh lol when 74]]": content
02:42.26CIA-62BRL-CAD: was: '[[Image:social_bookmarking_service_1881.jpg|thumb|]]Tasty is some
02:42.26CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that
02:42.26CIA-62BRL-CAD: al...' (and the only contributor was
02:42.26CIA-62BRL-CAD: '[[Special:Contributions/64.120.117.41|64.120.117.41]]')
02:42.39CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:42.39CIA-62BRL-CAD: deleted "[[Ppc services social bookmarking website promotion 14]]": content was:
02:42.39CIA-62BRL-CAD: '[[Image:social_bookmarking_service_1744.jpg|thumb|]]Web 2.0 tools can link your
02:42.39CIA-62BRL-CAD: students along with resources around the world.Web 2.0 explains th...' (and the
02:42.39CIA-62BRL-CAD: only contributor was '[[Special:Contributions/173.234.187.29|173.234.187.29]]')
02:42.55CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.176.193]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:43.08CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:43.08CIA-62BRL-CAD: deleted "[[In two weeks yeah haha get off twitter this is my social network
02:43.08CIA-62BRL-CAD: 30]]": content was: '[[Image:social_bookmarking_service_5335.jpg|thumb|]]Whilst
02:43.08CIA-62BRL-CAD: checking your regular website metrics in Google Analytics, you might be
02:43.09CIA-62BRL-CAD: delighted to find...' (and the only contributor was
02:43.09CIA-62BRL-CAD: '[[Special:Contributions/173.234.176.193|173.234.176.193]]')
02:43.41CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.93.135]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:43.52CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:43.53CIA-62BRL-CAD: deleted "[[La vida social no me dejo escribir mucho estas ultimas horas 87]]":
02:43.53CIA-62BRL-CAD: content was: '[[Image:social_bookmarking_service_1607.jpg|thumb|]]Web 2.0 gear
02:43.53CIA-62BRL-CAD: can link your students by resources around the community.Web 2.0 explains the
02:43.53CIA-62BRL-CAD: pro...' (and the only contributor was
02:43.53CIA-62BRL-CAD: '[[Special:Contributions/173.234.93.135|173.234.93.135]]')
02:44.05CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:64.120.38.9]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:44.21CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:44.21CIA-62BRL-CAD: deleted "[[Amr ta On em alguma rede social 67]]": content was:
02:44.21CIA-62BRL-CAD: '[[Image:social_bookmarking_service_4116.jpg|thumb|]]While checking your every
02:44.21CIA-62BRL-CAD: day internet site metrics from Google Analytics, you might be delighte...' (and
02:44.22CIA-62BRL-CAD: the only contributor was '[[Special:Contributions/64.120.38.9|64.120.38.9]]')
02:44.31CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:44.31CIA-62BRL-CAD: deleted "[[At your service sir 87]]": content was:
02:44.31CIA-62BRL-CAD: '[[Image:social_bookmarking_service_4617.jpg|thumb|]]While checking your regular
02:44.31CIA-62BRL-CAD: website metrics with Google Analytics, you might be delighted to dis...' (and
02:44.32CIA-62BRL-CAD: the only contributor was
02:44.32CIA-62BRL-CAD: '[[Special:Contributions/173.234.245.28|173.234.245.28]]')
02:44.41CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:44.41CIA-62BRL-CAD: deleted "[[I dont have no service 26]]": content was:
02:44.41CIA-62BRL-CAD: '[[Image:social_bookmarking_service_4706.jpg|thumb|]]Label the website in
02:44.41CIA-62BRL-CAD: keywords to assist other owners identify hers content.Trouble:Tolerably ...'
02:44.42CIA-62BRL-CAD: (and the only contributor was
02:44.42CIA-62BRL-CAD: '[[Special:Contributions/64.120.38.9|64.120.38.9]]')
02:46.28CIA-62BRL-CAD: 03173.208.56.140 07http://ist.brlcad.org * r3113 10/wiki/Wer_nutzt_Evernote_f%C3%BCr_bookmarking_3: New page: [[Image:social_bookmarking_service_2094.jpg|thumb|]] Web 2.0 tools can connect your students with assets around the planet. Trouble: Average Directions 1 Permit students to use Web 2.0...
02:50.59starseekerhopes he's doing the blocking right...
02:51.38CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.56.140]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:51.49CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
02:51.49CIA-62BRL-CAD: deleted "[[Wer nutzt Evernote f??r bookmarking 3]]": content was:
02:51.49CIA-62BRL-CAD: '[[Image:social_bookmarking_service_2094.jpg|thumb|]]Web 2.0 tools can connect
02:51.49CIA-62BRL-CAD: your students with assets around the planet.Trouble:AverageDirect...' (and the
02:51.49CIA-62BRL-CAD: only contributor was '[[Special:Contributions/173.208.56.140|173.208.56.140]]')
03:04.11CIA-62BRL-CAD: 03173.208.101.9 07http://brlcad.org * r3114 10/wiki/At_T_must_have_constructed_lines_all_over_my_house_because_I_now_have_service_3: New page: [[Image:social_bookmarking_service_2703.jpg|thumb|]] Web 2.0 tools can connect your scholars along with assets around the globe. Web 2.0 explains the proceed toward collaborative, shared...
03:05.04CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.101.9]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
03:05.15CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
03:05.15CIA-62BRL-CAD: deleted "[[At T must have constructed lines all over my house because I now have
03:05.15CIA-62BRL-CAD: service 3]]": content was:
03:05.15CIA-62BRL-CAD: '[[Image:social_bookmarking_service_2703.jpg|thumb|]]Web 2.0 tools can connect
03:05.16CIA-62BRL-CAD: your scholars along with assets around the globe.Web 2.0 explains th...' (and
03:05.16CIA-62BRL-CAD: the only contributor was
03:05.17CIA-62BRL-CAD: '[[Special:Contributions/173.208.101.9|173.208.101.9]]')
03:07.59starseekerbrlcad: is there some magic wand that needs to be waved to stop the crapstorm?
03:22.37CIA-62BRL-CAD: 03173.234.244.30 07http://www.solidgeometry.org * r3115 10/wiki/Yeah_with_the_invention_about_social_networking_that_s_an_easy_feat_Lol_73: New page: [[Image:social_bookmarking_service_3389.jpg|thumb|]] Label the website with keywords to help other consumers identify thems content. Directions 1 Warning increase with some [http://leas...
03:23.56CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.244.30]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
03:24.18CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
03:24.18CIA-62BRL-CAD: deleted "[[Yeah with the invention about social networking that s an easy feat
03:24.18CIA-62BRL-CAD: Lol 73]]": content was:
03:24.18CIA-62BRL-CAD: '[[Image:social_bookmarking_service_3389.jpg|thumb|]]Label the website with
03:24.18CIA-62BRL-CAD: keywords to help other consumers identify thems content.Directions1 W...' (and
03:24.18CIA-62BRL-CAD: the only contributor was
03:24.19CIA-62BRL-CAD: '[[Special:Contributions/173.234.244.30|173.234.244.30]]')
03:33.39CIA-62BRL-CAD: 03173.208.41.35 07http://ist.brlcad.org * r3116 10/wiki/Red_social_96: New page: [[Image:social_bookmarking_service_2017.jpg|thumb|]] While checking your regular website metrics with Google Analytics, you might be happy to reveal that someone has shared some link to y...
03:34.08CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.41.35]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
03:34.17CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
03:34.17CIA-62BRL-CAD: deleted "[[Red social 96]]": content was:
03:34.17CIA-62BRL-CAD: '[[Image:social_bookmarking_service_2017.jpg|thumb|]]While checking your regular
03:34.17CIA-62BRL-CAD: website metrics with Google Analytics, you might be happy to reveal ...' (and
03:34.18CIA-62BRL-CAD: the only contributor was
03:34.18CIA-62BRL-CAD: '[[Special:Contributions/173.208.41.35|173.208.41.35]]')
03:36.20CIA-62BRL-CAD: 03173.208.50.128 07http://brlcad.org * r3117 10/wiki/Vou_sair_aqui_e_ter_uma_vida_social_55: New page: [[Image:social_bookmarking_service_2071.jpg|thumb|]] Tasty is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that is permits users to share links on the w...
03:36.48CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.50.128]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
03:36.58CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
03:36.58CIA-62BRL-CAD: deleted "[[Vou sair aqui e ter uma vida social 55]]": content was:
03:36.58CIA-62BRL-CAD: '[[Image:social_bookmarking_service_2071.jpg|thumb|]]Tasty is some
03:36.58CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that
03:36.59CIA-62BRL-CAD: is...' (and the only contributor was
03:36.59CIA-62BRL-CAD: '[[Special:Contributions/173.208.50.128|173.208.50.128]]')
03:37.40starseekercan't figure out how the heck to disable automatic posting on the wiki...
03:50.50CIA-62BRL-CAD: 03173.208.40.36 07http://ist.brlcad.org * r3118 10/wiki/Esse_joguinho_The_Sims_Social_do_facebook_esta_me_irritando_j%C3%A1_D_16: New page: [[Image:social_bookmarking_service_4382.jpg|thumb|]] StumbleUpon yous a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that lets you scan by means of random we...
03:52.45CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.40.36]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
03:52.58CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
03:52.58CIA-62BRL-CAD: deleted "[[Esse joguinho The Sims Social do facebook esta me irritando j?? D
03:52.58CIA-62BRL-CAD: 16]]": content was:
03:52.58CIA-62BRL-CAD: '[[Image:social_bookmarking_service_4382.jpg|thumb|]]StumbleUpon yous a
03:52.59CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service]
03:52.59CIA-62BRL-CAD: th...' (and the only contributor was
03:53.00CIA-62BRL-CAD: '[[Special:Contributions/173.208.40.36|173.208.40.36]]')
03:53.31starseekerhmm, interesting article:  http://www.devtopics.com/programmer-productivity-the-tenfinity-factor/
03:54.56CIA-62BRL-CAD: 03173.234.245.28 07http://bz.brlcad.org * r3119 10/wiki/It_s_vintage_social_networking_bro_H_16: New page: [[Image:social_bookmarking_service_1825.jpg|thumb|]] Tag the website in keywords to support other buyers identify its content. The social bookmarking phenomenon started on 1996 together ...
03:55.26CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.245.28]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
03:55.46CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
03:55.46CIA-62BRL-CAD: deleted "[[It s vintage social networking bro H 16]]": content was:
03:55.46CIA-62BRL-CAD: '[[Image:social_bookmarking_service_1825.jpg|thumb|]]Tag the website in keywords
03:55.46CIA-62BRL-CAD: to support other buyers identify its content.The social bookmarkin...' (and the
03:55.46CIA-62BRL-CAD: only contributor was '[[Special:Contributions/173.234.245.28|173.234.245.28]]')
04:36.27abhi2011starseeker: nice article
04:45.33CIA-62BRL-CAD: 03173.234.177.115 07http://brlcad.org * r3120 10/wiki/J%C3%A1_voltei_faz_tempo_me_distra%C3%AD_com_o_The_Sims_Social_85: New page: [[Image:social_bookmarking_service_5120.jpg|thumb|]] StumbleUpon can be one essential tool to improve your number of visitors. StumbleUpon yous a [http://lease-a-seo.com/social-bookmarki...
04:58.11CIA-62BRL-CAD: 03173.234.127.10 07http://www.solidgeometry.org * r3121 10/wiki/To_resist_anything_yous_to_be_in_the_service_of_it_bashar_53: New page: [[Image:social_bookmarking_service_4981.jpg|thumb|]] Tasty yous any [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that is permits buyers to share links on the...
04:59.05CIA-62BRL-CAD: 03173.234.174.28 07http://www.solidgeometry.org * r3122 10/wiki/I_have_this_reputation_of_being_this_promiscuous_non_committing_man_29: New page: [[Image:reputation_management_1051.jpg|thumb|]] Purchaser confidence plays any crucial rule with the success of any B2C company. Difficulty: Moderately Challenging Directions 1 Connect...
05:03.10CIA-62BRL-CAD: 03173.234.158.36 07http://bz.brlcad.org * r3123 10/wiki/Have_I_become_anti_social_81: New page: [[Image:social_bookmarking_service_3704.jpg|thumb|]] Trouble: Moderately Easy Directions 1 Sign up with some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] s...
05:12.32CIA-62BRL-CAD: 03173.234.177.115 07http://ist.brlcad.org * r3124 10/wiki/Estou_mt_anti_social_D_20: New page: [[Image:social_bookmarking_service_676.jpg|thumb|]] Web 2.0 describes the proceed toward collaborative, shared, multimedia experiences on the Web. Specific sites, such because the wide op...
05:28.42CIA-62BRL-CAD: 03starseeker * r46567 10/brlcad/trunk/CMakeLists.txt:
05:28.42CIA-62BRL-CAD: Apparently a default VC 2010 Express install doesn't have all the
05:28.42CIA-62BRL-CAD: redistributable dlls CMake is looking for - do as CMake does, suppress the
05:28.42CIA-62BRL-CAD: (rather verbose) messages. This may need more investigation, not clear if a
05:28.42CIA-62BRL-CAD: valid NSIS installer can be made as-is.
05:35.08CIA-62BRL-CAD: 03173.234.120.97 07http://www.solidgeometry.org * r3125 10/wiki/Yeah_if_you_want_shitty_service_and_shitty_burgers_95: New page: [[Image:social_bookmarking_service_2822.jpg|thumb|]] StumbleUpon remains a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] with users to discover new web site b...
05:43.30CIA-62BRL-CAD: 03173.234.167.21 07http://ist.brlcad.org * r3126 10/wiki/I_m_only_social_at_concerts_84: New page: [[Image:social_bookmarking_service_2486.jpg|thumb|]] Web 2.0 tools can connect your students together with means around the world. Web 2.0 describes the move toward cooperative, shared, ...
06:10.33CIA-62BRL-CAD: 03173.234.126.69 07http://brlcad.org * r3127 10/wiki/U_sang_well_worship_service_81: New page: [[Image:social_bookmarking_service_3180.jpg|thumb|]] StumbleUpon is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that is lets you browse via random web ...
06:11.05starseekerwoo hoo - early testing suggests that the windows version of xsltproc will work!
06:31.39CIA-62BRL-CAD: 0364.120.39.21 07http://www.solidgeometry.org * r3128 10/wiki/Listening_music_to_and_watching_the_social_network_17: New page: [[Image:social_bookmarking_service_2049.jpg|thumb|]] StumbleUpon yous any [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that lets you browse via random websit...
06:32.00CIA-62BRL-CAD: 03173.208.100.10 07http://bz.brlcad.org * r3129 10/wiki/I_barely_have_service_in_here_64: New page: [[Image:social_bookmarking_service_5522.jpg|thumb|]] StumbleUpon is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] with owners to learn new internet site ...
06:39.31*** join/#brlcad merzo (~merzo@193.254.217.44)
06:41.55CIA-62BRL-CAD: 0364.120.39.21 07http://ist.brlcad.org * r3130 10/wiki/Yeah_with_the_invention_of_social_networking_that_s_an_easy_feat_Lol_10: New page: [[Image:social_bookmarking_service_1937.jpg|thumb|]] StumbleUpon is a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that is allows you browse by means of rand...
06:43.35starseekerhttp://bzflag.bz/~starseeker/archer_win32_native_built_docs.png
06:47.47CIA-62BRL-CAD: 03173.234.158.36 07http://bz.brlcad.org * r3131 10/wiki/No_shoes_no_shirt_and_I_still_get_service_87: New page: [[Image:social_bookmarking_service_3631.jpg|thumb|]] StumbleUpon is some [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] for users to uncover new internet site ...
07:06.18CIA-62BRL-CAD: 03173.234.177.115 07http://brlcad.org * r3132 10/wiki/Social_life_has_plummeted_sgoingon_2: New page: [[Image:social_bookmarking_service_4197.jpg|thumb|]] Web 2.0 tools may connect your students by resources around the globe. Web 2.0 explains the progress toward cooperative, shared, mult...
07:21.54CIA-62BRL-CAD: 03173.234.159.17 07http://ist.brlcad.org * r3133 10/wiki/Benefits_of_Using_an_Attorney_Answering_Service_40: New page: [[Image:social_bookmarking_service_3324.jpg|thumb|]] Web 2.0 gear may connect your students by resources all over the world. Web 2.0 describes the proceed toward collaborative, shared, m...
07:22.53CIA-62BRL-CAD: 03173.234.126.69 07http://brlcad.org * r3134 10/wiki/I_swear_my_parents_will_be_the_death_of_me_also_my_social_life_17: New page: [[Image:social_bookmarking_service_2312.jpg|thumb|]] Toothsome remains any [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that allows buyers to share links on ...
07:28.58CIA-62BRL-CAD: 03173.234.122.130 07http://www.solidgeometry.org * r3135 10/wiki/Went_to_a_church_service_today_21: New page: [[Image:social_bookmarking_service_3486.jpg|thumb|]] Difficulty: Reasonable 1 Authorize scholars to utilize Web 2.0 social networking gear like because Facebook, Twitter and YouTube to f...
07:55.54CIA-62BRL-CAD: 0364.120.116.42 07http://bz.brlcad.org * r3136 10/wiki/Who_would_have_thought_bookmarking_now_Thanks_76: New page: [[Image:social_bookmarking_service_1481.jpg|thumb|]] StumbleUpon is a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that is lets you scan by means of random i...
08:10.47CIA-62BRL-CAD: 03173.234.142.127 07http://bz.brlcad.org * r3137 10/wiki/Excellent_article_worth_bookmarking_2: New page: [[Image:social_bookmarking_service_2937.jpg|thumb|]] Difficulty: Moderate Directions 1 Allow scholars to make use of Web 2.0 social networking gear such as Facebook, Twitter plus YouTub...
08:24.34CIA-62BRL-CAD: 0364.120.116.42 07http://www.solidgeometry.org * r3138 10/wiki/Lol_ppl_alway_making_up_stupid_shit_for_social_networks_its_lame_af_1: New page: [[Image:social_bookmarking_service_2855.jpg|thumb|]] Whilst checking your everyday internet site metrics in Google Analytics, you might be delighted to find that someone has shared some l...
09:35.53CIA-62BRL-CAD: 03173.208.70.163 07http://brlcad.org * r3139 10/wiki/Gotta_love_when_your_friends_fahk_with_your_public_networks_39: New page: [[Image:social_bookmarking_service_1624.jpg|thumb|]] StumbleUpon is a [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] for users to find new websites based on th...
10:16.06plaesthere was spam added to bz.brlcad.org mainpage: http://bz.brlcad.org/w/index.php?title=Main_Page&oldid=3034
10:19.07plaeswell, this user: http://bz.brlcad.org/wiki/Special:Contributions/Martinpaul
11:23.06*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
11:42.22*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
12:15.45CIA-62BRL-CAD: 03173.234.174.28 07http://bz.brlcad.org * r3140 10/wiki/There_administration_picked_fans_to_spend_the_day_with_1Dx_98: New page: [[Image:reputation_management_2361.jpg|thumb|]] One estimated 57 percent regarding adults use seek out engines to find information on themeselves, according to a Pew Research Center revie...
12:33.35*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:51.27CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.177.115]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
14:52.32CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
14:52.33CIA-62BRL-CAD: deleted "[[J?? voltei faz tempo me distra?? com o The Sims Social 85]]": content
14:52.33CIA-62BRL-CAD: was: '[[Image:social_bookmarking_service_5120.jpg|thumb|]]StumbleUpon can be one
14:52.33CIA-62BRL-CAD: essential tool to improve your number of visitors.StumbleUpon yous a [h...' (and
14:52.33CIA-62BRL-CAD: the only contributor was
14:52.33CIA-62BRL-CAD: '[[Special:Contributions/173.234.177.115|173.234.177.115]]')
14:54.04CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.127.10]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
14:54.17CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.174.28]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
14:54.34CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
14:54.34CIA-62BRL-CAD: deleted "[[To resist anything yous to be in the service of it bashar 53]]":
14:54.34CIA-62BRL-CAD: content was: '[[Image:social_bookmarking_service_4981.jpg|thumb|]]Tasty yous any
14:54.34CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] that
14:54.35CIA-62BRL-CAD: i...' (and the only contributor was
14:54.35CIA-62BRL-CAD: '[[Special:Contributions/173.234.127.10|173.234.127.10]]')
14:54.42CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
14:54.42CIA-62BRL-CAD: deleted "[[I have this reputation of being this promiscuous non committing man
14:54.42CIA-62BRL-CAD: 29]]": content was: '[[Image:reputation_management_1051.jpg|thumb|]]Purchaser
14:54.42CIA-62BRL-CAD: confidence plays any crucial rule with the success of any B2C
14:54.43CIA-62BRL-CAD: company.Difficulty:Moderat...' (and the only contributor was
14:54.43CIA-62BRL-CAD: '[[Special:Contributions/173.234.174.28|173.234.174.28]]')
14:56.42brlcadplaes: thanks
14:57.08brlcadlooks like there's some new mediawiki attack vector working
14:57.52starseekerbrlcad: should I keep scrubbing?
14:59.53CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.158.36]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
15:00.33CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.167.21]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
15:01.09CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.120.97]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
15:01.38CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
15:01.38CIA-62BRL-CAD: deleted "[[I m only social at concerts 84]]": content was:
15:01.38CIA-62BRL-CAD: '[[Image:social_bookmarking_service_2486.jpg|thumb|]]Web 2.0 tools can connect
15:01.38CIA-62BRL-CAD: your students together with means around the world.Web 2.0 describes...' (and
15:01.39CIA-62BRL-CAD: the only contributor was
15:01.39CIA-62BRL-CAD: '[[Special:Contributions/173.234.167.21|173.234.167.21]]')
15:02.21CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
15:02.21CIA-62BRL-CAD: deleted "[[Yeah if you want shitty service and shitty burgers 95]]": content
15:02.21CIA-62BRL-CAD: was: '[[Image:social_bookmarking_service_2822.jpg|thumb|]]StumbleUpon remains a
15:02.21CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service]...'
15:02.21CIA-62BRL-CAD: (and the only contributor was
15:02.21CIA-62BRL-CAD: '[[Special:Contributions/173.234.120.97|173.234.120.97]]')
15:02.22CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
15:02.22CIA-62BRL-CAD: deleted "[[Estou mt anti social D 20]]": content was:
15:02.23CIA-62BRL-CAD: '[[Image:social_bookmarking_service_676.jpg|thumb|]]Web 2.0 describes the
15:02.23CIA-62BRL-CAD: proceed toward collaborative, shared, multimedia experiences on the Web. Sp...'
15:02.24CIA-62BRL-CAD: (and the only contributor was
15:02.24CIA-62BRL-CAD: '[[Special:Contributions/173.234.177.115|173.234.177.115]]')
15:02.44CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
15:02.45CIA-62BRL-CAD: deleted "[[Have I become anti social 81]]": content was:
15:02.45CIA-62BRL-CAD: '[[Image:social_bookmarking_service_3704.jpg|thumb|]]Trouble:Moderately
15:02.45CIA-62BRL-CAD: EasyDirections1 Sign up with some [http://lease-a-seo.com/social-bookmar...'
15:02.45CIA-62BRL-CAD: (and the only contributor was
15:02.45CIA-62BRL-CAD: '[[Special:Contributions/173.234.158.36|173.234.158.36]]')
15:04.13CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.126.69]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
15:04.27CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:64.120.39.21]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
15:04.34CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.100.10]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
15:04.46CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.159.17]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
15:04.49CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.122.130]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
15:05.02CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:64.120.116.42]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
15:05.46archiviststarseeker, front page has spam
15:05.59starseekerarchivist: working on it - I don't really know what I'm doing
15:06.20starseekeris not skilled in mediawiki, but crapflood was too severe, so I'm trying
15:06.36CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.142.127]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
15:06.51CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.70.163]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
15:08.02CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
15:08.02CIA-62BRL-CAD: deleted "[[U sang well worship service 81]]": content was:
15:08.02CIA-62BRL-CAD: '[[Image:social_bookmarking_service_3180.jpg|thumb|]]StumbleUpon is some
15:08.02CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] t...'
15:08.02CIA-62BRL-CAD: (and the only contributor was
15:08.03CIA-62BRL-CAD: '[[Special:Contributions/173.234.126.69|173.234.126.69]]')
15:08.05CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
15:08.05CIA-62BRL-CAD: deleted "[[Listening music to and watching the social network 17]]": content
15:08.05CIA-62BRL-CAD: was: '[[Image:social_bookmarking_service_2049.jpg|thumb|]]StumbleUpon yous any
15:08.05CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] ...'
15:08.06CIA-62BRL-CAD: (and the only contributor was
15:08.06CIA-62BRL-CAD: '[[Special:Contributions/64.120.39.21|64.120.39.21]]')
15:08.07CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
15:08.07CIA-62BRL-CAD: deleted "[[I barely have service in here 64]]": content was:
15:08.08CIA-62BRL-CAD: '[[Image:social_bookmarking_service_5522.jpg|thumb|]]StumbleUpon is some
15:08.23CIA-62BRL-CAD: [http://lease-a-seo.com/social-bookmarking.php social bookmarking service] f...'
15:08.23CIA-62BRL-CAD: (and the only contributor was
15:08.23CIA-62BRL-CAD: '[[Special:Contributions/173.234.158.36|173.234.158.36]]')
15:08.23CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
15:08.23CIA-62BRL-CAD: deleted "[[Social life has plummeted sgoingon 2]]": content was:
15:08.24CIA-62BRL-CAD: '[[Image:social_bookmarking_service_4197.jpg|thumb|]]Web 2.0 tools may connect
15:08.24CIA-62BRL-CAD: your students by resources around the globe.Web 2.0 explains the pro...' (and
15:08.25CIA-62BRL-CAD: the only contributor was
15:08.25CIA-62BRL-CAD: '[[Special:Contributions/173.234.177.115|173.234.177.115]]')
15:08.26CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
15:08.26CIA-62BRL-CAD: deleted "[[Benefits of Using an Attorney Answering Service 40]]": content was:
15:08.52CIA-62BRL-CAD: '[[Image:social_bookmarking_service_3324.jpg|thumb|]]Web 2.0 gear may connect
15:08.52CIA-62BRL-CAD: your students by resources all over the world.Web 2.0 describes the p...' (and
15:08.52CIA-62BRL-CAD: the only contributor was
15:08.52CIA-62BRL-CAD: '[[Special:Contributions/173.234.159.17|173.234.159.17]]')
15:08.53CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
15:08.53CIA-62BRL-CAD: deleted "[[I swear my parents will be the death of me also my social life 17]]":
15:08.54CIA-62BRL-CAD: content was: '[[Image:social_bookmarking_service_2312.jpg|thumb|]]Toothsome
15:08.54CIA-62BRL-CAD: remains any [http://lease-a-seo.com/social-bookmarking.php social bookmarking
15:08.55CIA-62BRL-CAD: service]...' (and the only contributor was
15:08.55CIA-62BRL-CAD: '[[Special:Contributions/173.234.126.69|173.234.126.69]]')
15:08.56CIA-62(12 lines omitted)
15:08.57CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete:
15:08.57CIA-62BRL-CAD: deleted "[[Excellent article worth bookmarking 2]]": content was:
15:08.58CIA-62BRL-CAD: '[[Image:social_bookmarking_service_2937.jpg|thumb|]]Difficulty:ModerateDirections1
15:08.58CIA-62BRL-CAD: Allow scholars to make use of Web 2.0 social networking gear...' (and the only
15:08.59CIA-62BRL-CAD: contributor was '[[Special:Contributions/173.234.142.127|173.234.142.127]]')
15:11.07CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r3141 10/wiki/Main_Page: Undo revision 3084 by [[Special:Contributions/Jimblack|Jimblack]] ([[User talk:Jimblack|Talk]]) - spamming
15:11.36CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Jimblack]] with an expiry time of infinite (account creation disabled): Spamming links to external sites
15:16.49brlcadstarseeker: looks like you're doing just fine to me ... :)
15:17.01brlcadblock the ip/user and delete the page is all there is to it
15:17.17starseekerthe interface I'm using absolutely sucks - need a "batch delete" UI
15:17.27brlcadI sometimes try to remember to clear out the "comment" when deleting the page so the spam doesn't get repeated
15:17.34starseekerah, sorry
15:17.39brlcadthere probably is a MW module for that
15:17.55brlcadsometimes I don't remember, no big deal either way
15:18.15starseekeron a more positive note, the windows xsltproc succeeds in building our docs
15:18.45brlcadnods, good to know
15:19.08starseekerI don't suppose there's a mediawiki module that will let us reject posts based on regex matching of links?  (sort of adblock for wikis?)
15:19.24brlcadprobably is, there are hundreds of mw modules
15:19.33brlcadmany many related to various blocking vectors
15:20.11brlcadi'm looking at fixing one issue now -- the problem is multiplied right now because multiple domain names are responding, going to fix that
15:21.08starseekerah, so that's what the http://bz.brlcad.org links were about
15:21.59starseekerhmm... http://www.mediawiki.org/wiki/Extension:SpamBlacklist
15:39.50brlcadthere, done
15:42.32starseekerbrlcad: awesome, thanks!
15:44.49brlcadthat's not going to stop the spam, though
15:45.06starseekerevery little bit helps
15:45.52starseekerdoesn't understand how they're getting by recaptcha
15:46.05brlcadwe're already using a blacklist iirc, but haven't updated the list in a long while
15:47.18brlcadthere's been news about spammers getting more clever
15:47.46starseekergrowl
15:47.51brlcadcoupling their software with other client software that pays people to answer prompts
15:48.25brlcadso the recaptcha is sent to some kid in india/china/wherever that gets paid something like 1cent per response
15:48.46starseekeryeesh
15:49.34brlcadon the upside, recaptcha's OCR processing is up 3000% :)
15:49.41starseekerhehe
15:49.55starseekeryeah, I guess there is that
15:50.52starseekersupposes if we're going to have to deal with spam, getting the world's public domain works OCR'ed for free is at least a little payback
15:53.22starseekerah, poop.  test is like search, uses globals.  here we go again...
15:58.04*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
16:24.44brlcadis excited, got ahold of more than 100+ real .step files and about 25+ iges files
16:25.12brlcadstarseeker: make the globals static
16:25.28starseekeris working on passing them around in a struct "properly"
16:25.33brlcadah, k
16:25.50starseekersmaller code than search, so doable "relatively quickly"
16:26.06starseekerfactering in my goober pointing skills, of course
16:26.37starseekerbrlcad: holy cow, that's a lot of .step data
16:30.44brlcadyeah
16:31.02brlcad2.2GB worth
16:31.31brlcad900MB of iges
16:34.41starseekerO.o - does step-g work on any of it?
16:34.52starseekeror iges-g for that matter?
16:35.09starseeker(we really need to get the iges convertor making new NURBS, not old...)
16:35.22brlcadhaven't tested
16:35.30brlcadspent most of yesterday downloading them all
16:35.36starseekerheh
17:03.28starseekerpokes CIA-62
17:14.27CIA-62BRL-CAD: 03starseeker * r46568 10/brlcad/trunk/src/libged/exists.c: will be bounding box routines and raytracing routines for volume eventually, so name accordingly.
17:18.12CIA-62BRL-CAD: 03starseeker * r46569 10/brlcad/trunk/src/libged/exists.c: not hooked up or tested beyond 'it builds', and will need the specific test functions for each case implemented, but get the basic expression handling code building for exists.
17:28.47*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:05.31CIA-62BRL-CAD: 03starseeker * r46570 10/brlcad/trunk/src/libged/exists.c: replace syntax calls with ged result string prints
19:13.44*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
19:13.57jordisayolhello
19:14.30jordisayolis there an schedule for the next brlcad release?
19:35.37*** join/#brlcad merzo (~merzo@91-87-132-95.pool.ukrtel.net)
21:03.51CIA-62BRL-CAD: 03starseeker * r46571 10/brlcad/trunk/src/libged/exists.c: Get exists using the new code, although the only thing implemented at the moment is the db_lookup based call.
21:10.28*** join/#brlcad merzo (~merzo@91-87-132-95.pool.ukrtel.net)
21:14.24CIA-62BRL-CAD: 03starseeker * r46572 10/brlcad/trunk/src/libged/exists.c: oops - managed to gut the and/or code by mistake. Start putting it back together, lot more to fix here probably.
22:11.20*** join/#brlcad kunigami (~kunigami@201.53.206.27)
IRC log for #brlcad on 20110906

IRC log for #brlcad on 20110906

01:35.19CIA-62BRL-CAD: 03173.234.131.70 07http://brlcad.org * r3142 10/wiki/R_U_still_long_Gold_I_hope_so_48: New page: [[Image:Gold_Bullion_Silver_Coins_4919.jpg|thumb|]] If you are a coin collector with Florida, you may well want to portion with most of your collection at certain point. Whether you are a...
01:54.56CIA-62BRL-CAD: 03173.208.19.167 07http://brlcad.org * r3143 10/wiki/SHAMROCKGOLD_64: New page: [[Image:Gold_Bullion_Silver_Coins_2957.jpg|thumb|]] Trouble: Moderately Easy Instructions 1 See what a gold bullion is. Gold bullion is any investment grade of gold that comes within s...
02:06.53CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.131.70]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:07.03CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.19.167]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
02:07.15CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[R U still long Gold I hope so 48]]"
02:07.24CIA-62BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[SHAMROCKGOLD 64]]"
02:35.32CIA-62BRL-CAD: 03starseeker * r46573 10/brlcad/trunk/src/libged/exists.c: be smarter about how we handle a case without an explicit operation.
03:11.06*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
03:28.41CIA-62BRL-CAD: 03starseeker * r46574 10/brlcad/trunk/src/libged/exists.c:
03:28.41CIA-62BRL-CAD: Need to handle no-explicit-op tests elsewhere to be robust in multi-test cases.
03:28.41CIA-62BRL-CAD: Got a couple returns flipped apparently - fixed to the point where 'exists
03:28.41CIA-62BRL-CAD: obj1.s -a obj2.s' and 'exists obj1.s -o obj2.s' are returning what I would
03:28.41CIA-62BRL-CAD: expect, but not sure yet if it's 'right'
03:37.16CIA-62BRL-CAD: 03starseeker * r46575 10/brlcad/trunk/src/libged/exists.c: call out the need to keep the option tables sorted - it's 'implicit' in the use of bsearch but make it explicit in a comment for new coders who are wondering why a new option isn't working...
04:28.02CIA-62BRL-CAD: 03starseeker * r46576 10/brlcad/trunk/src/libged/exists.c: reset t_wp_op for -o as well as -a.
05:13.40*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
09:53.38*** join/#brlcad kunigami (~kunigami@201.53.206.27)
09:57.11*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
10:52.07*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
10:58.43*** join/#brlcad kunigami (~kunigami@201.53.206.27)
11:30.22*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:19.47*** join/#brlcad juanman (~quassel@186.136.168.73)
13:19.54*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
15:03.49brlcadyawns
15:08.05*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:33.27*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
15:42.46*** join/#brlcad kunigami_ (~kunigami@187.106.4.105)
15:44.38brlcadhowdy kunigami_
15:46.37brlcadkunigami: I'd like to pull together an announcement of your work and am looking to showcase some awesome imagery along with a brief writeup
15:55.11brlcadkunigami: so any thoughts you have on what might make a great demonstration or particular items to cover in the writeup would be appreciated :)
16:01.20brlcadon an unrelated thought, time to post a release!
16:02.58brlcadalso unrelated, starseeker: curious cmake (make -j20) build failure in tcl .. fixed by just rerunning make -j20 again
16:03.28brlcad(this was a fresh clean out-of-dir build)
17:12.55*** join/#brlcad kunigami_ (~kunigami@201.82.92.180)
17:29.24starseekerum.  xsltproc occasionally has a problem with massively parallel situations (I think it's an xsltproc bug) but I don't recall tcl failing
18:43.59CIA-62BRL-CAD: 03n_reed * r46577 10/brlcad/trunk/src/conv/obj-g_new.c: Setting defaults so parser can be run without specifying options.
18:50.10CIA-62BRL-CAD: 03starseeker * r46578 10/brlcad/trunk/src/libged/exists.c: tweak message handling for errors, null out t_wp_op for LPAREN
19:04.59*** join/#brlcad merzo (~merzo@98-189-132-95.pool.ukrtel.net)
19:36.26CIA-62BRL-CAD: 03n_reed * r46579 10/brlcad/trunk/src/librt/primitives/poly/poly.c: Having rt_pg_to_bot use initialized memory for rt_bot_internal struct.
19:49.30*** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br)
22:33.18kunigamibrlcad: I'll try to prepare something tomorrow! BTW, I intend to keep on this project, at least one day a week
23:21.14brlcadkunigami: oh, that'd be awesome
23:21.40starseekerbhinesley: still around? :-P
23:21.44brlcadmaybe something with a more complex model in a scene, something that really showcases the nice lighting
23:22.39brlcadn_reed: if you're interested, uploading a slew of nurbs obj files -- same dir as before: OBJ/NURBS
23:23.34brlcadit's about 60MB across a couple dozen examples
23:25.01brlcads/couple dozen/18ish/
23:25.38brlcadfrom what I can tell, it looks like rhino and blender are two common exports that will pump out nurbs obj
23:32.40n_reedbrlcad: looks like the few defective outputs I saw in obj-g were just tolerance issues
23:33.09n_reedso I have no problem starting work on NURBS support
23:40.52*** join/#brlcad Yoshi47 (~jan@d72-39-60-53.home1.cgocable.net)
23:43.25brlcadn_reed: any way to handle the tolerance failures automatically?
23:44.23brlcadmm.. server migration priority just went up a notch .. all this new STEP data is too much for .bz
IRC log for #brlcad on 20110907

IRC log for #brlcad on 20110907

00:05.56*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
00:14.18n_reedbrlcad: specifically the issue was that two inputs had outputs with unwanted holes in them
00:14.55n_reedproblem should be that too few or too many points are being considered identical
00:15.12n_reedusing meters as units (now the default) is enough to fix one of the cases
00:15.28n_reedfixing the other should require adjusting hte distance tolerance
00:16.30n_reeddistance tolerance could be adjusted automatically, but i'm not sure it could be done smartly enough to work in every case
00:26.10*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
00:26.31*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
00:29.52*** join/#brlcad juanman (~quassel@201.255.47.86)
00:29.54*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
00:53.40bhinesleystarseeker: yep, I'm here
00:53.57*** join/#brlcad kunigami (~kunigami@201.82.92.180)
01:11.43brlcadbhinesley: same for your project too, ideas on how to characterize your summer work into a showcase piece?
01:12.37brlcadvisuals are a bit less effective except for maybe a diagram
01:13.26brlcadeasy enough to show how three commands now becomes just one, or a harder case where translating relative to something else turns 10+ steps into just one
01:17.54brlcadstarseeker: I'm not too concerned about the cax-if at this point -- I considered going through the efforts to join them a while back anyways
01:18.56brlcadcertainly not concerned about any of their data tainting the scl just because they don't even provide that kind of information
01:29.08starseekercool
01:54.18starseekerifcOpenShell is kinda interesting
01:58.14*** join/#brlcad merzo (~merzo@98-189-132-95.pool.ukrtel.net)
04:01.23*** join/#brlcad DarkCalfz (DC@173.231.40.98)
04:23.32CIA-62BRL-CAD: 0378.8.106.10 07http://brlcad.org * r3144 10/wiki/User:78.8.106.10: New page: [http://www.williamhickswi.com williamhickswi] Hello, im williamhicksw
04:43.56CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:78.8.106.10]] with an expiry time of infinite (anonymous users only, account creation disabled): Inserting nonsense/gibberish into pages
04:44.05CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:78.8.106.10]]": spam
05:27.42*** join/#brlcad merzo (~merzo@32-92-132-95.pool.ukrtel.net)
05:32.23bhinesleybrlcad: the DESCRIPTION section of the "edit" man page was my attempt at summarizing what it's all about.
05:32.26bhinesleymain concepts you could touch on: use of apparent positions of objects + offsets as references (particular/instance/of/obj 0 2.5 -5), ability to use those object references or actual coordinates interchangably in specifying any of the x/y/z coordinates, performing batch operations (i.e. perform a similar operation on each of *these*)
05:32.31bhinesleyExamples 3 or 4 in the edit_translate manual are practical/interesting uses that show off several features at once. They're simple to understand, yet they would take many steps to perform by conventional means (true for many other modeling packages as well). They would be even harder to replicate if specific instances of objects were used, ex:
05:32.36bhinesleyedit translate -k . -a -z C/D/E/F/G A/obj1 A/obj2 B/obj1 B/obj2
05:32.39bhinesley(move each object instance from the elevation of their respective bb center to the elevation of the apparent bb_center of C/D/E/F/G; in other words, align them at the elevation that C/D/E/F/G is drawn)
05:32.43bhinesleybesides requiring 4 sets of oed + translate + accept (12 steps) at a minimum, personally, I wouldn't even know how to accomplish the exact same task using other mged/libged commands.
05:33.48bhinesleybtw, as shown in example 10, I'm not sure the -r option is strictly necessary since I added the ability to specify offsets with objects.  Something to consider at least, assuming we'll refactor.
05:34.27bhinesleybrlcad: hopefully that's the type of thing you were looking for, if not, let me know.
07:49.19*** join/#brlcad merzo (~merzo@193.254.217.44)
08:32.13CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3145 10/wiki/User:Abhijit: /* Log */
12:58.52*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:15.30*** join/#brlcad kunigami (~kunigami@201.82.92.180)
13:35.01*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:46.09*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-184.wlan.tudelft.nl)
14:56.04*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:14.33CIA-62BRL-CAD: 03tbrowder2 * r46580 10/brlcad/trunk/sh/make_deb.sh: correct typo
15:14.38*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
15:36.36*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
16:33.55brlcadbhinesley: that might work -- I think part of the effort will involve actually characterizing one of the examples into what steps would need to be taken now, to drive that point home
16:46.38CIA-62BRL-CAD: 03tbrowder2 * r46581 10/brlcad/trunk/sh/make_deb.sh: making a little more robust--allow for non-package utilities such as a locally installed cmake
16:52.26brlcadnifty for those that haven't seen it before: http://xlinux.nist.gov/dads/termsImpl.html
18:10.34CIA-62BRL-CAD: 03brlcad * r46582 10/brlcad/trunk/src/tclscripts/lib/ (8 files):
18:10.35CIA-62BRL-CAD: add deprecation warnings to the following widgets: Database, Db, Display, Dm,
18:10.35CIA-62BRL-CAD: Drawable, Mged, QuadDisplay, and View. They are all supplanted by the newer Ged
18:10.35CIA-62BRL-CAD: widget (which hooks to libtclcad for dm/fb/view bindings as well as libged
18:10.35CIA-62BRL-CAD: commands).
18:13.31CIA-62BRL-CAD: 03brlcad * r46583 10/brlcad/trunk/ (TODO doc/deprecation.txt):
18:13.31CIA-62BRL-CAD: formally deprecate the old mged megawidget tcl infrastructure since there may be
18:13.31CIA-62BRL-CAD: users out there using it. they were the precursor to archer, but now archer
18:13.31CIA-62BRL-CAD: goes through a different Ged widget interface that binds to libtclcad.
19:03.57CIA-62BRL-CAD: 03brlcad * r46584 10/brlcad/trunk/TODO: loadview can be better
20:01.48*** join/#brlcad ibot (~ibot@rikers.org)
20:01.48*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
20:01.50jordisayolbrlcad: anyway, is there a way in SF to make as default download for an OS a directory instead a file?
20:04.56jordisayolbrlcad: I've seen that, if I mark as default a 64 bit package, it was the most downloaded, but if I mark the 32 bit package as default, this is the most downloaded too!!! So the conclusion is, people clicks without read/think too much...
20:05.43brlcadjordisayol: not that I'm aware of, it's be a feature enhancement request
20:06.15jordisayolbrlcad: ok, many thanks
20:34.27CIA-62BRL-CAD: 03erikgreenwald * r46585 10/brlcad/trunk/src/libgcv/bottess.c: begin soup2bot(). Cleanup.
20:39.11*** join/#brlcad merzo (~merzo@32-92-132-95.pool.ukrtel.net)
22:06.03*** join/#brlcad merzo (~merzo@32-92-132-95.pool.ukrtel.net)
22:40.04*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
22:43.43*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
22:53.54*** join/#brlcad Stattrav (~Stattrav@203.196.190.162)
22:53.54*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
23:02.27*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20110908

IRC log for #brlcad on 20110908

00:59.23*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
05:37.48CIA-62BRL-CAD: 03brlcad * r46586 10/brlcad/trunk/include/fb.h: these macros aren't very safe. debugged a crash in rtxray related to dereferencing a null fbp. add a FIXME to turn them into proper functions.
05:43.06CIA-62BRL-CAD: 03brlcad * r46587 10/brlcad/trunk/src/rt/viewxray.c: not sure how we're getting to this point, but prevent fb_write() from crashing if fbp is NULL.
06:00.12CIA-62BRL-CAD: 03brlcad * r46588 10/brlcad/trunk/ (BUGS src/rt/do.c): rtxray crashes if you specify rtxray -o any.bw output file as there are assumptions in the rtuif front-end that assume output will be a pix file.
06:06.21*** join/#brlcad merzo (~merzo@244-11-133-95.pool.ukrtel.net)
06:24.45CIA-62BRL-CAD: 03brlcad * r46589 10/brlcad/trunk/TODO: noticed some issues with pixdiff. doesn't handle bw input correctly and default output is misleading (and sometimes wrong).
11:37.10CIA-62BRL-CAD: 0391.198.94.86 07http://brlcad.org * r3146 10/wiki/User:91.198.94.86: New page: [http://www.williamhickswi.com williamhickswi] Hello, im williamhickswi
11:59.36CIA-62BRL-CAD: 0391.198.94.86 07http://brlcad.org * r3147 10/wiki/User_talk:91.198.94.86: New page: [http://www.williamhickswi.com williamhickswi] Hello, im williamhickswi
12:46.21CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:91.198.94.86]]"
12:46.35CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:91.198.94.86]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
12:47.09CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User talk:91.198.94.86]]"
13:09.19*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
13:09.32*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
13:46.53CIA-62BRL-CAD: 03109.230.251.132 07http://brlcad.org * r3148 10/wiki/Wiki_syntax_explained: New page: Guide for writing by using wiki syntax will follow [http://www.mediawiki.com Official Mediawiki Site]
14:01.42CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Wiki syntax explained]]": probing
14:01.56CIA-62BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:109.230.251.132]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
14:02.17brlcadwe're going to have to do something about that soon ...
14:34.31CIA-62BRL-CAD: 03erikgreenwald * r46590 10/brlcad/trunk/src/libged/Makefile.am: reflect that the bullet integration stuff has moved into a simulate/ subdir
14:42.20CIA-62BRL-CAD: 03erikgreenwald * r46591 10/brlcad/trunk/src/conv/intaval/Makefile.am: need both and , or libtcl won't be found
14:43.56CIA-62BRL-CAD: 03erikgreenwald * r46592 10/brlcad/trunk/src/libged/Makefile.am: add exists.c
14:44.13``Erikhuh, vim ate ${WDB} and ${WDB_LIBS} on that commit, whups
14:46.34CIA-62BRL-CAD: 03erikgreenwald * r46593 10/brlcad/trunk/ (bench/Makefile.am src/gtools/beset/Makefile.am): add _LIBS for libtcl link
14:50.59brlcad``Erik: cool, you testing autotools build on bsd?
14:51.26``ErikI'm using fbsd for autogen, but linux for the build
14:51.48brlcadk
14:51.53``Erikrweiss complained that he wasn't updating because it's "always broken", we steered him to installing cmake
14:52.32``Erik(our autoconf has gotten gamey over detecting system tcl correctly, but it's not worth the effort with deprecation in effect)
14:52.33brlcadif it's "always broken" for him, then he's doing something wrong
14:53.01``Erikinfrequent updates + wrong build system? :)
14:53.18brlcadcalls BS
14:53.31``Erikbut I got a complete build on rhel5/x86_64 *shrug*
14:53.37brlcadthe build system should work, especially if he updates infrequently :)
14:54.00brlcadeither way, I only care because I want to tag release
14:54.25brlcaddid/can you check if autotools distchecks clean?
14:54.38``Erikrunning
14:54.41brlcadcool
14:54.47``Erikand a fail
14:55.10brlcadwhen that passes, i'll do a mac build test and sync stable
14:56.23CIA-62BRL-CAD: 03erikgreenwald * r46594 10/brlcad/trunk/include/Makefile.am: config_win_cmake.h went back to having a .in suffix
15:02.36CIA-62BRL-CAD: 03erikgreenwald * r46595 10/brlcad/trunk/src/other/libz/Makefile.am: remove nonexistant header
15:09.46starseekerjabs CIA-62
15:10.13starseekerbrlcad: I think I fixed the togl build to not aways rebuild every time cmake is run
15:14.15*** join/#brlcad ibot (~ibot@rikers.org)
15:14.15*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
15:14.21``Erikneat, http://paste.lisp.org/display/124557  I don't know what exactly to do about that
15:15.02starseekerwinces
15:15.13starseekerthat's that new plugin stuff I put in for libged
15:15.46``Eriksh/cmakecheck.sh
15:16.18starseekernods - not sure what to do about it either
15:16.18*** join/#brlcad CIA-133 (~CIA@cia.atheme.org)
15:24.00CIA-133BRL-CAD: 03starseeker * r46598 10/brlcad/trunk/src/other/tktable/CMakeLists.txt: Same deal for tktable - only rebuild if something actually changes.
15:27.31*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:30.29CIA-133BRL-CAD: 03starseeker * r46599 10/brlcad/trunk/src/other/togl/src/CMakeLists.txt: Generating message is a bit messy for togl stubs, go simple.
15:42.56CIA-133BRL-CAD: 03erikgreenwald * r46600 10/brlcad/trunk/src/libged/ (4 files in 3 dirs):
15:42.57CIA-133BRL-CAD: Hoise subdir build information for CMake build. While the subdir CMake stuff
15:42.57CIA-133BRL-CAD: does work, it causes sh/cmakecheck.sh to fail in automakes dist-hook. Once
15:42.57CIA-133BRL-CAD: automake is completely removed, we may decide to move the cmake build logic back
15:42.57CIA-133BRL-CAD: into the subdirs.
15:43.09``Erikhoist, even
15:43.56CIA-133BRL-CAD: 03erikgreenwald * r46601 10/brlcad/trunk/misc/Makefile.am: update to reflect numerous changes in CMake/
15:46.49``Erikdist succeeds, doing the subdir build right now
15:48.10starseekerbrlcad: I think for the remainder of the issues (relinking everything because we're updating the count) we're looking at something along these lines:  http://cmake.org/Bug/view.php?id=8655
15:48.38CIA-133BRL-CAD: 03starseeker * r46602 10/brlcad/trunk/src/libged/CMakeLists.txt: move the macro to the top to avoid an undefined macro error.
16:03.57CIA-133BRL-CAD: 03erikgreenwald * r46603 10/brlcad/trunk/src/other/Makefile.am: add missing files to EXTRA_DIST
16:09.08starseekercmake looking ok here - make regress just passed (gentoo)
16:30.17CIA-133BRL-CAD: 03erikgreenwald * r46604 10/brlcad/trunk/src/other/Makefile.am: add OSL files
16:32.41CIA-133BRL-CAD: 03erikgreenwald * r46605 10/brlcad/trunk/src/other/incrTcl/ (itcl/Makefile.am itk/Makefile.am): add ac_std_funcs.cmake
16:40.06CIA-133BRL-CAD: 03erikgreenwald * r46606 10/brlcad/trunk/src/adrt/Makefile.am: add isst.bat to EXTRA_DIST
17:03.03CIA-133BRL-CAD: 03erikgreenwald * r46607 10/brlcad/trunk/src/fbed/ (CMakeLists.txt sgi_dep.c): eliminate sgi_dep.c
17:09.24CIA-133BRL-CAD: 03erikgreenwald * r46608 10/brlcad/trunk/src/tclscripts/archer/Makefile.am: add PipeEditFrame.tcl
17:17.38CIA-133BRL-CAD: 03erikgreenwald * r46609 10/brlcad/trunk/db/ (4 files): convert cornell-kunigami from .g to .asc with build rules
17:27.42CIA-133BRL-CAD: 03erikgreenwald * r46610 10/brlcad/trunk/doc/docbook/system/mann/en/Makefile.am: add exists.xml
17:35.52CIA-133BRL-CAD: 03erikgreenwald * r46611 10/brlcad/trunk/misc/Makefile.am: add Doxyfile.in
17:41.10CIA-133BRL-CAD: 03erikgreenwald * r46612 10/brlcad/trunk/Makefile.am: add configure.cmake.sh
17:43.29``ErikI think that's all done O.o
17:43.45``Erikfirst time we've been able to do a cmake build from an automake dist generated tarball, to boot
17:59.06starseekerawesome
18:05.34brlcadexcellent
18:06.17brlcadso was the previous source dist from an autotools make dist?  there was a post to the help forum about missing isst.bat in 7.20.2
18:06.31brlcadI thought 7.20.2 was a cmake dist
18:40.03starseekerI don't think so - IIRC, that might have been before we sorted out the zlib header thing
18:53.19``Erikfrom the saved timestamps in the tarball, I'd assume something like (svn co ... brlcad-7.20.2 && find brlcad-7.20.2 -name '\.svn' -exec rm "{}"\; && (cd brlcad-7.20.2 && sh autogen.sh) && tar zcvf brlcad.7.20.2.tar.gz brlcad-7.20.2)
18:54.03``Erik(mebbe with a -r to the rm and various fixes like that...)
19:05.56CIA-133BRL-CAD: 03starseeker * r46613 10/brlcad/trunk/ (4 files in 2 dirs): (log message trimmed)
19:05.56CIA-133BRL-CAD: Take some steps to mitigate the 'relink everything every cmake run' issue. Use
19:05.56CIA-133BRL-CAD: the build types to decide whether we want to increment COUNT - only do so when
19:05.56CIA-133BRL-CAD: we're doing a build configuration other than Debug, since it's those cases where
19:05.56CIA-133BRL-CAD: we might be concerned how many times CMake has been run. Also change the way
19:05.56CIA-133BRL-CAD: we're getting the timestamp (DATE) in Debug configurations - old method gave the
19:05.57CIA-133BRL-CAD: to-the-second ascii string conversion that's standard in C. For Debug cases,
19:25.13*** join/#brlcad ibot (~ibot@rikers.org)
19:25.13*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
19:35.11brlcadnot sure that's entirely true
19:35.49brlcadif someone's build debug 10 times then release 1, count will be 1 and that's not useful
19:36.31brlcadone of the critical things the count conveys is "this is not the first/only time a build was performed on this checkout"
19:38.14brlcadthe other is that this is the Nth attempt where a large N indicates a build from a particularly active checkout, small N but non-1 indicating that maybe a few tweak passes/rebuilds (maybe cause for concern), and N=1 .. pristine checkout/build/install
19:39.15brlcadwhines that scripting maths is hard
19:42.00starseekerwhat about counting in a non-included file in debug, and then adding in the result of that (if present) when switching to release?
19:48.46brlcadhm, doesn't sound like it's worth having that kind of specific logic around, almost seems better to just incr on every cmake like it was and let it relink because it's simple
19:49.17starseekerdon't think it's hard - there was some positive developer response here to the idea of avoiding relinking
19:49.19brlcadthe benefit was really only if it was easy enough to detect a config change
19:49.29starseekergive me a sec...
19:49.39brlcadnot that it's hard or not
19:50.04brlcadthat it sounds like the type of quirky logic that one looks back at in a few years and wonders, wtf, right before ripping it out
19:50.04starseekerbrlcad: it's got to be worth avoiding relinking 100+ executables
19:50.33brlcadis it not feasible to do your earlier idea?
19:50.40starseekerwhich earlier idea?
19:51.05brlcadyou'd mentioned being able to detect that something in the config changed, incrementing then
19:51.21brlcadlike saving the previous cache or detecting a cache change or similar
19:51.56starseekerthe problem is, the headers DO change each time you run config if you increment COUNT
19:51.57brlcadi don't recall the exact mechanism you had in mind, it was getting late
19:52.02starseekercount is included in the headers
19:52.09brlcadriiight
19:52.14starseekerif the COUNT file changes, relinking is guaranteed
19:52.22brlcadyes, understood
19:52.30brlcadthe idea was to only incr count if config changed
19:52.43starseekeroh, I recall - diffing the cache files?
19:52.50brlcadnot every cmake, but every cmake where something is different from the previous
19:52.57starseekerum...
19:53.08brlcadit was your idea, I liked it ;)
19:53.37brlcadthat basically caters to all the cases
19:53.43brlcadand keeps relinking to a useful minimum
19:54.08starseekerthe difficult was that a cache file isn't written until the end of the CMake process - so it's comparing an old cache file with the current "in memory" state of CMake
19:54.24starseekerthat sounds more complex than COUNT trickery
19:54.54brlcadnot at all complicated to explain though and no unintended side effects
19:55.23brlcadmaybe more complex to implement, but not more complex to maintain (it doesn't smell wierd, the other method really does)
19:55.33starseekerMUCH more complex to implement
19:55.41starseekermuch MUCH more complex
19:55.52brlcadhas confidence in starseeker's cmake magic ;)
19:56.18starseekergrumble...
19:56.37brlcadso leave it to relink each cmake, I still think that's better than something that makes the count toggled based on specific parameter values
19:57.26brlcadi.e., more important that "the value" have a simple definition than the build system wrapping around it
19:57.39brlcadincrementing every cmake (or make) isn't ideal, but it's bad either
19:57.45starseekerthinks the developer time saved avoiding all the useless relinking is more valuable than the COUNT variable (which, to be fair, he has NEVER used, so he may not have a good appreciation of its benefits...)
19:57.48brlcadevery config would probably be ideal
19:58.23brlcadactually, what I said earlier -- the original behavior -- was ideal, incrementing every build pass but only using it every link :)
19:58.50starseekernot possible in CMake as it exists today, apparently
19:58.59brlcadsure, not possible with autotools either
19:59.48brlcadmaybe with a custom make rule .. but not that big an issue
20:01.13brlcadI actually check that number every time I sit down at an unknown install to see what the user (even if it's just me) is running
20:01.45brlcade.g., right now: "Compilation 18"
20:01.54brlcaddefinitely a dev checkout
20:02.45CIA-133BRL-CAD: 03starseeker * r46614 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: Snarf environment variables like we're supposed to, don't ignore the user's CFLAGS...
20:03.07starseekersuspects he is far more included than brlcad to just check out a clean repo and/or blow away and rebuild...
20:03.09brlcadI'd frankly probably be more inclined to drop the count before changing the meaning of the number
20:03.20brlcad"Compilation 18 (or possibly more)" just isn't useful
20:05.55brlcadI do that for some builds too -- it's not about the dev, it's the code -- that's what the number tells you
20:06.39brlcad*when* it isn't a clean repo, that can be very useful to know
20:06.58CIA-133BRL-CAD: 03starseeker * r46615 10/brlcad/trunk/CMakeLists.txt: Sean wants this COUNT to be independent of build type
20:07.02starseekersvn status ftw
20:07.14brlcadeh?
20:07.20starseeker"not a clean repo"
20:07.29brlcadI don't necessarily have svn status when I'm running the binaries
20:07.41starseekeroh, you mean a build from a clean repo
20:07.43brlcadI'm running mged or rt or something else from an install
20:08.10brlcadthis is all about having an install let us know what kind of environment it came from
20:08.19brlcadnot just build settings, that's easy
20:09.03starseekerbrlcad: can I at least add an advanced developer option to disable the COUNT?
20:10.51brlcadif I encounter a crash while running rt and I see Compilation 18, the very first thing that begs (no matter where or who's desk I'm sitting at) is to not even mess with debugging it -- redo the install
20:12.20starseekerbrlcad: I restored the default behavior (I suppose I should yank the copy_if_diff logic for that file, since it's now useless)
20:12.24brlcadthat would completely defeat the purpose of the COUNT, back to the same "Compilation 1 (or possibly more)" situation
20:12.43starseekerbrlcad: only if a developer specifically turns it on though
20:12.59starseekerI could locally tweak the CMake logic to do exactly the same thing
20:13.41brlcadhow will I know when I run a random installed rt whether the dev turned it on or off?
20:13.54brlcadgood faith trust?
20:14.21starseekerwhat about setting the count to -1 or something like that when turned off?
20:17.33CIA-133BRL-CAD: 03starseeker * r46616 10/brlcad/trunk/CMakeLists.txt: copy_if_different logic is useless for COUNT, so remove it
20:17.57brlcadthis is not a productive way to continue discussing changes like this
20:18.10brlcadmight as well remove it entirely because it's either useful and used or it's not
20:18.35starseekeryou use it, so we'll got with that
20:18.50brlcadyou obviously don't use it, so you're asking every question to modify the feature into the minimalist way to make you not have to care about it
20:19.03brlcadthe answer should be to either use it or have a discussion on the merits to remove it
20:19.05starseekerprobably should use it
20:20.25starseekermore productive then... you mentioned the original system incrementing every build pass but only using it every link
20:20.44brlcadI'm not opposed to removing it, I'd choose removing it over making it only sometimes a useful value for example
20:20.47starseekerwhat would be a good way to have CMake generate logic to do that?
20:20.57brlcadI have no idea :)
20:22.19brlcadin Make lingo, it involved putting the version into into a compilation unit (vers.c), and then specifying vers.o during link but not as a make rule dependency
20:22.59brlcadso it only compiled and linked vers.c when it was going to link
20:23.11brlcadsomething like that at least
20:24.03starseekerum.  you mean vers.o was linked with the executables directly, or with the libraries?
20:24.23brlcadseparate ones for both
20:24.45brlcadI got rid of all the front-end versioning, not as useful as knowing the library
20:24.51brlcads/all/most/
20:29.04starseekererm.  We're agreed that if I can detect whether there was any actual configuration change, that's the best criteria for incrementing the count?
20:33.01brlcadthat sounds like the best closest useful fit to me
20:33.31starseekerok.  I might be wrong about how tricky that is - let me do some tests
20:35.18brlcadif you can't figure it out, don't sweat it -- I won't cry if the feature is removed, it's installation metadata
20:36.01starseekerif you do check it everytime though, it's telling you something useful (/me has a lot of respect for brlcad's notions of efficiency, if it wasn't useful you would have optimized it out already :-P)
20:36.09brlcadI find it useful, but certainly not critical or even worth debate, just informative when needed
20:45.48brlcadI will conceed that it's probably not worth keeping if it'll relink every cmake since we're talking about a time savings of approximately 30 minutes a couple times a year to redo an install
20:46.03brlcadthat's generously maybe 3 hours throughout the year
20:46.46starseekerhang in there - I just got a parse out of the CMakeCache.txt contents
20:47.36brlcadif cmake changes once a week across half a dozen developers and relinking takes optimistically 1 minute, that's 52 * 6 or roughly five hours
20:48.06starseekerwas just trying to get everything all nice and tidy after figuring out how to get togl and tktable to stop rebuilding, which is fundamentally a pretty stupid motivation
20:48.21brlcadsimilarly, if it takes you more than 3 hours to figure it out, it's not worth it ;)
20:48.28starseekermea culpa
20:48.46brlcadhey, a love nice and tidy
20:48.52brlcadyou know that! :)
20:49.11brlcadobsessive attention to detail ftw
21:37.33*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
22:27.47starseekerbrlcad: what about the date stamp?  I cut down the info in it to avoid seconds/minute changes triggering the same linking issue, should I just use that stamp for all builds?
22:28.31``Erikhm, kernel.org seems to be down :/
22:28.48starseekerthey fixing their servers?
22:30.20``Erikcan't get a dns resolve
22:30.31``Erikwhich sucks, cuz an updated version of git came out
22:30.33starseekerwinces
22:30.51starseekeris Linus hosting that on github too?
22:31.02starseekeror the git devs rather?
22:31.05``Eriktried several country resolves, I assume their toplevel dns crapped out a bit ago, long enough for propogation
22:31.24``Erikthey have a git repo and a .zip file, plus old files... but not the tar.bz2 that fbsd/ports wants
22:31.47``Erikand I'd kinda like the signed checksums, y'know? :D
22:31.55starseekerah
22:36.02brlcadstarseeker: no entiendo
22:37.02starseekerthe date stamp I had been writing out into include/conf/DATE printed the asciitime string including hours:minutes:seconds, so it got changed each time cmake ran
22:37.25``Erikeigo kudasai O.o
22:39.48n_reedenglish, spanish, japanese... doesn't matter to me :)
22:40.02starseekerthey're all greek? :-P
22:40.22n_reedno, i can read them all
22:40.47``Erikdon't make me dig up translate.google.com to find something incredibly obscure O.o
22:40.53starseekerheh cool :-)
22:41.03``Erikano bakka kuso ttare
22:44.43starseekerneeds to see what autotools does for DATE, come to think of it
22:45.19``Erikprobably runs "date"
22:45.30CIA-133BRL-CAD: 03starseeker * r46617 10/brlcad/trunk/ (4 files in 2 dirs): (log message trimmed)
22:45.30CIA-133BRL-CAD: Make a serious stab at incrementing the COUNT variable only when the
22:45.30CIA-133BRL-CAD: configuration actually changes. For the moment, this is accomplished by reading
22:45.30CIA-133BRL-CAD: the old CMakeCache.txt file (stashed at the beginning of the second cmake run)
22:45.30CIA-133BRL-CAD: and comparing values found there to values in the current CMake enviornment.
22:45.31CIA-133BRL-CAD: It's not perfect in that new variables in the working environment won't trigger
22:45.32CIA-133BRL-CAD: the COUNT increase, but for most reconfiguration situations something will be
22:45.52starseekeryeah, that's gonna trigger a relinking then - date includes minutes and seconds of current time
22:47.27starseekerbrlcad: see how that looks - if that doesn't look good I can pose the problem on the CMake list.
22:49.40``Erik*look* autoconf does use date, but with the format string
22:50.00``ErikCONFIG_DAY=`date +%d`
22:50.47starseekerecho "\"`LANG=C date -R 2>/dev/null || date +'%a, %d %b %Y %H:%M:%S %z' 2>/dev/null || date`\"" > $@
22:53.25starseeker%M and %s are the trick, maybe %H too
22:53.34starseekers/%s/%S
22:54.46``Erikwhen I used B|X instead of irssi, I was putting logs in seperate dirs by day, the cron job had mkdir `date +%Y%m%d`
22:55.35``Erikand for dump scripts, I do something like $host-$fs-`date +%Y%m%d%H%M`.dump.bz2
22:55.37starseekerin CMake I'm actually generating the date stamp with C code (date available on all platforms) - I can do a custom string, the issue is that means not using the "standard" format
22:55.54starseekerdate ISN'T available on all platforms
22:55.58starseekersheesh
22:56.27``Erikstrftime() is :)
22:56.54starseekerah, didn't know about that
22:57.07starseekercool, that will simplify the time.c.in code
22:57.42starseekerbut that gets back to whether brlcad wants to have the DATE file do something different from the standard ascii string
22:57.49starseekerisn't going to assume this time
23:01.28*** join/#brlcad merzo (~merzo@248-122-133-95.pool.ukrtel.net)
23:08.05*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:20.47CIA-133BRL-CAD: 03starseeker * r46618 10/brlcad/trunk/CMakeLists.txt: Silly developer. If detecting config changes, need the copy_if_diff code again
23:22.00brlcadautotools writes out the date in RFC 2822 format
23:22.04brlcaddate -R
23:22.14brlcadfor gnu date, or date +'%a, %d %b %Y %H:%M:%S %z' for others
23:22.30brlcadah, you found it
23:25.28brlcadRFC 2822 is particularly useful because it's easily human readable and computer parsable without sacrificing info
23:25.36CIA-133BRL-CAD: 03starseeker * r46619 10/brlcad/trunk/CMakeLists.txt: copy/paste strikes again
23:26.46starseekerbrlcad: no argument - the issue is that when cmake re-runs and makes a new DATE, we've got the linker issue all over again if we include minutes and seconds
23:26.54starseeker(those for sure - hours may be an issue)
23:28.43brlcadcouple the date stamp regeneration to COUNT?
23:28.53starseekerhmm, good idea
23:29.00starseekerdigs
23:29.14brlcadif you need to generate 2822, this should help: http://inn.eyrie.org/svn/tags/2.4.4/lib/date.c
23:29.24brlcadbsd-licensed, only need one or two functions from it
23:29.30starseekerwas assuming asciitime did that, but maybe not...
23:31.04starseekerasctime rather
23:32.02starseekerand.... bzzt, wrong
23:32.06starseekerlooks at date.c
23:34.37brlcadstarseeker: yeah, I don't believe so
23:34.41brlcadbut strftime() should
23:34.53brlcadsince you can specify the '%a, %d %b %Y %H:%M:%S %z' format string
23:35.12brlcadforgot all about asctime()
23:36.19brlcadhopefully shouldn't need that date.c impl .. strftime() is c90
23:36.33starseekertries that to start
23:36.41brlcadhttp://msdn.microsoft.com/en-us/library/fe06s4ak(v=vs.80).aspx woot
23:37.11brlcadbeen there since '95, better than good enough
23:37.46brlcadalrighty!  .. finally finished revamping the nurbs test script
23:39.13brlcadnow with matching view rendering, better percentage deviation reporting, and normalized rays/s calculations
23:39.18starseekerawesome!
23:40.26brlcadhaven't been able to think of a good way to make this script more useful in a general context .. it does a lot of workhorsing
23:41.12brlcadactually might make for a nice regression test.. ends up invoking about a dozen different tools
23:42.26starseekercool
23:42.49starseekerwe could probably use a NURBS regression test
23:43.14``Erik(might wanna contemplate migrating #!/bin/sh to tclsh or something some day)
23:45.23starseekerwe discussed that once - apparently that comes under the "labor of Hercules" heading :-/
23:46.31``Eriksame category as cmake, heracles? :)
23:46.44starseekeris betting worse, actually...
23:47.09``Erikmebbe not, say, footer, header, indent... but regress, bench... things winderz folk might want to try
23:48.25``Erik'nut' tells me I should eat pizza :/ (available on bz)
23:51.06starseeker``Erik: brlcad has put a lot of pretty serious work into those sh scripts - I don't even want to think about what it would take to reach parity with tclsh
23:54.05starseekerprobaby easier to stuff an sh impliementation into src/other and make it work on Windows - I think brlcad may have mentioned pdksh as a possibility, but I'm not sure
23:58.52brlcadyeah, I'm pretty adept at tcl, but some of those scripts do things I don't think I could easily do with tcl (or python or perl ...)
23:59.59brlcadsome shell tricks just aren't possible, so you'd end up having to do some manual expansion of logic into something equivalent
IRC log for #brlcad on 20110909

IRC log for #brlcad on 20110909

00:00.31starseekeris looking, but doesn't see any immediate indication that anyone has pdksh compiling with MSVC...
00:03.33brlcadhttp://en.wikipedia.org/wiki/Korn_shell says some versions of windows already include a posix-compliant ksh, and http://en.wikipedia.org/wiki/UWIN
00:03.43CIA-133BRL-CAD: 03starseeker * r46620 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/test_srcs/time.c.in): Yay! RFC2822-ify the DATE stamp code, and go with Sean's idea of linking the DATE regeneration to the COUNT regeneration.
00:04.23brlcadthe main portability issue is getting a pseudo terminal interface, which was the other part of that equation
00:04.24starseekerurm.  CPL?  not very familiar with that license
00:04.54brlcadyou need a terminal to run a shell, if you have that, porting the underlying shell is pretty trivial
00:05.25starseekerwinces
00:05.52starseekerso I guess it boils down to whether implementing a terminal emulator in Windows is easer than the sh->tclsh port
00:06.18brlcadmeh
00:06.24brlcadthe shell scripts are all developer infrastructure
00:06.56starseekerwould be nice to do regress/bench with MSVC
00:07.00brlcadnot a big deal if you can't test some parts of the system on Windows, you can everywhere else
00:07.11brlcadbench is a diff issue, already on it
00:07.51starseekerah, cool :-)
00:08.27brlcadsure it would be nice to have all of regress on windows, but not "absolutely must have necessary" .. and there is cygwin/mingw if we really want to be pedantic, it's pretty trivially possible
00:09.39brlcadlet a windows diehard rewrite them :)
00:11.21starseekerheh
00:21.46starseekerbrlcad: how does that new setup look?
00:22.02starseekerseems to be behaving OK here, so far
00:33.42brlcadbeen working on getting the final nurbs rerun kicked off again for another 10-20 hours of processing
00:35.30brlcadnow that it's done and churning, hopefully it'll be a clean run and the stats can be distributed as a baseline
00:36.07brlcadi'll be kicking off some builds here in a couple minutes so i'll let you know how it goes :0
02:44.46CIA-133BRL-CAD: 03173.234.97.161 07http://brlcad.org * r3149 10/wiki/User:108.62.162.154: New page: [http://www.galeriabali.pl/pl/Ryby owoce morza] Szeroki wybor w karcie dan spowoduje, ze znajdziesz cos wyjatkowego a ciekawosc jak smakuja inne dania sprawi, ze nie beziesz mogl sie docze...
03:17.31CIA-133BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:108.62.162.154]]"
03:17.32CIA-133BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.97.161]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
03:27.47CIA-133BRL-CAD: 03starseeker * r46621 10/brlcad/trunk/src/libged/CMakeLists.txt: need to ignore the simulate files if we're not building them
03:32.13starseekerbrlcad: I'm a bit confused about how to approach an aspect of the distcheck rule - I can ignore files that the build logic doesn't know about and not include them in the tarball, but how do I distinguish between "junk" files that should be ignored and files that the developer genuinely forgot to include? (like the simulate files if bullet isn't found)
03:41.38CIA-133BRL-CAD: 03starseeker * r46622 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: Improvements to the distcheck logic - haven't quite got to activting the CPack tweaking logic, but close. In the meantime, better error reporting.
03:54.30CIA-133BRL-CAD: 03starseeker * r46623 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: more TODO notes for dist
04:02.02brlcadstarseeker: the autotools build checks the svn manifest -- if they're in svn, then they should be in the dist
04:02.51starseekerurm.  So I need to parse the svn manifests.
04:04.00brlcad12-liner coming:
04:04.03brlcaddist-hook:
04:04.03brlcad<PROTECTED>
04:04.07brlcad<PROTECTED>
04:04.09brlcad<PROTECTED>
04:04.12brlcad<PROTECTED>
04:04.14brlcad<PROTECTED>
04:04.17brlcad<PROTECTED>
04:04.19brlcad<PROTECTED>
04:04.22brlcad<PROTECTED>
04:04.24brlcad<PROTECTED>
04:04.27brlcad<PROTECTED>
04:04.29brlcad<PROTECTED>
04:04.55brlcadthat's how autotools does it -- gets the list of names from the ".svn/entries" files, then looks to see if they're in the source dist that was built
04:05.10brlcadif missing, reports then halts
04:05.39brlcadthat script-fu should convert pretty simply to cmake funcs
04:06.31starseekerthose entries files are per .svn directory?
04:06.40brlcadyes
04:07.04brlcadthey're simple text, pop one up
04:07.52brlcadbasically xml blocks with name="filename" identifiers
04:08.18starseekerwhat does it do without the .svn directories then?
04:09.06brlcadno manifest, no way to know what's actually missing
04:09.09brlcadso it does nothing
04:09.12starseekerah
04:09.24starseekerthat's actually the case I have implemented then :-/
04:09.38brlcadit could report what files were found, but meh .. 99% of the time, we have the list
04:10.10starseekernods - I'll leave what I have for that case (no .svn entities files found) and figure out the .svn manifest part
04:10.30brlcadyeah, that's probably very reasonable behavior -- no svn files, report and could even halt
04:10.56brlcadbut if there is a manifest, it probably shouldn't halt on the unknowns
04:11.29starseekernods
04:11.38CIA-133BRL-CAD: 03starseeker * r46624 10/brlcad/trunk/CMakeLists.txt: Echo some messages to identify various stages of distcheck.
04:11.39brlcadarguably useful to even report them since our actual "correctness" rule is only to make sure what's in svn is in the dist
04:11.41starseekerthat's what I was figuring - with svn manifests, it's sane to continue
04:12.04brlcadbut even reporting them could be good sanity too
04:12.18starseeker<shrugs> at least flags the trouble spot
04:12.28brlcadthe biggest catch is finding things you *know* are in svn but are missing
04:12.31brlcadyeah
04:13.15starseekerI doubt I'll be ready with an svn based distcheck for this release :-(
04:13.36brlcadthat's fine
04:13.45brlcadplanning on distchecking with both anyways
04:13.57brlcadif you want to get fancy -- one thing I never got around to fixing is if you svn delete a file, the entry remains (with a deleted flag in the entries record)
04:14.45starseekernods - sounds worth doing
04:14.55brlcadrarely hit it in practice so not a big deal, but one more place to knock the autotools build down a notch
04:15.24brlcadwould be a bigger issue if we deleted/renamed files more frequently between releases (and not just whole dirs)
04:16.17starseekernods
04:16.29brlcadoh wow, so I thought it was still relinking everything ....
04:17.04brlcadbut turns out it's just that slow to walk over all 400+ targets to evaluate and print "Built target ..."
04:17.24starseekerO.o
04:17.41brlcadcool, so looks like it works
04:17.47brlcadto do nothing:
04:17.48brlcadElapsed compilation time: 1 minute 7 seconds
04:18.07starseekerwhat's the autotools time to do nothing?
04:18.39starseekeractually, with all the docbook targets present (even without pdf) I think it's over a thousand targets...
04:18.57brlcadyeah, it is
04:19.08starseekerthat was fun in Visual Studio
04:19.14brlcadgood question, I don't recall off the top of my head but was less
04:19.38brlcadcounts the number of targets
04:19.40starseekerbets it's about 50-60%, mostly due to faster docbook
04:20.14CIA-133BRL-CAD: 03108.62.166.91 07http://brlcad.org * r3150 10/wiki/User:108.62.173.114: New page: [http://www.willa-sloneczna.euroadres.pl noclegi kazimierz dolny] .Kiedy mysli sie nad slowami dluzszy pobyt to prawdopodobnie rozwazasz o kilku tygodniach lub miesiacach. W rzeczywistosc...
04:20.22brlcadsunufa!
04:20.38brlcadlooks like I know what I'm doing tomorrow
04:20.56CIA-133BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:108.62.173.114]]"
04:21.03starseekeroddly enough, I'll be doing something similar (cleaning bathrooms ;-)
04:21.06CIA-133BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:108.62.166.91]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
04:21.48brlcadgood thing is that it takes less than 30 seconds to revert and block .. but still, pita!
04:21.52brlcad1175 targets :)
04:22.32starseeker<evil laugh>MWA_HAHAHAHAHA</evil laugh>
04:23.09starseekerhmm - time to do nothing on my Linux box here - 4 seconds
04:24.04starseekercan't wait to post a table somewhere with Linux, Mac and Windows build times side by side
04:25.03starseekerbrlcad: you're feeding it the make -j# for the empty case?
04:26.22starseekertries on a mac once...
04:26.35brlcadI had the first time, but not that timed one
04:27.00starseekerit should make a difference
04:27.43brlcadprobably, but not a huge one .. this laptop only has two procs and the disks are too fast and os x is an i/o bottleneck
04:27.52starseekerah
04:27.53brlcad1min9sec
04:28.02starseekerphooy
04:28.03brlcadso .. bout the same
04:33.16starseekerbrlcad: so it looks like we're closing in - svn manifests for distcheck and turning the MSVC stuff into tests are the two biggies I know about
04:33.28starseekeroh, and finishing updating the docs
04:33.38brlcadmsvc into tests?
04:33.46starseekerconfig_win going byebye
04:33.55brlcadah great
04:35.17brlcadshould probably hit the docs first, the sooner the deprecation statements get added, the sooner we can remove the build in a couple months
04:35.17starseekeris considering making a small convenience NSIS installer for the Windows xsltproc
04:36.39starseekerknows you had a list of things to add statements to - configure obviously, and autogen.sh
04:36.50starseekeris that in a TODO somewhere?
04:37.01starseeker(just so  I know what to hit)
04:37.41brlcadthose two are the main ones
04:38.22starseekerdid you want to add notes in the current documentation files, or just swap them out when the time comes?
04:38.46brlcadjust swap, if it's deprecated then there's no need to educate on the old system
04:39.07brlcadthe statements are just added to the remnants visible for those that did learn the old way
04:39.09starseekernods - oh, is the new Bundled/System/Auto option setup to your liking?
04:39.23brlcadhaven't dove that deep again
04:39.31starseekerah, k
04:39.37brlcadhm, libpc bustage
04:41.52starseekerprobably the new boost
04:41.57brlcadyep
04:42.26starseekergrim?
04:43.09brlcadtrivial
04:43.13CIA-133BRL-CAD: 03brlcad * r46625 10/brlcad/trunk/configure.ac: reflect new location of boost headers
04:43.37starseekerah :-)
04:45.07brlcadthe new normalized rays/s is pretty cool
04:45.52starseekeroh, in your benchmark?
04:46.04brlcadyeah
04:46.25starseekertries clang as long as he's on the mac...
04:46.42starseekerhow're nurbs stacking up?
04:47.03brlcadpulls rays/s from the summary for a given trace, but then also calculates how many pixels actually involved geometry and weights the rtfm value
04:47.25starseekersweet
04:47.32starseekerwas that the math you were scripting earlier?
04:48.00brlcadrelated, but that was actually for the projected area and volume cases
04:48.12starseekeryow
04:48.47brlcadthey have to do something a bit more tricky since I'm trying to report a relative deviation as percentage error
04:49.00starseekerkinda sounds like stuff mged should have had tools for
04:49.44brlcadmmm, dunno
04:49.52brlcadnot seeing general utility
04:50.01brlcadfor the pix comparisons, sure
04:51.00brlcadbut there the math is easy, just 1 - (num_pixels_wrong / num_pixels)
04:51.33starseekerah - guess I was thinking something like having rt report the "pixels involving geometry" metric
04:51.56brlcadah, maybe but that was also pretty easy to script
04:52.01brlcadwith existing tools
04:52.18starseekercool
04:52.18brlcadthe hard one is the volume and error
04:52.48starseekerhmm:  src/conv/g-vrml.c:99:21: warning: using extended field designator is an extension [-pedantic]
04:52.50brlcadamount_vol_wrong / amount_vol doesn't give what you want
04:53.20brlcadwell, at least doesn't give what *I* want :) .. that just reports the % difference
04:53.27starseekernods
04:53.39starseekersounds like a problem for our resident math genius ;-)
04:53.58brlcadended up with this little bit of goodness: dc -e "1k 100.0 $bvol $vol - d * v $bvol / 100.0 * - d [0] sa 0.0 >a p"
04:54.08starseekerO.o
04:55.25starseekerwatches SdaiCONFIG_CONTROL_DESIGN.h barf warnings and reflects that he REALLY needs to try the newer SCL code...
04:57.00brlcadwhich is basically: 100.0 - abs(actual_volume - real_volume) / actual_volume * 100.0  but then clamping the value to 0.0 if it goes negative
04:57.30starseekernods
04:57.47brlcadactual is tiny and real is huge, then the "difference factor" is going to be huge
04:58.28starseekerso it's amplifying the difference?
04:58.29brlcadbasically means objects that are smaller than the baseline will have an error value that is the percentage of the actual volume
04:58.49brlcadan object half as big as it's supposed to be is going to report a volume error of 50%
04:58.59starseekerah, gotcha
05:00.43brlcadbut then for objects larger than they're supposed to be, it'll report 50% when it's 50% larger and 100% error when it's double (*or* more) in size
05:00.58brlcadthat's the case that was hard to figure out
05:01.13brlcadsince it can be unboundedly larger than the baseline
05:01.46brlcadgood stuff
05:01.52starseekerare you seeing cases much larger than baseline?
05:02.00starseekeris curious how that could come about...
05:02.37brlcadthere are some clear failures, but most are slight larger/smaller deviations
05:02.42brlcadbots
05:02.58brlcadthe calcs will work for any case though
05:03.10starseekernods - that's cool :-)
05:04.44starseekeraw - clang build busted on obj-g_new.c
05:05.26starseekerok, I gotta get out of here
05:05.59starseekerbrlcad: let me know if you see an problems with the new COUNT setup, but I think that will do the trick for most situations we're likely to see
05:11.10CIA-133BRL-CAD: 03starseeker * r46626 10/brlcad/trunk/src/conv/obj-g_new.c: size_t -> size_t * for comparison
05:11.20starseekerand we build with clang again :-)
05:11.27starseekerhits the road
05:12.09brlcadit's looking great
07:43.37*** join/#brlcad ibot (~ibot@rikers.org)
07:43.37*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
09:07.01*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
09:50.29*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:07.35*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-185-071.wlan.tudelft.nl)
13:28.28starseekeroh, beautiful - apparently a Makefile doesn't know what N is in make -j N
13:28.33starseekerhttp://old.nabble.com/MAKEFLAGS-var-does-not-show-%22-j%22-param-----td15983337.html
13:36.33brlcadstarseeker: that's not what that thread says
13:38.55brlcadsays make-w32 doesn't implement the parallel build with the "job server" mechanism, so it redoes the parameter for some other mechanism on windows
13:45.14*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
14:02.59*** join/#brlcad abhi2011_ (~chatzilla@wlan-145-94-185-071.wlan.tudelft.nl)
14:06.32starseekerbrlcad: not the windows part, the part where $(MAKEFLAGS) will never show the -jN option in parallel
14:07.09starseekerneeds to introspect in the Makefile what the -j option passed in was, and it apparently can't be accessed at all
14:08.25starseekerjust gives back the --jobserver-fds=3,4 -j contents regardless
14:08.29starseekerconfirms that in tests here
14:16.16*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
14:20.01brlcadstarseeker: ah, I see what you're getting at
14:20.12*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
14:20.38brlcadthat's undoubtedly because the jobserver is being entrusted with that detail
14:25.08brlcadstarseeker: couldn't you just set it up so that it just toggles off a cmake variable?  cmake -DJOBS=3
14:25.38brlcadthen you can access that to add -j$JOBS during dist or wherever
14:27.01starseekerthat would mean doing something like cmake -P distcheck.cmake -DJOBS=3 instead of make -j3 distcheck
14:27.18starseekerworkable, but it takes distcheck outside the make system
14:27.39brlcadnot necessarily
14:28.30brlcadso you could run "cmake -DJOBS=3 path/to/src" during setup, but it doesn't actually do anything with it other than stash it
14:28.56starseekeroh, set the job count at cmake configure time instead of make time?
14:29.04brlcadthen "make distcheck" would use the stashed value, or at worst maybe "make distcheck JOBS=3" instead
14:29.18brlcadto override at make-time
14:29.28starseekerisn't sure the override would work...
14:29.33brlcadanother options is just "-j"
14:29.46brlcad-j without a number means "go hog wild"
14:29.50starseekerheh
14:30.30starseekereven that's tricky though - accessing make values to feed to CMake isn't really something the CMake generated scripts are set up for
14:30.47starseekerhas an email into the CMake list to ask about it
14:31.31starseekerideal case would be to add the ability to CMake generated make files to respect some variable (JOBS or CPUS) passed in at make time
14:32.53starseekermaybe have a ${CMAKE_CPU_COUNT} variable at CMakeLists.txt level that could be added to the --build line, e.g. ${CMAKE_COMMAND} --build -j${CMAKE_CPU_COUNT} and then have the CMake makefiles do the right thing
14:35.51brlcadthat's kind of what I mean, just s/CMAKE_CPU_COUNT/JOBS/
14:36.15starseekernods - that would take support on the CMake generator backend
14:36.46brlcadCMAKE_NCPU would be a "proper" prefixed form I guess :)
14:36.52starseekerhehe
14:36.57starseekerwill suggest that
14:37.26starseekermake NCPU=3 isn't make -j3, but it is probably as close as make will let us get
15:04.07CIA-133BRL-CAD: 03brlcad * r46630 10/brlcad/trunk/ (include/bu.h src/libbu/fnmatch.c src/librt/search.c):
15:04.08CIA-133BRL-CAD: expose the documented minmum inteface for bu_fnmatch() including the various
15:04.08CIA-133BRL-CAD: flags that a caller might set as well as the nomatch return value. remove the
15:04.08CIA-133BRL-CAD: other BU_-prefixed symbols from the implementation since they're not public api.
15:04.08CIA-133BRL-CAD: renamed BU_CASEFOLD to BU_FNMATCH_CASEFOLD in the process for bu api
15:04.08CIA-133BRL-CAD: consistency.
15:18.35*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
15:33.54brlcadstarseeker: do you remember why you made the plans in librt/search.c void* instead of db_plan_t* ?
15:35.25starseekermight have had something to do with how I was calling things from libged
15:37.58CIA-133BRL-CAD: 03starseeker * r46631 10/brlcad/trunk/ (CMakeLists.txt autogen.sh configure.ac): Make the depends explicit for these initial commands - looks like ninja actually caught one out.
15:38.04starseekerah crud
15:38.24starseekerbrlcad: well, how do those look for autogen.sh and configure.ac deprecation warnings?
15:40.00CIA-133BRL-CAD: 03brlcad * r46632 10/brlcad/trunk/src/librt/search.c: lets not add 50 new functions to librt's API. mark all of the implementation functions as HIDDEN.
15:44.05CIA-133BRL-CAD: 03brlcad * r46633 10/brlcad/trunk/src/librt/search.c: ws indent consistency cleanup
15:44.38CIA-133BRL-CAD: 03brlcad * r46634 10/brlcad/trunk/include/raytrace.h: migrated command doc from impl to header for db_search_formplan()
15:53.30CIA-133BRL-CAD: 03brlcad * r46635 10/brlcad/trunk/include/common.h: better document why we use HIDDEN, emphasize that it's not really appropriate for front-end code but is expected for libraries.
15:53.55CIA-133BRL-CAD: 03brlcad * r46636 10/brlcad/trunk/src/libged/search.c: mark the private functions as HIDDEN
15:55.26CIA-133BRL-CAD: 03starseeker * r46637 10/brlcad/trunk/ (autogen.sh configure.ac): these got sucked in by mistake
15:56.28brlcadstarseeker: good start, but a few changes -- s/may be/will be/
15:56.39starseekerah, right
15:56.44brlcadand "Please use .." doesn't really say anything
15:57.14brlcadthey're using what they know, so we should tell them what the new command is AND where to read for more info
15:57.39starseekerk
16:33.50CIA-133BRL-CAD: 03starseeker * r46638 10/brlcad/trunk/CMakeLists.txt: Try a recommendation from Dave Cole of CMake - this is (more or less) what they do in their ExternalProject code to handle subbuilding
16:44.25brlcadstarseeker: is ninja one of the cmake devs or some system??
17:02.12CIA-133BRL-CAD: 03brlcad * r46639 10/brlcad/trunk/src/libbu/ (argv.c vls.c): move bu_argv_from_string() from vls.c to argv.c
17:06.12starseekeroh, sorry - new CMake generater for this:  http://martine.github.com/ninja/manual.html
17:06.45brlcadah
17:07.05starseekerin development at the moment
17:11.33starseekerhttp://www.cmake.org/pipermail/cmake/2011-September/046145.html
17:11.53brlcadnods
17:12.11starseekerfaster building ftw, if it actually works
17:15.37CIA-133BRL-CAD: 03brlcad * r46640 10/brlcad/trunk/ (include/bu.h src/libbu/argv.c): make bu_argv_from_string() work with size_t instead of int for the size parameters. move the decl over with the other argv functions. need ctype.h header for isspace() too.
17:31.19CIA-133BRL-CAD: 03bob1961 * r46641 10/brlcad/trunk/src/tclscripts/lib/TkTable.tcl: Added a -singleSelectCallback option. If specified this essentially puts the table widget into a mode where only one row at a time can be selected.
17:35.03*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-185-071.wlan.tudelft.nl)
18:06.25CIA-133BRL-CAD: 03173.234.121.94 07http://brlcad.org * r3151 10/wiki/Haha_Spoil_her_reputation_81: New page: [[Image:reputation_management_1273.jpg|thumb|]] ya estamos listas pa salir al shows miados aki en Tijuana, agarrensen poke este pedo va a estar mamalon x 1 vez "las you you" !!!! NCBI ROF...
18:12.34CIA-133BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Haha Spoil her reputation 81]]"
18:12.45CIA-133BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.234.121.94]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
18:32.37*** join/#brlcad abhi2011_ (~chatzilla@wlan-145-94-185-071.wlan.tudelft.nl)
18:37.23brlcadso there are now a couple new wiki extensions installed
18:38.16brlcadone is a new blacklist extension that pulls the massive lists maintained by mediawiki and wikipedia folks (they are separate lists) that block posts that contain blacklisted url/content
18:39.06brlcadanother is a Q&A tension -- anyone care to suggest some good hard cad/math-related questions?
18:44.40*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:45.45n_reednot sure i understand the notion of a Q&A extension
18:45.56n_reedis the idea to post questions and answers
18:46.04n_reedor to get people to answer questions
18:47.12brlcadwe pose a question, they have to answer it correctly to modify the wiki
18:47.40brlcadlike "What is the name of this software?"  answer: BRL-CAD
18:48.21n_reedso like a captcha, but harder
18:49.14brlcadwhat is the square root of 1000-100?
18:49.15brlcadsure
18:50.25n_reedare you asking for suggesstions because you want to populate a list of options?
18:53.29brlcadthat is the idea
18:54.52n_reedi'll ask the obvious math person to send you some
18:56.15brlcadmere (CAD) mortals should be able to answer them
18:56.38brlcadI already have about 10, probably enough -- more just whether others wanted to add a couple
19:22.31CIA-133BRL-CAD: 0368.34.98.23 07http://brlcad.org * r3152 10/wiki/Testing_something_bogus: New page: This is a test.
19:23.26CIA-133BRL-CAD: 0368.34.98.23 07http://brlcad.org * r3153 10/wiki/Testing_something_bogus:
19:28.22starseekerphew - parallel distcheck
19:28.55CIA-133BRL-CAD: 03bob1961 * r46642 10/brlcad/trunk/ (11 files in 5 dirs): Added more editing support for pipes (i.e. append, prepend, delete, move, select and scale).
19:31.18starseekerre-enables the "make your life miserable" parts until he gets proper svn manifest checking working
19:40.42CIA-133BRL-CAD: 03bob1961 * r46643 10/brlcad/trunk/src/libged/Makefile.am: Added edpipe.c to libged/Makefile.am
19:41.02CIA-133BRL-CAD: 0368.34.98.23 07http://brlcad.org * r3154 10/wiki/Testing_something_bogus:
19:42.14CIA-133BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Testing something bogus]]": just testing
19:44.36brlcadso we'll see if that helps -- recaptcha is no longer enabled and logged in users still have no captcha
19:49.33starseekerbrlcad: nice, thanks!
19:52.40starseekerpwd
19:52.42starseekerwhoops
20:03.26starseekerhmm:  http://www.opencascade.org/about/news/issue173/
20:03.40starseekerwonders if that constitutes a glimmer of hope or not
20:05.49CIA-133BRL-CAD: 03starseeker * r46644 10/brlcad/trunk/CMakeLists.txt: turn back on the repo checks. distcheck will need to become its own CMake file I think - this is getting too complex for one custom target.
20:10.23brlcadprobably in response to OCE
20:11.15starseekeralmost certainly - question will be whether it's just words or if they actually change
20:11.33brlcadthey need to start with the license itself
20:11.37starseekerwould be awesome if they went LGPL
20:11.59brlcador better
20:13.32starseekerdunno how technically compatible we would be even if the license were ironed out, but they do have some bits we don't right now...
20:41.23brlcadand vice versa, but cleanly integrating pieces from two large codebases is arguably more work than implementing from scratch for each
20:41.54brlcadbetter to collaborate on the pieces that can be fully abstracted from both (like SCL)
20:42.19CIA-133BRL-CAD: 03r_weiss * r46645 10/brlcad/trunk/include/bn.h:
20:42.19CIA-133BRL-CAD: Updated include file 'bn.h' to enable the prototype versions of functions
20:42.19CIA-133BRL-CAD: bn_isect_lseg3_lseg3, bn_isect_line3_line3, and bn_isect_line_lseg and remove
20:42.19CIA-133BRL-CAD: the original versions. This change is the first of three. The remaining changes
20:42.19CIA-133BRL-CAD: will be to files 'plane.c' and 'nmg_tri.c'.
20:44.27CIA-133BRL-CAD: 03r_weiss * r46646 10/brlcad/trunk/src/libbn/plane.c: Updated file 'plane.c' to enable the prototype versions of functions bn_isect_lseg3_lseg3, bn_isect_line3_line3, and bn_isect_line_lseg. The original functions are removed.
20:47.28CIA-133BRL-CAD: 03r_weiss * r46647 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: Updated file 'nmg_tri.c' to change function calls from the prototype names of functions bn_isect_lseg3_lseg3, and bn_isect_line3_line3 back to their original names.
21:04.07brlcadhttp://vim.wikia.com/wiki/Remove_unwanted_spaces
21:04.07brlcadhttp://vim.wikia.com/wiki/Highlight_unwanted_spaces
21:04.23brlcadpossibly of interest to some of the vimragers in here
21:08.09CIA-133BRL-CAD: 03brlcad * r46648 10/brlcad/trunk/src/ (70 files in 70 dirs): ws consistency removing trailing ws and much more (see sh/ws.sh)
21:21.36CIA-133BRL-CAD: 03brlcad * r46649 10/brlcad/trunk/src/ (12 files in 12 dirs): more ws consistency cleanup
21:22.09brlcadstarts to see a pattern
21:33.21CIA-133BRL-CAD: 03bob1961 * r46650 10/brlcad/trunk/src/libged/edpipe.c: Collapse the functionality of ged_append_pipept() and ged_prepend_pipept() into _ged_append_pipept_common().
21:36.33CIA-133BRL-CAD: 03r_weiss * r46651 10/brlcad/trunk/src/librt/primitives/nmg/ (8 files): Updated files nmg_class.c, nmg_fuse.c, nmg_info.c, nmg_inter.c, nmg_mk.c, nmg_mod.c, nmg_rt_isect.c and nmg_tri.c to turn on the prototype triangulation code of nmg primitives.
21:38.48CIA-133BRL-CAD: 03bob1961 * r46652 10/brlcad/trunk/src/libtclcad/tclcad_obj.c:
21:38.48CIA-133BRL-CAD: Collapse the functionality of to_mouse_append_pipept() and
21:38.48CIA-133BRL-CAD: to_mouse_prepend_pipept() into to_mouse_append_pipept_common(). Added a call to
21:38.48CIA-133BRL-CAD: ged_snap_to_grid() in to_mouse_append_pipept_common for snap-to-grid behavior
21:38.48CIA-133BRL-CAD: when adding/inserting pipe points.
21:40.38CIA-133BRL-CAD: 03r_weiss * r46653 10/brlcad/trunk/include/raytrace.h: Updated raytrace.h to turn on the prototype triangulation of nmg primitives.
21:40.50brlcadr_weiss' change really begs for some thorough retesting with the conversion script
21:48.33CIA-133BRL-CAD: 03r_weiss * r46654 10/brlcad/trunk/src/librt/primitives/ars/ars.c: Updated ars.c to turn on changes which were disabled until the prototype version of nmg triangulation was enabled.
21:52.00CIA-133BRL-CAD: 03n_reed * r46655 10/brlcad/trunk/src/external/CMakeLists.txt: syntax error
21:59.04starseekerbrlcad: the pattern being my files having busted whitespace?
22:00.05starseekerhides
22:02.26starseekertried to set his editors to behave, really he did...
22:08.29starseekerwinces - did Richard see your source release announcement?
22:09.47starseekermakes a note to look into astyle sometime http://astyle.sourceforge.net/
22:35.12CIA-133BRL-CAD: 03r_weiss * r46656 10/brlcad/trunk/src/librt/primitives/tor/tor.c: Updated file tor.c to enable removing of zero length edges from torus primitives. This was disabled until the prototype nmg triangulation was made available.
23:09.00*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:45.57starseekerhuh - of course it's not quite the same since the tcl pkgIndex building macros aren't firing, but if I turn off docbook and compare:
23:46.50starseekermake:  7m8s, ninja: 6m13s to build all of BRL-CAD on my gentoo box
23:47.13starseeker(debug config)
IRC log for #brlcad on 20110910

IRC log for #brlcad on 20110910

01:00.16*** join/#brlcad ibot (~ibot@rikers.org)
01:00.17*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
01:23.04CIA-133BRL-CAD: 03brlcad * r46657 10/brlcad/trunk/sh/ws.sh:
01:23.04CIA-133BRL-CAD: wow, the 'e' case has been wrong from the get-go but only now seen with the
01:23.04CIA-133BRL-CAD: inadvertent modification of src/external/CMakeLists.txt where it removed the (0)
01:23.04CIA-133BRL-CAD: at the end of the file. this was due to using emacs-style quoting of the ()
01:23.04CIA-133BRL-CAD: parens instead of perl's unquoted style. fixed to the original intent of
01:23.05CIA-133BRL-CAD: ensuring that text files have a trailing newline.
01:23.57brlcadmisses the 2min enable-all compiles, that was a couple years of super high-productivity
01:24.35brlcadchanges how you code when you can turn a build around in less than 3min, about as drastic as 3sec builds do for test code
01:38.54CIA-133BRL-CAD: 03brlcad * r46658 10/brlcad/trunk/sh/ws.sh: the $ anchor matches a newline at end of file, so use the \z metasymbol instead to match the true end of string, which with 0777 should be the EOF.
02:02.42CIA-133BRL-CAD: 03brlcad * r46659 10/brlcad/trunk/ (22 files in 18 dirs): more ws consistency, trailing ws elimination, and such.
03:19.41starseekerbrlcad: the difference may be more pronounced on a non-gentoo box
03:20.13starseekeron this machine I'd get >50% of that time is straight up C/C++ compilation
03:20.25starseekers/get/guess
03:44.26starseekernot sure how to benchmark that, come to think of it...
04:13.21starseekerbrlcad: has the svn entries format changed?  I don't see any name= strings in mine here...
06:19.29brlcadit's the same here, but certainly possible .. the files are listed there somewhere, though
06:19.38brlcadalternative to searching the files is to ask svn directly
06:19.40brlcadsvn info -R | grep Path | awk '{print $2}'
11:17.25*** join/#brlcad kunigami (~kunigami@201.82.92.180)
13:08.34CIA-133BRL-CAD: 03starseeker * r46660 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: Not functional yet, but start working on logic to snarf file lists from svn info and do something intelligent with them.
14:09.22brlcadnice
14:15.41starseekerwill be even nicer when I figure out how to manipulate it right - it's Not Doing What I Want right now :-P
14:15.55starseekerstill, I think the proof of concept is there
14:16.32starseekerI take it the key operation is to compare the results of the expanded tarball archive with the subversion manifests?
14:17.17starseeker(we don't really care about the original source archive except insofar as detecting modified files disqualifies the tarball from "distribution ready status"?)
17:47.15*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096600997.dsl.bell.ca)
18:03.28*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
22:12.27*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
23:03.08*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
23:17.38*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
23:23.46*** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862)
IRC log for #brlcad on 20110911

IRC log for #brlcad on 20110911

02:11.00*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:14.06starseekeryay, couches are in
02:49.35*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
02:49.44yukonbobhello, #brlcad
03:48.05*** join/#brlcad yukonbob (~bch@S010600235a187d92.ok.shawcable.net)
03:56.02*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
03:56.11*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
08:16.46*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
11:09.55*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:27.39*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:12.11kunigamihm, I'm getting the following error with mged after a clean build: http://paste.ubuntu.com/686851/ (mac os)
13:20.16CIA-133BRL-CAD: 03Kunigami 07http://brlcad.org * r3155 10/wiki/User:Kunigami: updated profile
13:22.14CIA-133BRL-CAD: 03Kunigami 07http://brlcad.org * r3156 10/wiki/User:Kunigami: added more information
13:58.05*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
15:02.35starseekerkunigami: can you get a gdb backtrace?
15:09.15*** join/#brlcad piksi (piksi@pi-xi.net)
15:13.59kunigamistarseeker: seems a tcl/tk issue: http://paste.ubuntu.com/686945/
15:15.06starseekererum
15:15.23starseekerapparently it doesn't like your freetype
15:15.31starseekeriirc it was finding a freetype in opt?
15:15.46starseekerdo you have one in the "normal" system install for Mac?
15:18.12kunigamistarseeker: yup, I have one at /usr/X11/lib
15:18.37starseekerif you could, edit your CMakeCache.txt file result pertaining to freetype to point to the one in /usr
15:19.01starseekerFREETYPE_LIBRARY in particular
15:19.04``Erikif linking gets both /opt/local and /usr/X11, there might be symbol issues between the two
15:19.34starseekerhad to jump through hoops for X11 and OpenGL, looks like freetype needs to get added to the mix
15:19.43starseekeryargh
15:19.44``Erikstarseeker needs to figure out how to convince cmake to ONLY use /opt/local if those exists O.o :)
15:20.05starseekerkunigami: then just run "make" again - cmake will rerun itself
15:20.16starseeker<snort>
15:20.31starseekerusually go for the system versions
15:21.08``Erikpersonally, I'd favor the macports or fink variants... they tend to be a lot more recent and less ... 'adjusted'
15:21.42starseekerif I REALLY wanted to get fancy I could try detecting macports/fink installations and then making a sort of global "Use System/MacPorts/Fink" versions of things
15:22.09``ErikI think the auto* stuff had exactly that
15:23.11starseekerwhat's a good way to reliably detect macports and/or fink?
15:23.28``Erikaaaanyways, it's sunday morning, I spent yesterday dragging my sick arse around the rennfest, and I believe my sick arse is going to the botanical gardens O.o
15:23.38starseekeruh oh
15:23.48``Erikum, I believe both have a program called "port"
15:24.02``Erika tcl variant of the fbsd ports or gentoo portage
15:24.10``Erikyes, it really is that sick.
15:24.53starseekerkunigami: you're using macports you said?
15:25.02kunigamistarseeker: yup
15:25.09starseeker``Erik: hey, gentoo is copying freebsd more or less :-P
15:25.44``Erikquite aware, I believe my first port commit to fbsd was 2001... :)
15:25.47starseekerkunigami: is the "port" command in your normal system path?
15:26.05``Erikno, it's in the macports dir
15:26.11kunigamistarseeker: yes
15:26.23``Erikmacports will attempt to adjust your $PATH in your .bashrc for you
15:26.30starseeker``Erik: so to freebsd folk gentoo is like some sick distorition from a horror movie in the mirror? :-P
15:26.53starseekerkunigami: does your ports command tell you if it's a macports or fink port?
15:26.59``Erikmore like a little kid jumping up and down and saying "me too!"
15:27.06starseeker(e.g. port -v or port --some-option?)
15:27.28``Erik$port -v
15:27.33``ErikMacPorts 2.0.99
15:27.37kunigamistarseeker: it tells me "MacPorts 2.0.1"
15:27.39starseekerawesome
15:27.57starseekerdoes it happen to tell you where macports is installed?
15:28.07starseekeror is the path to the port binary a reliable indicator?
15:28.48``Erikfink uses /sw/, macports uses /opt/local
15:29.04starseekerconsistently?
15:29.11starseekeror can users change the install local?
15:29.15``Erikglenns did something stupid and work macs use /usr/local/macports or something stupid like that
15:30.05starseekernods - so I'd like to key off the location of port if possible
15:30.15starseekerand then use port -v to identify fink vs macports
15:30.22``Erik99.99% of users will be either /sw for fink or /opt/local for macports
15:30.40starseekerso /sw/bin/port for fink?
15:31.05kunigamistarseeker: my ports seems to be in /opt/local too. don't know how to get this information from port itseilf
15:31.21``ErikI think, it's been a bazillion years since I've used fink
15:31.22starseekeris assuming some folks will have both fink and macports at the same time, so will have to sort that out (when possible)
15:31.37``Erikman 3 read
15:31.40starseekerkunigami: as long as port is located in /opt/local/bin we should be good
15:31.44``Eriker, wait, 1? hrm
15:32.00``Erikthere's a bash read command, might be usefull... "I cn't guess, tell me"
15:32.46starseekerfind_program(PORT_BIN port) should do the trick and give me the full path to port
15:33.07starseekerthen I'll run port -v (hopefully the fink version supports that too) and snarf macports or fink out of the result
15:33.39starseekerthen do a little path surgery and either enforce or ignore searching in sw or opt/local or whatever (that'll be the trickest bit, probably)
15:34.13starseekerthen I can revert a lot of the changes I made to the FindX11 and FindGL cmake scripts, which would be a Good Thing
15:35.24``Eriklater tonight, I'll look at my ancient g3 ibook and see if it's fink only and how to detect that... otherwise, everything I have is all mac ports, srry
15:35.35starseekerno biggie
15:35.59``Erika dmg with a self contained .app is what most mac users will expect *shrug*
15:36.22starseekerI just have to figure out how to exclusivly search for stuff only system or first macports then sytem (ignoring fink if there) or first fink then system (ignoring macports if there)
15:36.26starseekerblegh
15:36.51starseekernods - but for people doing devel on Mac, the fink and macports installs are a Common Problem
15:37.03starseekerwhich means we really should handle it Right if it can be handled Right
15:38.30starseekerkunigami: you might end up having to play guinea pig to test some detection logic - I don't have a macports mac handy ;-)
15:38.49starseekerprobably won't be today though
15:38.54starseekermore house stuff to do
15:39.04kunigamino problem :)
15:39.25starseekerkunigami: in the meantime, does setting the freetype to your system version work?
15:39.59kunigamistarseeker: nope :( I just edited the path for libfontconfig and I'm compiling again
15:41.11starseekerabsolute worst case we may have to look at what the TEA tcl/tk build is doing for that system - it's always possible the CMake logic missed a trick
15:41.58starseeker(the autotools build just got fixed thanks mostly to ``Erik and brlcad, so it should be viable to try that as well to see if it works)
15:46.06kunigamistarseeker: changing both libfontconfig and libfreetype paths did the trick. Thanks!
16:22.53*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
16:26.31kunigamiIs there any simple scene where I can apply osl shaders? (besides cornell). All files I'm opening have tons of regions :(
17:07.28*** join/#brlcad kunigami (~kunigami@201.82.92.180)
17:18.55*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
18:31.06``Erikmossworld.g ?
22:45.52*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
IRC log for #brlcad on 20110912

IRC log for #brlcad on 20110912

04:59.57brlcadautotools had no fink/macports-specific logic -- it was attempted very early on but was quickly completely removed because of all the problems it caused
05:04.08brlcadkunigami1: a real scene would make the best demo .. the complexity of the model shouldn't matter
05:04.39brlcadit's pretty easy to change the shader on all objects in a hierarchy
05:04.52brlcador apply a new shader to a top-level and have it override everything below
07:37.49*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
09:58.18*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
10:14.08*** join/#brlcad kunigami (~kunigami@201.82.92.180)
11:17.34*** join/#brlcad kunigami (~kunigami@201.82.92.180)
13:08.18*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:39.27*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
14:24.05*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
14:55.42*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
15:16.58CIA-133BRL-CAD: 03r_weiss * r46661 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: Updated file nmg_tri.c to quiet compiler warnings.
16:36.51*** join/#brlcad merzo (~merzo@72-107-132-95.pool.ukrtel.net)
17:51.09*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
18:19.26CIA-133BRL-CAD: 03starseeker * r46662 10/brlcad/trunk/ (10 files in 8 dirs): Still experimental, but make a stab at being able to enable/disable fink and macports on Macs.
18:29.14CIA-133BRL-CAD: 03starseeker * r46663 10/brlcad/trunk/misc/CMake/Fink_MacPorts.cmake: remove debugging print statements
19:24.56*** join/#brlcad alex_joni (~alex_joni@81.196.65.201)
19:24.57*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
19:36.01abhi2011hmm, I have been trying to provide the proper paramters to ged_mater() to get an object autmatically shaded
19:36.15abhi2011but it seems ged_mater() is no longer used for the mater commands
19:36.26abhi2011it seems to be going to ged_glob() now
19:37.22brlcadged_glob does glob name expansion, so *.tgc will expand to "asdf.tgc foo.tgc"
19:38.39abhi2011ok
19:39.52abhi2011hmm but after that, in cmd_ged_plain_wrapper(), it should call get_mater()
19:40.26abhi2011hmm no its probably called from a different place
19:40.59abhi2011i was trying to set a break point in the ged_mater() function to see what paramters gets passed
19:41.14abhi2011but control never seems to land there
19:43.50abhi2011thought I could shade objects to any color by simply calling ged_mater() with the proper parameters
20:01.49abhi2011yup best to use avs and librt directly
20:09.43*** join/#brlcad Stattrav (~Stattrav@203.196.190.162)
20:10.02*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
20:11.19brlcadabhi2011: not all commands in mged are hooked into libged yet -- archer uses libged exclusively
20:14.34brlcadyou have to look at the command binding table in mged (setup.c) to see what actually gets called
20:15.45brlcadthat said, setup.c does list ged_mater() for 'mater', so you inability to set a breakpoint is probably a different problem
21:10.16*** join/#brlcad merzo (~merzo@60-98-133-95.pool.ukrtel.net)
21:22.38abhi2011ok got the color in now for showing the object state with respect to physics
21:23.08abhi2011colors are different now for idle, active and sleeping states...purely for debugging later on
21:23.31abhi2011now looking to draw  the bounding box for each object as reported by bullet
21:24.21abhi2011so looking for a single command that lets me make a nearly transparent arb8 , with some light color and with the vertices i specifiy
22:08.04*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
22:25.23*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
22:54.45*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
23:07.59brlcadabhi2011: mk_arb8() or mk_rpp() will make a box, mk_comb() to make a combination -- there you can specify a mater string and color
23:09.41*** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br)
IRC log for #brlcad on 20110913

IRC log for #brlcad on 20110913

00:02.13*** join/#brlcad piksi (piksi@pi-xi.net)
00:16.47*** join/#brlcad piksi (piksi@pi-xi.net)
00:18.53*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
01:11.43*** join/#brlcad ``Erik_ (Here@c-69-140-109-104.hsd1.md.comcast.net)
02:57.51CIA-133BRL-CAD: 03starseeker * r46664 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in:
02:57.51CIA-133BRL-CAD: Total rework of distcheck. Not 'hooked up' but it can spot disagreements
02:57.51CIA-133BRL-CAD: between build logic and svn info results. Main problem right now is diffing the
02:57.51CIA-133BRL-CAD: two generated text files - CMake is hideously slow at what should be a quick,
02:57.51CIA-133BRL-CAD: easy task. May need to provide minimalist diff utility for this to work
02:57.52CIA-133BRL-CAD: acceptably performance wise, but it does appear that it will work.
03:11.14CIA-133BRL-CAD: 03starseeker * r46665 10/brlcad/trunk/ (97 files in 97 dirs): Closing in on svn-ified distcheck for CMake, if performance issues can be addressed.
03:17.18*** join/#brlcad DarkCalff (DC@173.231.40.98)
04:23.30CIA-133BRL-CAD: 03starseeker * r46666 10/brlcad/trunk/ (doc/CMakeLists.txt src/librtserver/CMakeLists.txt): Couple more CMakeLists.txt tweaks
04:54.58CIA-133BRL-CAD: 03brlcad * r46667 10/brlcad/trunk/include/ (config_win.h config_win_cmake.h.in):
04:54.58CIA-133BRL-CAD: add compatibility macros for S_ISDIR(), S_ISREG(), and S_ISLNK(). for the first
04:54.58CIA-133BRL-CAD: two, the existing S_IF* defines are sufficient, but we punt for symbolink links.
04:54.58CIA-133BRL-CAD: could maybe do something for 'shortcuts' but it would probably be the suck.
04:56.36CIA-133BRL-CAD: 03brlcad * r46668 10/brlcad/trunk/include/bu.h: add a declaration for a new bu_file_directory() function that returns truthfully whether a given filepath is one. add a note that bu_file_delete() tries really really hard to delete the file.
04:59.30CIA-133BRL-CAD: 03brlcad * r46669 10/brlcad/trunk/include/bu.h: add bu_file_symoblic() while we're at it for api-completeness.
05:01.33CIA-133BRL-CAD: 03brlcad * r46670 10/brlcad/trunk/src/libbu/file.c: add initial implementations for bu_file_directory() and bu_file_symbolic()
05:52.12CIA-133BRL-CAD: 03starseeker * r46671 10/brlcad/trunk/misc/ (CMake/distcheck_buildsys.cmake.in CMakeLists.txt comm.c):
05:52.13CIA-133BRL-CAD: Not entirely clear if we can keep CMake's notions of sorting compatible with
05:52.13CIA-133BRL-CAD: comm's, but in some early testing this seems to work - a little libbu-ification
05:52.13CIA-133BRL-CAD: of netbsd's comm code (very simple if we can get away with it) and presto,
05:52.13CIA-133BRL-CAD: distcheck is failing (correctly) in reasonable time.
07:34.54*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:42.00CIA-133BRL-CAD: 03173.208.18.213 07http://brlcad.org * r3157 10/wiki/Ahahahahaha_What_reputation_Quiet_you_11: New page: [[Image:reputation_management_3486.jpg|thumb|]] Bulgarian Exports to European Union Soar [] TourDeFrance starts today! Will it be the same without ? Get on your bike here - One step ahead...
09:39.01*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
11:11.35*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
11:39.47*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
12:19.02CIA-133BRL-CAD: 03erikgreenwald * r46672 10/brlcad/trunk/misc/CMakeLists.txt: add TCL_INCLUDE_DIRS to satisfy the use of bu.h
12:19.25CIA-133BRL-CAD: 03tbrowder2 * r46673 10/brlcad/trunk/doc/docbook/books/README: correct typo
12:27.09CIA-133BRL-CAD: 03tbrowder2 * r46674 10/brlcad/trunk/doc/docbook/resources/standard/xsl/README: correct typos
12:28.02CIA-133BRL-CAD: 03tbrowder2 * r46675 10/brlcad/trunk/doc/docbook/resources/standard/xsl/highlighting/README: correct typo
12:44.33*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:16.21CIA-133BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:173.208.18.213]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
13:16.21CIA-133BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Ahahahahaha What reputation Quiet you 11]]": spam
13:34.33CIA-133BRL-CAD: 03brlcad * r46676 10/brlcad/trunk/src/libbu/malloc.c: if the caller passes a NULL string value, don't rely on libc to do something reasonable with it. turn it into '(null)' for the debug printing (which is what most libc impls do now anyways).
14:28.31*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
14:56.07*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
14:56.12yukonbobhello #brlcad
15:18.37brlcadhello
15:56.37*** join/#brlcad plaes (~plaes@gn237.zone.eu)
15:57.28jordisayolbrlcad: what about the new 7.20.4 source release?
16:43.43brlcadjordisayol: yeah, got distracted with some other coding
18:12.27CIA-133BRL-CAD: 03erikgreenwald * r46677 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: s/static/HIDDEN/
20:41.09CIA-133BRL-CAD: 03starseeker * r46678 10/brlcad/trunk/doc/docbook/Makefile.am: Sort the files for EXTRA_DIST docbook
21:37.16*** join/#brlcad merzo (~merzo@100-177-133-95.pool.ukrtel.net)
23:15.44abhi2011trying to get a glass shader to work
23:15.47abhi2011shader gp.r "glass {tr 0.8 re 0.7}" 0 0 255
23:15.59abhi2011but mged refusing to accept it
IRC log for #brlcad on 20110914

IRC log for #brlcad on 20110914

00:04.01*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
00:04.49brlcadmm e-mail troll
00:35.44*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
00:51.23abhi2011brlcad , is there a way to change the rt resolution from the default 512 by 512
00:56.24abhi2011ok got it
00:56.28abhi2011the -s option
01:00.14abhi2011hmm trying with -s1024, seems like have to leave the rendering job overnight :P
01:10.42CIA-133BRL-CAD: 03abhi2011 * r46679 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): Added code to simulate command for showing bounding boxes and rigid body activation state
01:24.01CIA-133BRL-CAD: 03starseeker * r46680 10/brlcad/trunk/ (6 files in 4 dirs): More distcheck progress, although there's still at least one bug to iron out.
03:17.59brlcadabhi2011: the number of pixels increases quadratically as you increase the image size
03:18.27brlcadso going from 512x512 to 1024x1024 is a 4x increase in the number of pixels being rendered
03:21.08brlcadusually better to get your scene set up exactly how you want it at 256x256 or similar without materials for a quick preview, then render high at some much higher resolution (I tend to like 4096x4096 with jitter and hypersampling) with materials and custom light sources
03:21.37brlcadbut then those usually beg for some quick distributed rendering with lots of computers :)
03:27.44*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
05:18.45*** join/#brlcad ibot (~ibot@rikers.org)
05:18.45*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
11:38.52CIA-133BRL-CAD: 03starseeker * r46681 10/brlcad/trunk/src/libged/simulate/simulate.c: comment out rv until it's actually used, breaks strict building as the code currently stands.
12:00.34CIA-133BRL-CAD: 03starseeker * r46682 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): fix paths that are appended to cmakefiles.cmake and cmakedirs.cmake
12:25.03*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:56.07CIA-133BRL-CAD: 03tbrowder2 * r46683 10/brlcad/trunk/doc/docbook/Makefile.am: correct XSLTPROC options; add new document to tree
13:17.26CIA-133BRL-CAD: 03starseeker * r46684 10/brlcad/trunk/ (28 files in 5 dirs): (log message trimmed)
13:17.26CIA-133BRL-CAD: Variety of distcheck fixes, including a nifty problem where a directory named
13:17.26CIA-133BRL-CAD: 'off' was causing a logic failure in the path building logic. dist files are
13:17.26CIA-133BRL-CAD: now actual cmake files that are included - this allows CMake to re-run after one
13:17.26CIA-133BRL-CAD: is edited, which is the correct behavior. directories that are specified (as
13:17.27CIA-133BRL-CAD: opposed to recognized as parents of files specfied) use svn info to build the
13:17.28CIA-133BRL-CAD: list of files below the ignored directory, which means temporary files should be
13:41.14CIA-133BRL-CAD: 03tbrowder2 * r46685 10/brlcad/trunk/doc/docbook/presentations/ (13 files in 3 dirs): new document added to tree
14:08.24CIA-133BRL-CAD: 03brlcad * r46686 10/brlcad/trunk/doc/docbook/Makefile.am: fully sort the list
14:08.56CIA-133BRL-CAD: 03Tbrowder 07http://brlcad.org * r3158 10/wiki/FAQ: add a new bit of trivia from the old-timers
14:17.39CIA-133BRL-CAD: 03starseeker * r46687 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in:
14:17.39CIA-133BRL-CAD: OK. First rule if building a dist tarball from a tarball or other non-svn
14:17.39CIA-133BRL-CAD: checkout source, don't. CPack has no way of knowing what to exclude in the
14:17.39CIA-133BRL-CAD: fully ignored sub-directories. If you must, distcheck will do what it can where
14:17.39CIA-133BRL-CAD: it can to spot files that don't belong, and warn you of your peril.
14:20.59CIA-133BRL-CAD: 03Tbrowder 07http://brlcad.org * r3159 10/wiki/SVN: add link to some more SVN info
14:27.42CIA-133BRL-CAD: 03Tbrowder 07http://brlcad.org * r3160 10/wiki/SVN:
14:29.52CIA-133BRL-CAD: 03Tbrowder 07http://brlcad.org * r3161 10/wiki/SVN: add link to more svn info
14:50.24CIA-133BRL-CAD: 03starseeker * r46688 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in:
14:50.24CIA-133BRL-CAD: Be nice to the users, if the ignored file count gets too large refer them to a
14:50.24CIA-133BRL-CAD: file instead of dumping thousands of lines to the terminal. Need to do
14:50.24CIA-133BRL-CAD: something more intelligent for in-src distcheck building, which is what prompted
14:50.24CIA-133BRL-CAD: the change, but might as well handle this for cases with lots of stray files
14:50.25CIA-133BRL-CAD: too.
14:56.06*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:07.45CIA-133BRL-CAD: 03Abhi2011 07http://brlcad.org * r3162 10/wiki/User:Abhijit: /* Log */
15:16.21CIA-133BRL-CAD: 03Abhi2011 07http://brlcad.org * r3163 10/wiki/User:Abhijit: /* Development timeline */
15:32.20CIA-133BRL-CAD: 03tbrowder2 * r46689 10/brlcad/trunk/doc/docbook/Makefile.am: more file name sorting
16:16.37brlcadinteresting, http://www.cs.washington.edu/research/constraints/cassowary/
16:32.02brlcadsecondary lead if spirit work ever hits a roadblock
16:51.07CIA-133BRL-CAD: 03tbrowder2 * r46690 10/brlcad/trunk/doc/docbook/README: added blub on new presentations directory
16:52.50CIA-133BRL-CAD: 03tbrowder2 * r46691 10/brlcad/trunk/doc/docbook/ (Makefile.am system/man1/en/Makefile.am): renamed build variable to better track file tree name
16:53.13*** join/#brlcad Stattrav (~Stattrav@61.12.114.82)
16:53.13*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
16:55.36starseekerbrlcad: does it do floating point?
16:56.45starseekerah, I think I've run across that before
16:57.29starseekerthat also needs GTL: http://www.fim.uni-passau.de/en/fim/faculty/chairs/theoretische-informatik/projects.html
16:58.53starseekerO.o am I seeing that right, Apple is using it?
17:00.48starseekerperhaps I underestimated it
17:05.19starseekerlooks like it also wants guile
17:29.58brlcadnods
17:30.29brlcadit's also dead/unsupported along with GTL, but an interesting lib nonetheless
17:31.24brlcadi'd be a little surprised if guile was actually required
17:31.30brlcadthere's lots of bindings to various languages, I suspect that's where it's used
17:35.04starseekernods - yeah, most of it looks like demos
17:35.21starseekerprobably not too hard to get the interesting subset building
17:35.57starseekernifty:  http://www.badros.com/greg/cassowary/js/quaddemo.html
17:36.55starseekeris quite intrigued by Apple's use
17:43.53starseekerdoesn't see any code from Apple on the cassowary site... wonder if they just used it as-is?
17:44.02starseekerwould be surprising for code that old
17:46.34starseekerbrlcad: was that the academic library you were thinking of?
17:47.26starseekervaguely remembers getting as far as determining it needed GTL and that GTL still exists before, but I didn't follow up since gecode looked more modern and maintained
17:48.20starseekerwasn't fully aware of gecode's lack of floating point solver support at the time
18:00.26brlcadstarseeker: it might have been, don't remember for certain
18:01.14starseekerwill play with it later - struggling to convince CPack not to include build files in its tarballs
18:01.18brlcadstill, greener pastures and all -- it's just a good thought to keep in mind's back pocket, maybe wire up to the libpc test cases to see how it does
18:01.51starseekermay have to at least require a subdirectory within the source tree - the source=build case is a nightmare
18:02.12brlcadnightmare in what sense?
18:02.37starseekerI have to tell CPack to exclude files, but the simple act of RUNNING cpack within the build tree creates more files
18:03.07starseekerwhich I can't list for CPack because they don't exist ahead of time
18:03.22brlcadyou mean for distcheck?
18:03.24starseekeryeah
18:04.05brlcadif it's *only* for distchecking, not a big deal -- or even let cpack pack them, it'll just warn on them down the line
18:04.33starseekeras long as it's smart enough to not be recursive, I guess...
18:04.34brlcadin practice for proper dist building, it can be out of dir no worries
18:05.11brlcadin source build support is really only needed to support simple compilation/install
18:05.30brlcaddistchecking is "in-house stuff, in-house rules"
18:05.54starseekerI thought one of the points though was to verify the tarball had everything we wanted it to
18:06.01brlcadsure
18:06.13starseeker(admittedly that works a little different now, with that verification happening up front, sorta...)
18:06.35brlcadso it has too much if someone built in-dir and ran distcheck, but it could warn and still run all the tests
18:07.03starseekernods... true
18:07.28brlcadchecking the tarball is only half the picture, and the lesser-utilized half at that
18:07.41brlcadthe other half of the distcheck is all the testing
18:07.54brlcadthat is desirable to run and re-run as often as possible
18:08.16brlcadso is distcheck ready to go now?
18:08.26brlcadI'm going through commits now to see if everything is documented
18:08.43starseekerclose, but I wouldn't consider it properly hooked in yet
18:10.31CIA-133BRL-CAD: 03brlcad * r46692 10/brlcad/trunk/NEWS: tom converted traNese's intro to Tcl/Tk presentation into the docbook format. that means it'll get installed in html form (and potentially as pdf).
18:10.42brlcadclose enough for me to distcheck a source release tarball? :)
18:10.55starseekerurm.  from out of dir build, maybe
18:11.13brlcadwas hoping for better than maybe :D
18:11.32starseekerbrlcad: I've totally rewritten it twice in the last two days :-P
18:11.36*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
18:11.38starseekerit's hard to be definitive just yet
18:11.41brlcadI know, that's why I'm asking
18:12.47brlcadabhi2011: how's that render coming along?
18:13.06brlcadwants to set up his own scene here real soon now...
18:24.29jordisayolbrlcad: I see that "sh/make-deb.sh" was modified by tbrowder2
18:25.28jordisayolbrlcad: is there some problem with my maintenance?
18:25.44piksiare there screenshots or feature lists of the current archer ui?
18:26.29CIA-133BRL-CAD: 03brlcad * r46693 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: if the code added to quiet compiler warnings has to also be quieted (with #if 0), then it should just be removed...
18:30.18starseekerpiksi: this is fairly current:  http://bzflag.bz/~starseeker/archer_win32_native_built_docs.png
18:30.58starseekerthis is still fairly close appearance wise:  http://bzflag.bz/~starseeker/archer_latest.png
18:31.41brlcadjordisayol: not at all, at least not that I'm aware of -- were the changes significant/controversial?
18:31.55brlcadI think he was just trying to help
18:32.29brlcadtom's a relatively new committer, communicates via mailing list
18:32.49jordisayolbrlcad: I'm just checking, it appear that only added a "test dependency only" ability
18:33.55jordisayolbrlcad: is just to know if I have to continue to build new deb/rpm packages
18:33.59piksistarseeker: thanks. last time i tried modeling something with MGED i found it extremely cumbersome compared to e.g. current versions of autocad or autodesk revit. archer ui looks pretty much like autocad circa 2004. what kind of an ui philosophy is being used with archer?
18:34.12brlcadjordisayol: oh, please! :)
18:34.46brlcadyou don't "have to" but it's greatly helpful and appreciated (as seen by the loads and loads of downloads)
18:35.13starseekerpiksi: um.  "make it not suck?"  not sure what you mean by a ui philosophy
18:35.30piksijordisayol is responsible for rpm packaging?
18:35.40jordisayolbrlcad: no no, it's ok. i just want to know
18:35.45piksithen i have to thank you, i was pleasantly surprised to find a fedora package for my system :-)
18:36.12jordisayolpiksi: i do my best, and yes i buils rpm packages
18:36.18jordisayolbuild*
18:36.45jordisayolpiksi: is there some problem with them?
18:36.54brlcadpiksi: my goal is towards a completely modeless redesigned ui but we're not going to get there in one jump
18:37.18piksijordisayol: no, i was just very happy that there was an rpm and i didn't have to compile :-)
18:37.33jordisayolpiksi: ;-)
18:37.36piksistarseeker: ui philosophy, i.e. all tools working in a consistent manner, designing the tools from the viewpoint of a designer (for example having good 3d snapping capabilities, versatile extruding/lofting/revolving tools etc)
18:37.50brlcadarcher is already a huge stepping stone as it is, even if it just brings us into the 90's ;) .. to do more would increase risk of delays (or outright failure)
18:39.26piksibrlcad: if by mode you mean the command line type interface of autocad, i find it extremely fast compared to many of the recent autodesk ui changes that move towards clicking (without being "in a command state")
18:39.43brlcada lot of the nifty UI features you mention require extensive backend support, too -- which has little if anything to do with the overarching ui design
18:39.57jordisayolbrlcad: as a main developer, can You tell tbrowder2 to communicate me just ins deb/rpm modifications? just for a better building result
18:40.22brlcadpiksi: that is not what is meant by mode, http://en.wikipedia.org/wiki/Mode_(computer_interface)
18:40.25piksibrlcad: yes, i understand that the ui features i'm longing for require an *extensive* framework which is not easy to do at all
18:41.11piksibrlcad: ah now i understood. yes, that is a good thing to avoid
18:41.17brlcadjordisayol: hm? didn't understand the "just ins"
18:42.02brlcadjordisayol: if you see something undesirable, you can revert it from the deb/rpm files -- that merely begs a dev-dev discussion
18:42.04jordisayolbrlcad: sorry, is a typo. just for files directly involved in deb/rpm building packages
18:42.37piksibrlcad: is any kind of an input/suggestions/feature requests for the upcoming ui features needed or accepted from users? my background is in architecture but i've used brl from time to time to model csg-stuff instead of autocad
18:43.01jordisayolwell, I've modified "sh/make_debsh" to disable source build, and now i find this modification, that's all
18:43.05brlcadfwiw, a commit effectively is a means of communication -- and one that's guaranteed to reach everyone
18:43.22brlcadotherwise it's a bit tricky with him on the mailing list and you on irc -- the discussions shouldn't be in private
18:44.23starseekerbrlcad: yep, though so - new docbook stuff sets off cmake distcheck
18:44.26starseekerone sec...
18:45.28jordisayolbrlcad: ok
18:47.00brlcadpiksi: input/suggestions/feature requests are always welcome but with heeded caution that we've probably heard/thought of it too (we have a TODO list that probably represents a 1000-staff years of effort and that still wouldn't get us all the features of the "big five")
18:47.11piksi:-)
18:47.44piksibrlcad: yeah i wasn't expecting to introduce anything groundbreaking in terms of design. is the todo list public?
18:47.55brlcadpiksi: more constructive is the suggestions that have real productive effort tied to them -- like coming up with a detailed use case or a real prototype mock up
18:48.07piksiyeah i always try to provide mockups
18:49.25brlcadeven better is to relate it to the current state of the software, like looking at MGED or Archer's horrid menu hierarchy and detailing exactly what a new/better hierarchy would look like, etc
18:50.09brlcadas for the 3rd generation interface, a good bit of mock-up design effort has already happened (in a non-CAD/agnostic way to help with the underlying usability concepts)
18:51.58brlcadone prototype video is here: http://brlcad.org/design/gui/
18:52.17CIA-133BRL-CAD: 03starseeker * r46694 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/distcheck_buildsys.cmake.in):
18:52.17CIA-133BRL-CAD: Deduce the in-source build directory rather than hardcode one devs typical
18:52.17CIA-133BRL-CAD: defaults. Have the distcheck routine use the variable as well to clean up its
18:52.17CIA-133BRL-CAD: output. Looks like this is helpful, but not clear yet if it is a full solution.
18:53.03brlcadjordisayol: to reiterate, if he modified one of the scripts your using and it affects your ability to prepare a release, there is ABSOLUTELY no problem reverting that change
18:53.30brlcadif it doesn't affect what you're doing or can be accommodated, then great .. just ignore it or accommodate or ask him to make it optional or whatever works ;)
18:53.52brlcadif you reply to the commit e-mail, it'll go to the brlcad-devel mailing list and reach him
18:54.26jordisayolbrlcad: well,the only two files out of /misc/debian dir that I modified are make_deb.sh and make_rpm.sh
18:54.42jordisayolbrlcad: and he modified make_deb.sh
18:55.01starseekerjordisayol: the changes conflict?
18:55.33jordisayolis not a bit modification, just added a new option to just test is dependencies are present in system and exit
18:55.51jordisayolis => if
18:56.14brlcadmodifications are to be expected anywhere in the source tree, part of collaborative development
18:56.42brlcadwhat's really cool is having three devs all working in the same file at the same time, frequently updating, and just seeing the code flow :)
18:57.00brlcadi've only seen it a couple times in my career, but it's a thing of beauty :D
18:57.29brlcadhyperproductivity!
18:58.19CIA-133BRL-CAD: 03starseeker * r46695 10/brlcad/trunk/doc/docbook/ (3 files in 3 dirs): Fix up the presentations CMakeLists.txt logic
18:59.04jordisayolbrlcad: I apologize, I was surprised for this modification, that's all
18:59.28starseekerjordisayol: generally, that's a good thing - it means people are taking an interest in your work :-)
19:00.26jordisayolbrlcad: yes, shure, but it can means to that i'm not doing it so good too :-)
19:01.54brlcadit didn't even occur to me to think that it meant you were doing something so good :)
19:02.59brlcadwhat starseeker said, just someone else taking an interest in the scripts, in what you'd done .. that's usually a "really good" thing
19:03.57jordisayolbrlcad: You and starseeker have a couple of beers payed ;-)
19:05.37starseekerbrlcad actually went to some trouble to remove individual authorship entries from the various source files and instead record them in the AUTHORS file - we don't want to wind up with a situation where people don't want to touch code because "it's somebody else's"
19:06.53starseekerso no worries - we're all trying to Make Things Better :-)
19:08.46CIA-133BRL-CAD: 03brlcad * r46696 10/brlcad/trunk/NEWS: bob has initial support in for editing pipe primitives within archer. support for appending, prepending, deleting, moving, selecting, and scaling.
19:13.23CIA-133BRL-CAD: 03starseeker * r46697 10/brlcad/trunk/CMakeLists.txt:
19:13.23CIA-133BRL-CAD: Be sure we don't do anything in the case where the build and the source
19:13.23CIA-133BRL-CAD: directories are the same directory - unless I'm missing some CPack option or
19:13.23CIA-133BRL-CAD: feature (possible) that case is just not going to mix well with CPack's approach
19:13.23CIA-133BRL-CAD: to archive creation.
19:15.33starseekerbrlcad: cmake distcheck now succeeds
19:18.05CIA-133BRL-CAD: 03starseeker * r46698 10/brlcad/trunk/CMakeLists.txt: fix if location
19:25.59jordisayolbrlcad: there are some errors on tbrowder2 make_deb.sh modifications. He treat some packages names as executable files names, and this will cause the script failure
19:29.56piksibrlcad: thanks, i'll look into it
19:31.31brlcadpiksi: the TODO file in any source distribution contains several hundred items (some huge, some tiny)
19:31.48piksi:-)
19:32.30brlcadthe documentation section at the bottom is particularly ripe for getting involved in a useful way, but that extends to (unlisted) developer documents (aforementioned mockups etc) too
20:05.31*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
20:05.31*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
20:05.31*** join/#brlcad yiyus (1242712427@je.je.je)
20:05.31*** join/#brlcad kanzure (~kanzure@131.252.130.248)
20:05.31*** join/#brlcad piksi (piksi@pi-xi.net)
20:05.31*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
20:05.31*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
20:05.31*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
20:05.31*** join/#brlcad plaes (~plaes@gn237.zone.eu)
20:05.31*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
20:05.31*** join/#brlcad kunigami1 (~kunigami@loco-gw.ic.unicamp.br)
20:05.31*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
20:05.31*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
20:05.31*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
20:05.31*** join/#brlcad CIA-133 (~CIA@cia.atheme.org)
20:19.05*** join/#brlcad kanzure (~kanzure@131.252.130.248)
20:45.23CIA-133BRL-CAD: 03starseeker * r46699 10/brlcad/trunk/ (4 files in 2 dirs): Make a stab at consolidation of all distcheck logic into one file.
21:12.00CIA-133BRL-CAD: 03starseeker * r46700 10/brlcad/trunk/ (4 files in 2 dirs): Hmm. $(MAKE) isn't working as expected in EXECUTE_PROCESS - revert the one file solution.
21:14.18starseekeroh, duh - right, $(MAKE) is specific to make files
21:21.17CIA-133BRL-CAD: 03starseeker * r46701 10/brlcad/trunk/CMakeLists.txt: Fix numbers on distcheck stages.
21:24.35CIA-133BRL-CAD: 03starseeker * r46702 10/brlcad/trunk/CMakeLists.txt: try searching for cpack rather than hardcoding it.
21:31.40*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
21:32.09CIA-133BRL-CAD: 03starseeker * r46703 10/brlcad/trunk/ (3 files in 2 dirs): completed distcheck does not necessarily imply distribution ready files, so don't assert that. No need for distcheck message file, and not using the old svncheck anymore.
22:20.42*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
22:57.26CIA-133BRL-CAD: 03tbrowder2 * r46704 10/brlcad/trunk/doc/docbook/resources/docbook-5.0/ (36 files in 8 dirs): add DocBook schemas for validation
22:58.30CIA-133BRL-CAD: 03tbrowder2 * r46705 10/brlcad/trunk/doc/docbook/Makefile.am: add make target for DocBook validation
23:18.43CIA-133BRL-CAD: 03jordisayol * r46706 10/brlcad/trunk/sh/make_deb.sh: Correct some minor erros.
23:58.28CIA-133BRL-CAD: 03r_weiss * r46707 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Updated function nmg_isect_two_face2p_jra within file nmg_inter.c. Improved the logic for determining where edges should be cut.
IRC log for #brlcad on 20110915

IRC log for #brlcad on 20110915

00:07.01CIA-133BRL-CAD: 03r_weiss * r46708 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mk.c: Updated function nmg_loop_g within file 'nmg_mk.c'. Changed the padding of the loop bounding box to only pad the dimension with is less than distance tolerance. The result is faster boolean operations on nmg primitives.
00:28.22*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
00:49.38CIA-133BRL-CAD: 03r_weiss * r46709 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Updated function nmg_isect_two_face2p_jra in file 'nmg_inter.c' adding more conditions for edge cutting.
02:02.53CIA-133BRL-CAD: 03tbrowder2 * r46710 10/brlcad/trunk/doc/docbook/fop.xconf.in: the docbook directory works fine as the base directory for fop
02:14.13starseekergrowls - cassowary c++ will need updating
02:21.47CIA-133BRL-CAD: 03tbrowder2 * r46711 10/brlcad/trunk/doc/docbook/fop.xconf.in: add more info and default fonts for embedding in pdf
02:23.21CIA-133BRL-CAD: 03tbrowder2 * r46712 10/brlcad/trunk/doc/docbook/resources/fonts/ (15 files in 3 dirs): add GNU free fonts for defaults for pdf
02:26.23CIA-133BRL-CAD: 03tbrowder2 * r46713 10/brlcad/trunk/doc/docbook/resources/offo-hyphenation-binary-v2.0/ (15 files in 3 dirs): add hyphenation for fop version 1.0
04:25.00*** join/#brlcad Stattrav (~Stattrav@61.12.114.82)
04:25.00*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
08:46.29*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
11:18.00*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:50.10CIA-133BRL-CAD: 03brlcad * r46714 10/brlcad/trunk/configure.ac: need HAVE_C99_FORMAT_SPECIFIERS to be defined for %zu printing
13:15.49starseekerbrlcad: I emailed Tom on the list about the stuff he's adding to Docbook - let me know if I should yank it until the license questions are resolved
13:22.02CIA-133BRL-CAD: 03brlcad * r46715 10/brlcad/trunk/src/libbu/argv.c: if we get a null argv, nothing to do
14:25.39*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
16:16.00*** join/#brlcad Stattrav (~Stattrav@61.12.114.82)
16:16.01*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
17:12.50``Erik<@joosa> how do you say float in java? just 1.5f?
17:12.50``Erik<@Gliptic> FloatFactoryFactory.getInstance(FloatFactoryFactory.defaultInstanceDescriptionString).getFactory(Locale.getLocale("en-US")).createBuilder().setString("1.5").getResult()
17:32.01*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
17:36.00starseekerheh
19:01.09brlcadnice
19:24.57``Erikhuh http://omnesviae.org/
19:47.19n_reedIrssi 0.8.11 (20070425) - http://irssi.org/ end
19:48.16*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
20:19.38CIA-133BRL-CAD: 03starseeker * r46720 10/brlcad/trunk/ (3 files in 2 dirs): back to configuring a message, but this time have it actually say something based on whether the tarballs are good or not.
21:41.36CIA-133BRL-CAD: 03erikgreenwald * r46722 10/brlcad/trunk/src/libgcv/bottess.c: fix up nmgregion tree for return. Completely eliminate soup2bot.
22:18.37CIA-133BRL-CAD: 03tbrowder2 * r46724 10/brlcad/trunk/doc/docbook/resources/fonts/truetype/gnu-freefonts/: removing fonts with incompatible license
22:26.24CIA-133BRL-CAD: 03tbrowder2 * r46725 10/brlcad/trunk/doc/docbook/resources/fonts/truetype/stix-v1.0.0/ (6 files): adding STIX fonts with SIL Open Font License
22:38.21CIA-133BRL-CAD: 03tbrowder2 * r46726 10/brlcad/trunk/doc/docbook/resources/fonts/truetype/stix-v1.0.0/ (4 files): pdf files showing all glyphs and unicode points for the four font faces
23:01.25CIA-133BRL-CAD: 03tbrowder2 * r46727 10/brlcad/trunk/doc/docbook/fop.xconf.in: restoring base to '@srcdir@' for testing cmake and autotools
IRC log for #brlcad on 20110916

IRC log for #brlcad on 20110916

00:02.17*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
01:41.26abhi2011starseeker: is the header simphysics.h not required to be mentioned in the CMakeLists.txt file for libged ?
01:42.18abhi2011I am trying to add a new source and header in the simulate command, and I think only the cpp file needs to be included in the libged/CMakeLists.txt file
01:42.23abhi2011at  SET(ged_ignore_files simulate/simphysics.cpp simulate/simulate.c)
01:43.50abhi2011so I ll change it to   SET(ged_ignore_files simulate/simphysics.cpp simulate/simulate.c simulate/simcollisionalgo.cpp simulate/simcollisionalgo.h)
03:14.02brlcadabhi2011: how'd that new render animation turn out?
03:14.26brlcadwas showing a bunch of folks your previous animation earlier this week, they love it! :)
03:14.39abhi2011yes it turned out fine
03:14.49abhi2011I ll make a movie over the night today :)
03:15.42abhi2011pentium dual core :P
03:25.14``Erikabhi: if you have something scriptable you can give us, we can throw a LOT of cpu into making you up a movie
03:26.23``Eriklike a stack of 16 core xeons :)
03:54.14abhi2011oh wow!
03:54.25abhi2011umm but u wud need bullet installed and working too
03:54.50abhi2011which reminds me, does the simulate command work on any other system correctly
03:55.21abhi2011also I have got a database and 2 tcl scripts
03:55.45abhi2011so I ll put these in the samples and tclscripts folders  if i want to share it ?
03:59.43abhi2011well database not needed actually, since the script can be run from a new database and creates everything
04:00.23abhi2011right, so i ll give clean up the script and pastebin it for now
05:02.56CIA-133BRL-CAD: 03abhi2011 * r46728 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simcollisionalgo.h): Added 2 files for containing a RT based contact manifold generator
05:26.35abhi2011ok here is the tcl script for generating the scene : http://bin.cakephp.org/view/350938158
05:35.14abhi2011:=
05:36.08abhi2011and here is the shell script
05:40.17abhi2011http://bin.cakephp.org/view/572543350
06:07.42CIA-133BRL-CAD: 03abhi2011 * r46729 10/brlcad/trunk/src/libged/ (CMakeLists.txt simulate/simphysics.cpp simulate/simulate.c): Began rt integration into the bullet collision pipeline, added callback to show aabb overlaps and contact points
06:27.02CIA-133BRL-CAD: 03Abhi2011 07http://brlcad.org * r3164 10/wiki/User:Abhijit: /* Log */
06:28.47CIA-133BRL-CAD: 03Abhi2011 07http://brlcad.org * r3165 10/wiki/User:Abhijit: /* Log */
06:38.56abhi2011the minute i submit the shell script the laptop fan ramps up a few notches
06:38.58abhi2011:P
12:47.28*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:04.43*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:23.00brlcadsenses a big remrt session in his near future
13:45.43``Erikabhi: is it possible to run a bullet simulation and export a series of 'geometry at time X' definitions? so a single machine can generate the 2000 or so 'states' to be farmed out for raytracing?
13:48.23brlcadpretty impressive scripting
13:49.16brlcad``Erik: he's not here right now, but it is possible -- his script could just call clone before running simulate
13:50.35brlcadthen his rt script could be issued for all 2000 frames at once for remrt instead of one at a time (which will kick rt into multi-frame render mode to make sure there isn't temporal tearing across frames)
13:57.41``Erikcool (didn't think he was here, but y'know, post and wait)
14:21.00CIA-133BRL-CAD: 03d_rossberg * r46730 10/brlcad/trunk/CMakeLists.txt:
14:21.00CIA-133BRL-CAD: a non visible function prototype yields a warning "warning C4013: 'hypot' undefined; assuming extern returning int" => turned the warnings into errors
14:21.00CIA-133BRL-CAD: a possible consequence of missing prototypes is a floating point stack overflow (as it happened in this case)
14:54.59brlcadouch
15:17.24CIA-133BRL-CAD: 03tbrowder2 * r46731 10/brlcad/trunk/doc/docbook/presentations/en/intro-to-tcltk.xml: corrected image file references for cuurent file structure
15:27.44*** join/#brlcad b0ef (~b0ef@166.195.251.212.customer.cdi.no)
15:29.20CIA-133BRL-CAD: 03Sean 07http://brlcad.org * r3166 10/wiki/ESA_Summer_of_Code_in_Space: update with post-selection details -- link to abhijit's log
15:45.24brlcadwhere's the b0ef!
15:59.05CIA-133BRL-CAD: 03tbrowder2 * r46732 10/brlcad/trunk/doc/docbook/fop.xconf.in: get the base URL for fop back to its rightful place
16:23.48*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
17:04.37CIA-133BRL-CAD: 03tbrowder2 * r46733 10/brlcad/trunk/README.cmake: some more details for newbies
17:32.28brlcadhm, not so fond of so much irrelevant info before getting to the heart of the readme ..
17:35.19brlcadjordisayol: thx for being patient :)
17:35.25brlcadhe's learning
17:35.40jordisayolbrlcad: I see
17:35.44jordisayol:-)
18:22.22abhi2011any luck running those scripts on the server
18:25.43CIA-133BRL-CAD: 03tbrowder2 * r46734 10/brlcad/trunk/doc/docbook/articles/en/pipes.xml: adding unicode point for two symbols
18:26.46brlcadabhi2011: was looking them over earlier today while you were out
18:27.19*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
18:27.24yukonbobhello, #brlcad
18:27.29brlcadabhi2011: nice work, btw .. impressive scripting pulling things together exactly the way they're supposed to be
18:27.34brlcadhowdy yukonbob
18:27.58yukonbobhey brlcad -- how're things?
18:28.34brlcadabhi2011: with only a few modifications, those two scripts will work pretty well for setting up a completely distributed rendering
18:29.29brlcadyukonbob: good as ever, lots of skewers in the fire
18:29.40brlcadwhat are you working on these days?
18:30.13abhi2011brlcad: yep learning :)
18:30.43yukonbobhead-down in Tcl/C whenever I can, and started w/ Apache working on Tcl bindings for search-engine-in-development
18:30.55yukonbob<-- bch@apache.org :)
18:30.57abhi2011so what modifications would u do for distributed rendering ?
18:31.03brlcadabhi2011: for the distributed render, you'd want to clone each object before running simulate so that you keep all timestep revisions, then make the rt script one *mega* script that renders all frames in sequence with only one call to rt
18:31.30yukonbobpoking at my local brlcad/tcl/nbsd integration when I get chances...
18:31.56brlcadthat will kick rt into a video-rendering mode where it becomes frame-aware and can apply tricks to make the frame-by-frame output better
18:32.23yukonboband actually stumbled on an omission on my part that should help push that ahead -- took a while to get a version a few months old up/running, and now need to do a smaller leap fwd and getting running w/ latest brlcad code again...
18:32.52brlcadthen it's as simple as copying the db to your render clients, replacing 'rt' with 'rtsrv' and running remrt some place to collect all of the results
18:33.00abhi2011oh ok, so as I understand you generate all the different position the objects are in by running simulate for 1 step, 2 steps , 3steps.....300 steps and record them in different dbs
18:33.12abhi2011so 300 dbs
18:33.14brlcadthey can be in the same db
18:33.21abhi2011ah yes right
18:33.25abhi2011but with different names
18:33.26brlcadscene.001 scene.002 .. whatever
18:33.41abhi2011oh the db supports scenes too
18:33.45abhi2011didnt know that
18:33.56yukonbob<PROTECTED>
18:34.37brlcadabhi2011: you'll notice in rt script that it has a bunch of lines starting with viewsize, then start 0; clean;
18:34.51abhi2011yes right
18:34.58brlcadthat actually is a command to start frame 0 ..
18:35.15abhi2011ok
18:35.17brlcadso after clean, you can load the next object, start 1, etc
18:35.27abhi2011ok
18:35.55brlcadpretty much exactly what you have, just pulling the rt command outside that for loop
18:35.56abhi2011and by default..the way I have been working with mged so far, that just creates 1 scene : scene 0 and puts everyting there
18:36.02brlcadand building up the command inside the for loop
18:36.38abhi2011ok
18:37.05brlcadabhi2011: another thing I noticed is the hard-coded hack you have in there for knowing what is what in the db :)
18:37.25abhi2011in the c code ?
18:37.33brlcadfor starters, you should pass the list of objects to be simulated as a parameter to the simulate command :)
18:37.37brlcadyeah
18:37.41abhi2011ok
18:37.52abhi2011ah yes right
18:38.01brlcadsim_gp.r :)
18:38.19abhi2011yeah that needs more flexibility :P
18:38.21brlcadthat way you know which object(s) to work on
18:38.42abhi2011so all the objects to be simulated get passed as paramters
18:39.03abhi2011but then i would need to know which one of the passed objects is the ground plane
18:39.21brlcadmaybe Usage: simulate timestep(s) object0 [object1 ...]
18:39.31brlcadright
18:39.37abhi2011ok
18:39.39brlcadthat brings me to my next suggestion :)
18:40.09brlcadso there's two concepts that I think bullet represents, correct me if I'm wrong
18:40.18brlcadone is this concept of a ground plane
18:40.29brlcadwhich is defined by a plane equation vector
18:40.47brlcadthen it's marked immutable (i.e., with 0 volume)
18:41.39brlcadthat being the second concept
18:41.43brlcadyes?
18:41.55abhi2011welll almost , actually its more general, there can be 2 types of objects in bullet : static objects (with mass 0) and dynamic objects (with non zero mass)
18:41.58CIA-133BRL-CAD: 03tbrowder2 * r46735 10/brlcad/trunk/TODO: add tasks to be done to clean up DocBook source
18:42.08brlcads/volume/mass/ .. that's what I meant ;)
18:42.24abhi2011yes right
18:42.31abhi2011so I can actually mark any object as static
18:42.33brlcadbut a ground plane isn't just a mass 0 entity iirc, no?
18:42.41abhi2011true
18:42.41brlcadyou have to say "this is ground" too, no?
18:42.51abhi2011no there is no need to say so
18:42.55abhi2011i just have to make it static
18:43.00abhi2011that is fixed in space
18:43.07brlcadotherwise if I put an immutable box above your boxes, they'd have gravity pulling them in two directions
18:43.08abhi2011there is no separate concept of ground
18:43.40abhi2011no becuase the gravity is specified independently for the entire world
18:43.45abhi2011there is no concept of ground
18:43.54abhi2011if i have a plane that is rigid
18:43.55brlcadso gravity is global
18:44.00abhi2011then it appears as the ground
18:44.11abhi2011but its not specfied as such
18:44.21brlcadmm, okay
18:44.39brlcadso then all you need is some means to designate or calculate an object's mass
18:44.57abhi2011yes, right now i use the volume of the objects bb and density of 0
18:44.58brlcadwe have a tool that does that (gqa) calculating mass, but it's not yet an API function
18:45.00abhi2011sorry 1
18:45.05brlcadnods
18:45.05abhi2011oh ok
18:45.07abhi2011cool
18:45.21brlcadso how about this
18:46.00brlcadyou assume all regions specified for simulation (via specifying a given scene/combination/group) have a mass of 1
18:46.10brlcadunless a mass-value is set
18:46.22abhi2011ok
18:46.26abhi2011yes
18:46.35brlcadthat way all you need is some means to set an object's mass
18:46.46abhi2011however a larger object may appear to have the same mass as a smaller object
18:46.54abhi2011yes , the mass can be set
18:46.56abhi2011true
18:47.04brlcadwhich fortunately there is a system already in place for :D
18:47.06abhi2011if the user want more realistic simulation
18:47.12abhi2011yes :)
18:47.46abhi2011so i guess i can call upon the code in the gqa thingie to get me the mass
18:48.00brlcadnah, that'd be hell
18:48.12abhi2011ok :P
18:48.27brlcadit's not API yet and it'd take a week or more to make it proper API
18:48.47brlcadyour time is better spent getting collisions working ;)
18:48.51abhi2011right ok, so i ll make it trhe way we dicusssed then
18:48.57abhi2011assume mass of 1
18:49.03abhi2011unoless specified
18:49.12brlcadright, but then you need a way to specify mass :)
18:49.18abhi2011yes
18:49.23abhi2011so a -m flag
18:49.24brlcaddo you know how already? :)
18:49.30brlcadno no
18:49.31abhi2011with the masses in order
18:49.45brlcadobject-oriented, you want objects to specify themselves
18:50.06abhi2011ok but the user is going to pass the mass right
18:50.29brlcadpass the mass .. hehe
18:50.29brlcadyes :)
18:50.45abhi2011ok
18:50.51brlcadso the missing piece of this puzzle...
18:50.55brlcadperhaps a new brl-cad concept, we have an attribute system where you can store key=value on arbitrary db objects
18:51.10abhi2011ok
18:51.17brlcadthat will probably work perfect for this
18:51.22abhi2011right
18:51.26abhi2011like the avs thing
18:51.35abhi2011for the attributes of an object
18:51.38brlcadwhat avs thing?
18:51.47abhi2011there is this avs variable all over the c code
18:51.52brlcadah, yes
18:51.53brlcadthat's this
18:51.59abhi2011its used to access the attributes
18:52.00brlcadavs == attribute value system
18:52.04abhi2011yes
18:52.06abhi2011:)
18:52.10abhi2011so not so new after all
18:52.12abhi2011:P
18:52.26abhi2011well yeah but i understand what you are saying
18:52.28brlcadyeah, so just need to use it for your own settings :)
18:52.28abhi2011:)
18:52.57abhi2011ok
18:53.06abhi2011now about passing the mass while invoking the command
18:53.06brlcadattr set ground.r simulate:mass=0
18:53.17abhi2011oh ok
18:53.19abhi2011ah now i get it
18:53.19brlcadthen in the code, just look up the "simulate:mass" attribute and use the value
18:53.26abhi2011right
18:53.28abhi2011cool
18:53.40brlcadcan use that for a whole slew of things then :)
18:53.45abhi2011so its like any other attribute of the object, like radius etc
18:53.47abhi2011yes
18:53.51abhi2011we can specfiy friction
18:53.54abhi2011for custom materials
18:53.58abhi2011or density
18:54.13brlcadjust prefix your variables so they can be conceptually grouped together
18:54.19abhi2011ok
18:54.40brlcadbut you should always have a "default" too .. so if nothing is set, it'll do something sane
18:54.49abhi2011ok
18:54.55abhi2011now about the ground plane thing
18:55.19abhi2011see the user will invoke the command like :  simulate a.r b.r
18:55.22brlcadlike maybe if there is no immutable mass=0 objects being simulated, it defaults to making the biggest one be mass=0
18:55.33abhi2011ok
18:55.42brlcadsimulate 10 scene
18:55.54brlcador simulate 10 grp1 grp2 grp3 ...
18:56.10brlcadnot necessarily just the region objects
18:56.13abhi2011ok
18:56.19abhi20111 more question
18:56.21brlcadtrivial to walk the object(s) specified, get a list of all regions
18:56.30abhi2011right
18:56.37abhi2011i guess a scene's objects can be accessed
18:56.44abhi2011not yet worked with scenes
18:56.45brlcadif there are no regions, maybe treat the object specified as a region or error out if you have to have a region
18:56.59brlcaddb_walk_tree() is your friend
18:57.02abhi2011cool
18:57.52abhi2011umm so about scenes, if i want to create a new scene
18:57.58abhi2011there is an mged comand for it ?
18:58.01brlcadthat way your code doesn't even need to know the name(s) of anything
18:58.14brlcad'g' ?
18:58.25brlcadscenes are just logical groupings of objects
18:58.41abhi2011oh ok
18:58.46brlcadyou can group a bunch of regions and groups together with the 'g' command
18:59.00abhi2011yes of course :)
18:59.08abhi2011thought they were a new kinda thing
18:59.16abhi2011:P
18:59.17brlcadthey're implicit
18:59.20abhi2011ok
18:59.44abhi2011ok there is 1 other thing
18:59.53abhi2011about custom forces
19:00.07abhi2011so suppose i want some impulse applied on a specfic object
19:00.08brlcadobjects above the region level are groups, groups are "assemblies" in CAD terminology -- a scene is just another assembly
19:00.16abhi2011can be used to shoot a sphere at a cube stack for example
19:01.52abhi2011ok about the assemblies, so about the custom forces should I consider at this stage , something liek this : simulate 10 -f{obj, 10,0,0} grp1 grp2 ....
19:02.33abhi2011so that would apply a force of 10 newtons on the region/group named as 'obj' only
19:02.43abhi2011the remainign objects stay the same
19:02.52CIA-133BRL-CAD: 03tbrowder2 * r46736 10/brlcad/trunk/doc/docbook/articles/en/mgedrc.xml: adding unicode point for two symbols; lifting XInclude namespace to root element
19:02.59abhi2011obj should appear somewhere in grp1, grp2 etc
19:03.03brlcadabhi2011: I'd probably still use the attributes for that
19:03.11abhi2011ah yes of course
19:03.13brlcadbecause you need to persist the force across frames
19:03.31abhi2011yes true, that would be much easier then parsing comples flags
19:03.43abhi2011yes
19:04.06abhi2011interesting and very useful this attributes thing :)
19:04.13brlcadgranted, that means you'll have to read all objects to see if any have forces applied, run the simulation step, then write out any remaining/residual forces (for the next timestep)
19:04.29CIA-133BRL-CAD: 03tbrowder2 * r46737 10/brlcad/trunk/TODO: add another task to be done to clean up DocBook source
19:04.43brlcadbecomes a persistent database for any values you need during the sim
19:04.52abhi2011yes
19:04.53CIA-133BRL-CAD: 03starseeker * r46738 10/brlcad/trunk/README.cmake: Toplevel readme probably isn't the place for these details. Also, if the environment variables may cause a problem, the thing to do is to have CMake check them as part of the configure process and warn about them.
19:06.15abhi2011yes, that is another thing which was bothering me actually, see there are 2 options, to run all the simulation timesteps  without any thing else happening. or run 1 timestep, do overlp checks then run the next steps
19:06.26brlcadstarseeker: if CMake is a faithful conversion of configure, there should already be a big honking warning about BRLCAD_ROOT being set ;)
19:06.44abhi2011but if there is break between the steps and i have to recreate the entire scene again , then all the dynamic foce and acceleration info would need to be persisted
19:06.53abhi2011can use the attributes for that
19:06.58brlcadsure
19:07.28abhi2011right so a whole slew of new attributes to be added
19:07.39abhi2011for all objects in brl-cad
19:07.54abhi2011force , mass,
19:07.56brlcadall regions objects
19:08.02abhi2011yes ok
19:08.15abhi2011yes true
19:08.17abhi2011only regions
19:08.40brlcadpretty limited subset, and only after simulate has run once (and there are forces remaining) or as part of scene setup to override defaults
19:09.21brlcade.g., you wouldn't want to write out simulate:force=0.0 .. you'd delete the attribute
19:09.31abhi2011yes
19:09.41brlcad(assumes default force==0.0 of course)
19:09.57abhi2011yes, so all these attributes are listed in a header, and i just go add to them
19:10.29CIA-133BRL-CAD: 03tbrowder2 * r46739 10/brlcad/trunk/doc/docbook/articles/en/projection_shader.xml: adding unicode point for two symbols; lifting XInclude namespace to root element
19:10.53abhi2011and maybe increase a counter which currently tracks the number of attributes that can exist for a region
19:10.53starseekerbrlcad: yeah, yeah... :-P
19:11.08starseekeris catching up on backlog...
19:18.08CIA-133BRL-CAD: 03tbrowder2 * r46740 10/brlcad/trunk/doc/docbook/articles/en/build_region.xml: lifting XInclude namespace to root element
19:22.16abhi2011on thinking more about it, the velocity of the objects, both rotational and translational needs to be persisted for the next frame, and if any custom force should still to be applied in the next frame(since there is no concept of a residual force as such like 10 newtons force is applied and  5 newtons is left for next frame, that would result in wrong physics )
19:25.01abhi2011ok so I ll proceed with adding the new attributes : translational velocities in x y, z directions and rotational velocities for the 3 axes , and see if I can store then after 1 frame and reload them at the beginning of the next frame and see if physics continues properly
19:26.08abhi2011this can then be extended to calling rt at the end of a frame to create the contact manifolds , which can then be inserted into the collision pipeline befpre starting the next frame, so collision proceeds according to rt output
19:26.41CIA-133BRL-CAD: 03tbrowder2 * r46741 10/brlcad/trunk/doc/docbook/articles/en/build_pattern.xml: adding unicode point for one symbols; lifting XInclude namespace to root element
19:31.56CIA-133BRL-CAD: 03tbrowder2 * r46742 10/brlcad/trunk/doc/docbook/lessons/en/mged01_creating_primitive_shapes.xml: lifting XInclude namespace to root element
19:56.17brlcadstarseeker: if you knew the support hell that was when BRLCAD_ROOT was the norm, it probably would have been one of the first things you added
19:57.30brlcadhow many times I'd spend half a day debugging some really bizzare bug or crash only to discover they were running a 7.4 binary but using 7.0 libraries
19:58.50CIA-133BRL-CAD: 03starseeker * r46743 10/brlcad/trunk/CMakeLists.txt: Get a version of the warnings about BRLCAD_ROOT into CMake, as well as (reluctantly) using the environment variable if it's defined.
20:00.56brlcadabhi2011: couldn't you have a situation like where you'd have an electromagnetic field applying some force but then the force on the next frame would be different because of the different position in the field?
20:01.23brlcadthe idea being that you'd have some sort of force emitter objects, of course, with some sort of parametric force being applied
20:01.30brlcadnot just impulse or load
20:02.27brlcadabhi2011: I'd suggest combining the xyz velocities into one attribute (one for linear, one for rotational)
20:02.49brlcadshould limit the number of writes if values naturally group together
20:04.17CIA-133BRL-CAD: 03starseeker * r46744 10/brlcad/trunk/CMakeLists.txt: /usr is bad whether or not it came from BRLCAD_ROOT, adjust warning.
20:06.11brlcadstarseeker:  you missed the warning part
20:06.46brlcad"if test ! "x$BRLCAD_ROOT" = "x" ; then" ...
20:07.11brlcadthat's the important part
20:07.15starseekerthat's IF(BRLCAD_ROOT)
20:07.47starseekerSET(BRLCAD_ROOT "$ENV{BRLCAD_ROOT}") get's it from the environment variable - if that variable is empty, the if test fails.  otherwise, the warning proceeds
20:08.15brlcadnot following
20:08.33starseekerwe're warning if BRLCAD_ROOT is set, correct?
20:08.39brlcadcorrect
20:08.44starseekerthis will do that
20:09.03abhi2011brlcad : about the electro magnetic fields, yes true
20:09.41brlcadah, I see it.. the logic is further down .. I was expecting statement parity, or close to it
20:10.00brlcada quiet little "BRLCAD_ROOT is not necessary and may cause unexpected behavior" is not parity at all...
20:10.00CIA-133BRL-CAD: 03starseeker * r46745 10/brlcad/trunk/CMakeLists.txt: comment first, then code
20:10.37starseekerhas tested it - seems to do the trick
20:11.20brlcadthat's probably the distinction
20:11.30brlcadthere's no indication on the severity of the messages being printed
20:11.40CIA-133BRL-CAD: 03tbrowder2 * r46746 10/brlcad/trunk/HACKING: add reference to more DocBook details
20:12.31brlcadconfigure had something like four output levels, regular print message, warning, severe warning, and error (halting)
20:12.48starseekeryeah, I don't think cmake has warning vs. severe warning
20:12.53brlcadotherwise the messages will just get lost in the noise
20:13.31brlcadthe }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} markers screamed out "this is really bad" .. and it worked
20:13.33starseekerheh - I'm calling sleep on the first one, and flat out exiting with failure on /usr (with a message that tells them how to get it to go forward if they're really that stubborn)
20:13.40starseekerah, k
20:13.51CIA-133BRL-CAD: 03tbrowder2 * r46747 10/brlcad/trunk/doc/docbook/README: add more details on DB character code requirements
20:15.15brlcadthe only half-severe }}} message I think we ever reported was about the IEEE encoding, which I'm just not sure what it means in terms of valid calculations
20:15.28CIA-133BRL-CAD: 03tbrowder2 * r46748 10/brlcad/trunk/doc/docbook/README: correct typo
20:22.40CIA-133BRL-CAD: 03starseeker * r46749 10/brlcad/trunk/CMakeLists.txt: Make warnings noiser, also complain about BRLCAD_DATA
20:23.45brlcadstarseeker: er, BRLCAD_ROOT doesn't set prefix in configure ...
20:24.35starseekerah, my mistake
20:24.39starseekerwasn't parsing the m4 logic right
20:25.25brlcadit pulls the value from prefix (setting BRLCAD_ROOT) .. but that's os we set BRLCAD_ROOT as a define in the config header (so things like bu_brlcad_root() work correctly)
20:25.33brlcads/os/so/
20:26.19starseekernods - I never use BRLCAD_ROOT as a variable at all in CMake - it gets set to CMAKE_INSTALL_PREFIX in the config header
20:27.00brlcad"it" being BRLCAD_ROOT?
20:27.06starseekeryes
20:27.40brlcadyeah, I wouldn't have expected you to use it as a var
20:29.44CIA-133BRL-CAD: 03starseeker * r46750 10/brlcad/trunk/CMakeLists.txt: My mistake, we're not setting CMAKE_INSTALL_PREFIX to BRLCAD_ROOT. Tweak the logic and warnings accordingly
20:31.19brlcadit was needed for the m4 logic because BRLCAD_ROOT exists as a shell variable, an m4 variable, a make variable, and a #define -- cmake effectively eliminates the m4+make cases (unless you allow the same make-time override)
20:31.21CIA-133BRL-CAD: 03starseeker * r46751 10/brlcad/trunk/CMakeLists.txt: match closing tag
20:31.29brlcaddoes miss the various make-time overrides
20:34.05brlcade.g., make TCLDIR= TKDIR= (skip rebuilding tcl/tk even if dependency tracking wants to rebuild them)
20:34.34starseekerwinces - not sure how I'd make that work
20:34.40brlcadmake CPPFLAGS=-w (skip strict for this pass)
20:34.56brlcadno worries, not a major feature
20:35.08brlcadjust one of those things :)
20:35.53brlcadoverriding the dependency tracking system wasn't something universal, there had to be a make variable defined for the directory
20:36.01brlcadgetting that in cmake terms would probably suck
20:36.39brlcadbecause it'd probably take some round-about checking mechanism instead of just letting make do what it does
20:37.02CIA-133BRL-CAD: 03starseeker * r46752 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: That's actually CXXFLAGS, not CXX_FLAGS...
20:37.18brlcadone of the merits of automake+make .. but not one that trumps the windows portability aspect of cmake
20:37.22starseekerprobably mattered more when build times were slower
20:37.41brlcadnah, still matters .. I used it just last week :)
20:38.13starseekershakes his head - I think my developer skills are going to forever remain at the "midrange" level
20:38.40starseekercan get there eventually, usually...
20:39.00brlcadthink if you're working on building a proc-db or something simple, find out you need to add a libbu function that begs for a new configure/cmake header test, .. it's going to rightly want to rebuild everything
20:39.47starseekermake -j9 procdb_target would build only what that proc-db needs, I'd probably call that close enough...
20:40.07brlcadyou don't care about rebuilding everything in that moment, whether it's 2min or 10min .. your procdb builds and links in 2 milliseconds and that's what you're focusing on :)
20:40.31starseekermake procdb_target/FAST I think might do what you want there
20:40.43brlcadmaybe
20:40.51brlcadbut I *did* need libbu rebuilt :)
20:41.12brlcadjust not every f'n thing that uses libbu, and certainly not all of src/other :)
20:41.40starseekernods
20:41.51brlcadlike I said, not a huge deal .. just something different
20:41.57starseekermaybe if you describe the scenario to the CMake devs they could come up with something...
20:42.10brlcadnot even that important
20:42.49brlcadmight even be something similar in cmake terms that will work "good enough", like make libbu/FAST && make my_proc/FAST
20:43.20starseekerthought about suggesting that, but assumed it would be rejected for "too much typing" reasons :-P
20:44.17brlcadit's better than waiting 2-10min :)
21:30.59starseekertcl/tk 2011 schedule is up: http://www.tcl.tk/community/tcl2011/schedule.html
22:02.19brlcadlooks like Cliff F. is all over the place in the schedule this year
22:02.32brlcadquirky funny guy :)
22:03.33brlcadat least in a geek humor kind of way :)
22:03.38brlcadbets $20 that he says "Any questions? Any answers?" at least a few times during the week
22:57.25brlcadoh snap!
22:57.33brlcadthank you tom browder!
22:58.01brlcadlooks like sourceforge folks made ideatorret an option, that's outstanding!
IRC log for #brlcad on 20110917

IRC log for #brlcad on 20110917

00:31.48louipcwhat's ideatorrent all about?
01:02.59starseekerwas wondering that too...
01:55.35*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ)
02:00.13*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
04:38.46brlcadideatorrent is a community-driven feature request ranking system
04:39.37brlcadsort of a cross between digg and stackoverflow, it lets users post a feature request that others are then able to rank up, rank down, comment on, etc
04:40.37brlcadubuntu brainstorm ( http://brainstorm.ubuntu.com/ ) came up with the idea and was a pretty big success -- that got forked off as it's own project called IdeaTorrent
04:42.05brlcadhere's ours set up: https://sourceforge.net/apps/ideatorrent/brlcad/
04:42.18brlcadI added three initial ideas to the sandbox to get things going
04:44.26brlcadso there's two parts to it too
04:45.41brlcadyou propose a problem or lacking feature area (rt has too many command line options making it hard to use) as well as a solution (introduce long options and remove the following short options:...)
04:45.58brlcadothers can propose alternate solutions (and other feature areas)
04:46.08brlcadand everyone can vote on the problems and proposed solutions
10:54.02*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:19.50CIA-133BRL-CAD: 03tbrowder2 * r46753 10/brlcad/trunk/doc/docbook/articles/en/pipes.xml: added missing 'x' for hex unicode points
12:55.24*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl)
13:22.06CIA-133BRL-CAD: 03Sean 07http://brlcad.org * r3167 10/wiki/BOT: Redirecting to [[BoT]]
13:41.52``Erikwee, I submitted one to ideatorrent O.o (interface seems a bit of a pita)
16:24.05*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:22.52*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
20:19.37*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
20:31.56*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20110918

IRC log for #brlcad on 20110918

00:14.08*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
08:16.45*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
09:21.47*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:04.43*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
11:18.29CIA-133BRL-CAD: 03tbrowder2 * r46754 10/brlcad/trunk/HACKING: add discussion of floating point comparisons
13:51.36*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
16:52.15*** join/#brlcad Elrohir (~kvirc@p5B14B167.dip.t-dialin.net)
19:29.11CIA-133BRL-CAD: 03Abhi2011 07http://brlcad.org * r3168 10/wiki/Animation: /* With ffmpeg */
19:30.53CIA-133BRL-CAD: 03Abhi2011 07http://brlcad.org * r3169 10/wiki/Animation: /* With ffmpeg */
19:55.57*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
20:19.09abhi2011about the ideas for improvement, I really think it would be great to have all the tools accessible from the single point archer gui
20:19.26abhi2011like 3ds max or maya does
20:21.06abhi2011I think most new users would expect to start with a gui and then move on to scripting and command line tools later
21:30.54abhi2011is it possible to draw simply arrows and labels in the mged window
21:31.23abhi2011i want to show the direction of velocity and the value
21:31.30abhi2011maybe sketches can help
IRC log for #brlcad on 20110919

IRC log for #brlcad on 20110919

00:58.48CIA-133BRL-CAD: 03abhi2011 * r46755 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): started adding sim attributes
01:38.56CIA-133BRL-CAD: 03tbrowder2 * r46756 10/brlcad/trunk/doc/docbook/presentations/en/intro-to-tcltk.xml: prettying
01:44.25CIA-133BRL-CAD: 03tbrowder2 * r46757 10/brlcad/trunk/doc/docbook/resources/fonts/truetype/dejavu-lgc-fonts-ttf-2.33/ (23 files in 2 dirs): adding another free font
01:45.01CIA-133BRL-CAD: 03tbrowder2 * r46758 10/brlcad/trunk/doc/docbook/fop.xconf.in: update with currently used fonts
01:47.43CIA-133BRL-CAD: 03tbrowder2 * r46759 10/brlcad/trunk/doc/docbook/system/man1/en/obj-g.xml: correct typos; correct terminology
01:48.54CIA-133BRL-CAD: 03tbrowder2 * r46760 10/brlcad/trunk/doc/docbook/lessons/es/mged01_crear_figuras_primitivas.xml: lift xinclude namespace to root element
01:49.54CIA-133BRL-CAD: 03tbrowder2 * r46761 10/brlcad/trunk/doc/docbook/lessons/es/mged03_utilizar_comando_in.xml: lift xinclude namespace to root element
01:50.34CIA-133BRL-CAD: 03tbrowder2 * r46762 10/brlcad/trunk/doc/docbook/lessons/es/mged02_opciones_vistas.xml: lift xinclude namespace to root element
01:51.27CIA-133BRL-CAD: 03tbrowder2 * r46763 10/brlcad/trunk/doc/docbook/books/en/tutorial_series_authors.xml: added xml header
01:56.37brlcadabhi2011: bu_argv_from_vls() + strtol() would probably be a "better way"
01:56.47brlcad(in regards to your TODO)
02:43.36CIA-133BRL-CAD: 03tbrowder2 * r46764 10/brlcad/trunk/doc/docbook/presentations/en/intro-to-tcltk.xml: correct well-formedness error
02:45.47CIA-133BRL-CAD: 03tbrowder2 * r46765 10/brlcad/trunk/doc/docbook/system/man1/en/obj-g.xml: remove extraneous char
02:50.24CIA-133BRL-CAD: 03tbrowder2 * r46766 10/brlcad/trunk/doc/docbook/system/man1/en/obj-g.xml: remove extraneous char
08:14.47abhi2011brlcad: thanks!
08:22.20abhi2011hmmm just realized that I cannot simply assume integers as the components of the vector
08:22.54abhi2011so need to split the string based on whitespaces and convert each part into a floating point number
08:58.23abhi2011so something like sscanf(str, "%f %f %f", &vec[0], &vec[1], &vec[2])
11:34.40*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:44.25*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:55.07*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
14:24.52*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
14:28.09brlcadabhi2011: bu_argv_from_vls()+strtod()
14:28.28brlcadsscanf could work, but it's not nearly as robust as strtod
14:28.39abhi2011oh ok
14:28.59brlcadand the whitespace parsing you'll get from bu_argv_from_vls() provides a little more flexibility
14:29.13abhi2011ok
14:31.45brlcadalso meant to say about your other comments -- completely agree that it should all be accessible within archer/mged ...
14:32.11brlcadjust think it's a bit much to tackel before it's working
14:32.31brlcadthat said, drawing arrows and labels is something you could add before then
14:33.17brlcadthe nirt command does that along with a few other commands (it's very low-level)
17:30.56*** join/#brlcad dli (~dli@67.55.34.89)
19:43.14*** join/#brlcad ibot (~ibot@rikers.org)
19:43.14*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
20:13.25*** join/#brlcad ibot (~ibot@rikers.org)
20:13.25*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
20:49.52brlcadhappens
20:49.55brlcad(a lot) :)
21:03.44CIA-133BRL-CAD: 03tbrowder2 * r46767 10/brlcad/trunk/TODO: add check for properly embedded fonts in pdf docs
21:06.54CIA-133BRL-CAD: 03tbrowder2 * r46768 10/brlcad/trunk/TODO: correct typo: 'et al.' is short for 'et alii' which is Latin for 'and others'
21:08.39CIA-133BRL-CAD: 03tbrowder2 * r46769 10/brlcad/trunk/doc/docbook/Makefile.am: remove all DB xml validation references
22:43.25*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:57.30CIA-133BRL-CAD: 03tbrowder2 * r46770 10/brlcad/trunk/doc/docbook/system/mann/mged_cmd_template.xml: moving template to normal location
23:59.25CIA-133BRL-CAD: 03tbrowder2 * r46771 10/brlcad/trunk/doc/docbook/system/mann/mged_cmd_template.xml: moving template back to original location--easier to find here
IRC log for #brlcad on 20110920

IRC log for #brlcad on 20110920

00:15.07brlcad``Erik: crit now points to new machine again, just sync'd pw/group db's again, and more to come...
01:23.42CIA-133BRL-CAD: 03tbrowder2 * r46772 10/brlcad/trunk/doc/docbook/resources/fonts/truetype/dejavu-lgc-fonts-ttf-2.33/ (AUTHORS BUGS LICENSE NEWS README): more docs for dejavu fonts
01:24.45CIA-133BRL-CAD: 03tbrowder2 * r46773 10/brlcad/trunk/doc/docbook/books/en/ (2 files): lifting xinclude namespace to root element
01:25.37CIA-133BRL-CAD: 03tbrowder2 * r46774 10/brlcad/trunk/doc/docbook/specifications/en/BRL_CAD_g_format_V5.xml: eliminating unneeded info elements
01:32.20CIA-133BRL-CAD: 03tbrowder2 * r46775 10/brlcad/trunk/doc/docbook/README: add info on DB processing and validation tools
01:33.21CIA-133BRL-CAD: 03tbrowder2 * r46776 10/brlcad/trunk/doc/docbook/ (BRLCAD_DB_VALIDATION.pm find-db-files.pl validate.pl): add DB validation tools
01:35.09CIA-133BRL-CAD: 03tbrowder2 * r46777 10/brlcad/trunk/doc/docbook/books/ (it/ ru/): add Italian and Russian lang subdirs for BRL-CAD Overview
03:59.23``Erikawesomesauce
04:01.40``Erikthere's been some shuffle in system accounts and groups, need to be a bit careful about that for the real transition
05:10.02brlcadI did diffs, seemed fine
05:10.50brlcadwon't bother syncing passwords until it's time to turn off the lights
06:16.11brlcadfinishes scanning /etc
11:19.54*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:57.32CIA-133BRL-CAD: 03tbrowder2 * r46778 10/brlcad/trunk/TODO: add more DB tasks
12:07.49CIA-133BRL-CAD: 03tbrowder2 * r46779 10/brlcad/trunk/doc/docbook/resources/brlcad/ (. xsl/): add new dir for BRL-CAD DB xsl customizations
12:42.17CIA-133BRL-CAD: 03tbrowder2 * r46780 10/brlcad/trunk/doc/docbook/resources/brlcad/xsl/ (6 files): add intial xsl customizations
12:43.06*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:50.25CIA-133BRL-CAD: 03tbrowder2 * r46781 10/brlcad/trunk/doc/docbook/resources/brlcad/xsl/brlcad-xhtml-header-navigation.xsl: remove offending xml comment
12:59.15CIA-133BRL-CAD: 03tbrowder2 * r46782 10/brlcad/trunk/doc/docbook/resources/brlcad/ (12 files in 2 dirs): eliminating unnecessary dir
14:30.08*** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net)
15:24.40CIA-133BRL-CAD: 03tbrowder2 * r46783 10/brlcad/trunk/AUTHORS: correct name and company
15:27.11CIA-133BRL-CAD: 03tbrowder2 * r46784 10/brlcad/trunk/configure.ac: need an absolute build path for DocBook xml catalogs
15:29.01CIA-133BRL-CAD: 03tbrowder2 * r46785 10/brlcad/trunk/doc/docbook/DBPATH.pm.in: add config file for a Perl module for DocBook home path
15:30.22CIA-133BRL-CAD: 03tbrowder2 * r46786 10/brlcad/trunk/doc/docbook/ (BRLCAD_DOC.pm create-xml-catalogs.pl): adding DB tools for xsl customization and configuration
15:33.20*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-181.wlan.tudelft.nl)
15:50.54*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
16:00.23*** join/#brlcad yukonbob (~bch@S0106002191d1591c.ok.shawcable.net)
16:10.08CIA-133BRL-CAD: 03n_reed * r46787 10/brlcad/trunk/src/libgcv/wfobj/ (tri_face.c tri_face.h): added make_faceuse_from_face func; usefull elsewhere
16:11.35CIA-133BRL-CAD: 03n_reed * r46788 10/brlcad/trunk/src/conv/obj-g_new.c: using nmg triangulation for concave faces when making bots
16:16.34CIA-133BRL-CAD: 03n_reed * r46789 10/brlcad/trunk/src/conv/obj-g_new.c: making native bot the default conversion mode
16:36.03CIA-133BRL-CAD: 03tbrowder2 * r46790 10/brlcad/trunk/doc/docbook/resources/standard/svg/: adding W3C resource files for svg
16:42.55CIA-133BRL-CAD: 03tbrowder2 * r46791 10/brlcad/trunk/doc/docbook/resources/standard/svg/ (58 files): adding W3C resource files for svg
16:55.59CIA-133BRL-CAD: 03tbrowder2 * r46792 10/brlcad/trunk/doc/docbook/resources/brlcad/xsl/: removing unneeded dir
16:58.49CIA-133BRL-CAD: 03tbrowder2 * r46793 10/brlcad/trunk/doc/docbook/resources/brlcad/: ignore auto-generated files
17:29.44*** part/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
17:30.14*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
17:55.11CIA-133BRL-CAD: 03erikgreenwald * r46794 10/brlcad/trunk/src/libgcv/bottess.c: add support for the writer callback
18:20.39CIA-133BRL-CAD: 03tbrowder2 * r46795 10/brlcad/trunk/doc/docbook/resources/brlcad/center-table-print.xsl: new specialized stylesheet
20:22.09*** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no)
20:48.46CIA-133BRL-CAD: 03brlcad * r46796 10/brlcad/trunk/src/proc-db/: ignore menger binary
20:50.15CIA-133BRL-CAD: 03brlcad * r46797 10/brlcad/trunk/src/libbu/: ignore new tester binaries
20:51.21CIA-133BRL-CAD: 03brlcad * r46798 10/brlcad/trunk/src/libbu/: ignore test_htond too
20:57.15CIA-133BRL-CAD: 03brlcad * r46799 10/brlcad/trunk/src/libged/ged_private.h: rename pipe to pipe_internal to avoid shadowing the system function
21:53.39*** part/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net)
21:58.23CIA-133BRL-CAD: 03tbrowder2 * r46800 10/brlcad/trunk/doc/docbook/create-xml-catalogs.pl: get uri mapping right for xml catalog
22:00.39CIA-133BRL-CAD: 03tbrowder2 * r46801 10/brlcad/trunk/doc/docbook/resources/fonts/: ignore STIX src dir
22:02.06CIA-133BRL-CAD: 03tbrowder2 * r46802 10/brlcad/trunk/doc/docbook/resources/fonts/truetype/dejavu-lgc-fonts-ttf-2.33/: ignore a dejavu font dir
22:20.32CIA-133BRL-CAD: 03brlcad * r46803 10/brlcad/trunk/src/libbu/temp.c: it's not a warning, it's an outright unexpected error but do what the caller asked for anyways, truncating the result.
23:01.37*** join/#brlcad CIA-63 (~CIA@cia.atheme.org)
23:02.20*** join/#brlcad kanzure_ (~kanzure@131.252.130.248)
23:02.32*** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
23:03.14CIA-63BRL-CAD: 03tbrowder2 * r46805 10/brlcad/trunk/doc/docbook/BRLCAD_DB_VALIDATION.pm: added path for oNVDL validation method
23:04.13CIA-63BRL-CAD: 03tbrowder2 * r46806 10/brlcad/trunk/doc/docbook/README: added info on oNVDL validation method
23:05.07CIA-63BRL-CAD: 03tbrowder2 * r46807 10/brlcad/trunk/doc/docbook/validate.pl: added oNVDL validation method
23:10.04*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
IRC log for #brlcad on 20110921

IRC log for #brlcad on 20110921

00:29.28*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
00:33.20starseekerah, nuts - that's why the tcl/tk cmake was faster, left out an optimization flag TEA was adding
00:36.54CIA-63BRL-CAD: 03tbrowder2 * r46808 10/brlcad/trunk/doc/docbook/validate.pl: more check and options available--help completely documented
00:42.24CIA-63BRL-CAD: 03tbrowder2 * r46809 10/brlcad/trunk/doc/docbook/BRLCAD_DB_VALIDATION.pm: correcting path
00:43.45CIA-63BRL-CAD: 03tbrowder2 * r46810 10/brlcad/trunk/doc/docbook/Makefile.am: add xml catalogs to xsltproc and fop execution
01:10.42CIA-63BRL-CAD: 03brlcad * r46811 10/brlcad/trunk/src/librt/comb/comb.c: we don't use the resource, so only check validity if non-null
01:16.47CIA-63BRL-CAD: 03brlcad * r46812 10/brlcad/trunk/src/librt/db5_io.c: use the rt_uniresource if we get passed a null resource since the functab functions require one for resource allocation.
01:22.09CIA-63BRL-CAD: 03brlcad * r46813 10/brlcad/trunk/src/librt/db5_io.c: be consistent about checking the resource pointer, but only set rt_uniresource if it's a routine that calls into the functab.
01:26.25starseekerannnd adding those flags exposes other problems
01:26.26starseekersighs - guess I know what I'm doing tomorrow
01:29.17CIA-63BRL-CAD: 03brlcad * r46814 10/brlcad/trunk/src/librt/bundle.c: don't set the magic, it's not necessarily initialized.
01:32.16CIA-63BRL-CAD: 03brlcad * r46815 10/brlcad/trunk/src/librt/shoot.c: note to self, there's a lot more work to be done here. unstable implementation that erroneously relies on zero-initialization. since this is in a critical path, it'll take more effort to 'make it better' and verify.
01:47.25CIA-63BRL-CAD: 03brlcad * r46816 10/brlcad/trunk/src/librt/ (5 files in 2 dirs): more resource cleanup. setting the RESOURCE_MAGIC blindly is asking for trouble, don't do it. all calls to &rt_uniresource should go through a function so the global can be eliminated and initialization guaranteed.
01:48.56CIA-63BRL-CAD: 03brlcad * r46817 10/brlcad/trunk/src/librt/db5_io.c: missing close paren
01:52.56CIA-63BRL-CAD: 03brlcad * r46818 10/brlcad/trunk/src/librt/db_walk.c: don't halt on an RT_CK_RESOURCE check since it's not necessary that the parameter be non-NULL. pass the buck down.
01:53.35CIA-63BRL-CAD: 03brlcad * r46819 10/brlcad/trunk/src/librt/db_walk.c: ws consistency cleanup
02:02.36starseeker:q
02:03.36CIA-63BRL-CAD: 03starseeker * r46820 10/brlcad/trunk/src/other/ (4 files in 4 dirs): Backport some tcl.cmake changes from tcl/tk 8.6 work
02:20.51CIA-63BRL-CAD: 03brlcad * r46821 10/brlcad/trunk/src/libged/lt.c: redundant nullity check
02:50.42CIA-63BRL-CAD: 03tbrowder2 * r46822 10/brlcad/trunk/doc/docbook/validate.pl: correcting evaluating dbfils hash
02:51.20CIA-63BRL-CAD: 03tbrowder2 * r46823 10/brlcad/trunk/doc/docbook/resources/brlcad/ (3 files): first cut at cleanup of customization xsl files
03:17.32CIA-63BRL-CAD: 03brlcad * r46824 10/brlcad/trunk/src/conv/ (CMakeLists.txt Makefile.am g-dot.c): (log message trimmed)
03:17.32CIA-63BRL-CAD: add an initial implementation of a BRL-CAD exporter for the DOT plain text graph
03:17.32CIA-63BRL-CAD: description language. This exporter outputs the CSG DAG for a given set of
03:17.32CIA-63BRL-CAD: objects with color coding based on the node type (presently only recognizing
03:17.32CIA-63BRL-CAD: non-region combinations, regions, and primitives). works like a charm on a .g
03:17.32CIA-63BRL-CAD: file and unlike the other exporters, will default to all top-level objects if
03:17.33CIA-63BRL-CAD: none are specified (a concept that should be extended to all our exporters).
03:19.15CIA-63BRL-CAD: 03brlcad * r46825 10/brlcad/trunk/src/libged/lt.c: free the vls that was initialized
07:49.27*** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no)
07:51.30*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
07:51.30*** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
07:52.02*** join/#brlcad dli (~dli@67.55.34.89)
07:52.02*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
07:52.22*** join/#brlcad CIA-63 (~CIA@cia.atheme.org)
07:52.23*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
07:52.23*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
07:53.56*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
07:53.56*** join/#brlcad 13WAADT8D (~kanzure@131.252.130.248)
07:53.56*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
07:53.56*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
07:53.56*** join/#brlcad yiyus (1242712427@je.je.je)
07:53.56*** join/#brlcad piksi (piksi@pi-xi.net)
11:58.55CIA-63BRL-CAD: 03tbrowder2 * r46826 10/brlcad/trunk/TODO: add pdf index
12:02.20CIA-63BRL-CAD: 03tbrowder2 * r46827 10/brlcad/trunk/TODO: index is really a contents listing and link reference
12:04.29CIA-63BRL-CAD: 03tbrowder2 * r46828 10/brlcad/trunk/TODO: correct typo
13:21.52CIA-63BRL-CAD: 03tbrowder2 * r46829 10/brlcad/trunk/doc/docbook/find-db-files.pl: always use strict and warnings for good Perl practice
13:23.09CIA-63BRL-CAD: 03tbrowder2 * r46830 10/brlcad/trunk/doc/docbook/find-db-files.pl: tidy ws and sub names
13:44.15CIA-63BRL-CAD: 03tbrowder2 * r46831 10/brlcad/trunk/doc/docbook/create-index.pl: add a new tool to create an index for DB products
14:14.15CIA-63BRL-CAD: 03tbrowder2 * r46832 10/brlcad/trunk/src/other/tcl/generic/tcl.h: correct typo
14:41.46*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:19.21CIA-63BRL-CAD: 03n_reed * r46833 10/brlcad/trunk/ (include/raytrace.h src/conv/iges/iges.c): removed last use of nmg_moveeu, now permanently renamed to nmg_je
15:27.12CIA-63BRL-CAD: 03n_reed * r46834 10/brlcad/trunk/doc/deprecation.txt: added nmg_movveu->nmg_je substitution under minmally impacting api changes
15:27.45*** join/#brlcad dli (~dli@67.55.34.89)
15:54.10CIA-63BRL-CAD: 03tbrowder2 * r46835 10/brlcad/trunk/doc/docbook/validate.pl: now all options should work including '--stop'
16:04.21*** join/#brlcad dli (~dli@67.55.34.89)
16:21.51CIA-63BRL-CAD: 03bob1961 * r46836 10/brlcad/trunk/src/libged/get_autoview.c: libged/get_autoview now returns the largest of the radial vector components as the value for "size" instead of radial[X].
16:22.33CIA-63BRL-CAD: 03tbrowder2 * r46837 10/brlcad/trunk/doc/docbook/validate.pl: better info for output--option stop works on all three methods
18:01.35*** join/#brlcad dli (~dli@67.55.34.89)
18:19.02*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565177.dsl.bell.ca)
18:24.35CIA-63BRL-CAD: 03brlcad * r46838 10/brlcad/trunk/src/libbu/ptbl.c: make sure buffer has been allocated before trying to free it. might be valid and null. also, make sure we don't dereference the ptbl until after BU_CK_PTBL().
18:25.47CIA-63BRL-CAD: 03brlcad * r46839 10/brlcad/trunk/src/libbu/ptbl.c: gah, fix copy/paste error.
18:46.46``Erikhuh, interesting http://blogs.msdn.com/b/oldnewthing/archive/2011/09/21/10214405.aspx
18:47.17CIA-63BRL-CAD: 03brlcad * r46840 10/brlcad/trunk/ (include/bu.h src/libbu/quote.c):
18:47.17CIA-63BRL-CAD: change the signature of bu_vls_encode/bu_vls_decode to return pointers to the
18:47.17CIA-63BRL-CAD: strings that were encoded/decoded. this allows the functions to be chained
18:47.17CIA-63BRL-CAD: together and embedded within printing statements without additional calls to
18:47.17CIA-63BRL-CAD: bu_vls_addr(). tries to account for vls strings with existing content too.
19:05.33``Erik"every time you make a powerpoint, edward tufte kills a kitten"
19:15.33brlcadit's true
19:16.21``Erikhttp://tkkc.org
19:54.30*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:44.37CIA-63BRL-CAD: 03brlcad * r46841 10/brlcad/trunk/TODO: some thoughts on the ambiguous historic use of u,+,- for the boolean operators and what to consider moving forward for rel8
21:15.40CIA-63BRL-CAD: 03brlcad * r46842 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am test_quote.c): stub in an initial unit test harness for new string quoting api
21:23.33CIA-63BRL-CAD: 03brlcad * r46843 10/brlcad/trunk/src/conv/g-dot.c:
21:23.33CIA-63BRL-CAD: keep track of which objects have already been written out with a creative (if I
21:23.33CIA-63BRL-CAD: do say so myself) use of bu_ptbl using the bu_hash() of the object name.
21:23.33CIA-63BRL-CAD: tracking each node type separately so they can be formatted as a group later.
21:23.33CIA-63BRL-CAD: also include the title and name of the input file as a label on the graph.
21:27.15CIA-63BRL-CAD: 03erikgreenwald * r46844 10/brlcad/trunk/src/libgcv/bottess.c: initialize intersect points. minor cleanup
21:51.22CIA-63BRL-CAD: 03r_weiss * r46845 10/brlcad/trunk/src/conv/g-vrml.c: (log message trimmed)
21:51.22CIA-63BRL-CAD: Significate updates to the 'g-vrml' converter. Some logic bugs were fixed.
21:51.22CIA-63BRL-CAD: Triangulation was changed to use 'nmg_triangulate_model' instead of its own
21:51.22CIA-63BRL-CAD: function which was very limited. Added two new options. A '-b' option to perform
21:51.22CIA-63BRL-CAD: a bot dump (all csg geometry is ignored) and '-e' to perform an evaluation or
21:51.22CIA-63BRL-CAD: all opjects including bots. By default bots are dumped and csg evaluation is
21:51.23CIA-63BRL-CAD: perform ignoring the bots. Some code refactoring was also done. More testing is
22:17.58*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
22:36.17*** join/#brlcad DarkCalf (DC@173.231.40.98)
22:50.28CIA-63BRL-CAD: 03abhi2011 * r46846 10/brlcad/trunk/src/libged/simulate/simulate.c: fixed the parse_vector function to use libbu
23:10.48CIA-63BRL-CAD: 03tbrowder2 * r46847 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: squash compiler warning of uninitiated var
23:41.31CIA-63BRL-CAD: 03abhi2011 * r46848 10/brlcad/trunk/src/libged/simulate/simulate.c: added linear velocity and angular velocity properties to the list passed to physics
23:57.46CIA-63BRL-CAD: 03tbrowder2 * r46849 10/brlcad/trunk/doc/docbook/ (6 files): ignore autogenerated files
IRC log for #brlcad on 20110922

IRC log for #brlcad on 20110922

01:25.24*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
02:48.28*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
07:41.03*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:00.12CIA-63BRL-CAD: 03tbrowder2 * r46850 10/brlcad/trunk/doc/docbook/lessons/es/mged03_utilizar_comando_in.xml: remove period from title
13:10.30CIA-63BRL-CAD: 03tbrowder2 * r46851 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeIV.xml: add missing title
14:15.41*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
14:42.31``Erik(union (difference s1 s2) s3)   <-- that looks keen to me :D
14:52.00CIA-63BRL-CAD: 03bob1961 * r46852 10/brlcad/trunk/ (13 files in 5 dirs):
14:52.00CIA-63BRL-CAD: Changed the way dm-ogl and dm-wgl were handling zclipping (i.e. setting a value
14:52.00CIA-63BRL-CAD: in the GL_MODELVIEW matrix). This adversely affected lighting if the window
14:52.00CIA-63BRL-CAD: bounds were relatively big and was noticeable when viewing geometry in shaded
14:52.00CIA-63BRL-CAD: mode. Added GUI components in Archer to control the front and back zclipping
14:52.00CIA-63BRL-CAD: planes.
14:54.15*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:10.14brlcad``Erik: heh, that adds potentially an order of magnitude to the processing time parsing those expressions
15:10.48brlcadespecially nasty for expressions with more than a dozen operations (which is VERY common)
15:12.29``Erik(define-symbol-macro + union)
15:13.25brlcadthen it's back to the same issue of what to use for union and intersection :)
15:14.20``Erikbut but but lisp is magic fairy dust that makes everything right! :D
15:53.33CIA-63BRL-CAD: 03bob1961 * r46853 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Don't need the extra call to go_draw() in the interlay section of go_refresh_draw().
16:42.05*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:20.51CIA-63BRL-CAD: 03r_weiss * r46854 10/brlcad/trunk/src/conv/g-vrml.c:
18:20.52CIA-63BRL-CAD: Updated the 'g-vrml' converter. Corrected some bugs in the count of regions
18:20.52CIA-63BRL-CAD: converted and regions attempted. Also added a count of the number of failed due
18:20.52CIA-63BRL-CAD: to bombs. Changed the logic so that if errors occur during conversion, the
18:20.52CIA-63BRL-CAD: conversion will continue and at the end report the number of errors.
18:33.22CIA-63BRL-CAD: 03bob1961 * r46855 10/brlcad/trunk/src/libdm/dm-wgl.c: Fix a cut-n-paste error.
18:33.37*** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl)
19:41.56abhi2011is there a macro for testing if a floating point value is exactly 0
19:42.00abhi2011not just near 0
19:42.14abhi2011or is fabs(f) == 0 the only option
20:05.01brlcadabhi2011: there is no way you can portably guarantee that a floating point value is exactly 0
20:05.34brlcadrelying on that usually implies a flaw in the math/logic that doesn't account for the actual nature of floating point math
20:06.58brlcadfabs(f) == 0 isn't necessarily reliable either (and doesn't address the issue of wanting to rely on zeroness)
20:08.19abhi2011well I want to check if the passed mass is 0
20:08.22abhi2011by the user
20:08.54brlcadso check with ZERO(), what's the issue?
20:09.16abhi2011ok, there is a line about it not being recommended in the comments
20:10.15brlcadwell it's not recommended, but it's certainly better than trying to fake it with things like fabs(f) == 0 :)
20:10.32abhi2011yup, stuck that into the code now
20:10.51brlcadthe issue is that you haven't defined how close to zero you have to be
20:11.07abhi2011yeah, the epsilon
20:11.14brlcadthat's why it recommends against it (instead favoring NEAR_ZERO() with the tolerance defined)
20:11.32brlcadis 0.0000000000000000001 "close enough"?
20:11.54brlcadhow about 6 zeros, 3 zeros, 1 zero? ..
20:12.05abhi2011ok, hehe yeah, bullet wroks with sngle point precision so it should be  :P
20:12.50brlcadZERO() still uses a tolerance
20:13.12abhi2011yes it used near_zero(), well i think the less than and greater than comparisons should be fine
20:13.27abhi2011for the == stuff ZERO() is good enuf
20:13.30brlcadit just uses a hard-coded platform-varying tolerance that should roughly equate to "roughly as precise as this hardware is capable of being" ..
20:13.38abhi2011ah nice
20:13.43brlcadwhich is often not what the math actually affords, that makes it dangerous
20:14.52brlcadthe hardware may be capable of 1e-40, but if you take a square root of something a few times, or use single precision, or pass through print specifiers, or divide, or ... you might end up with a "zero" 1e-7
20:15.02brlcadand ZERO() will be false
20:17.43brlcadif bullet uses single precision (really? wtf..)
20:17.55brlcadthen you should probably define your tolerance
20:18.15brlcadsingle precision is much looser than most hardware is cabable of ...
20:19.01brlcadI'd suggest something like 0.001
20:19.23brlcadthat's roughly sqrt(FLT_EPSILON)
20:20.15brlcad0.0005 if you want to be consistent with the rest of BRL-CAD
20:21.17abhi2011ok
20:21.25abhi2011yes, bullet can be set to double precision
20:22.00brlcadthat'd probably be better as a default
20:22.15brlcadmaybe have a -f fast flag that will use single precision instead
20:23.20abhi2011right ok, btw if 0.0005 is default , there should be a constant that defines it
20:24.25abhi2011will have a look at vmath.h
20:25.08abhi2011hmm ok FLT_EPSILON & DBL_EPSILON
20:48.23CIA-63BRL-CAD: 03abhi2011 * r46856 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h):
20:48.23CIA-63BRL-CAD: modified simulation code to persist velocities between each simulation step Now
20:48.23CIA-63BRL-CAD: bullet does a single step of simulation and saves the state of rigid bodies as
20:48.23CIA-63BRL-CAD: well as updates the transforms in the dbthis will allow rt to shoot rays in the
20:48.23CIA-63BRL-CAD: updated model
21:02.08brlcadabhi2011: it's not a constant globally defined for that tolerance, each application defines the tolerance
21:02.43brlcadin your case, you're running as a libged command, so you can just use whatever tolerance is presently set
21:02.49brlcad``Erik: http://brlcad.org/tmp/rtvstie.png
21:03.26brlcadlots of off-by-many on that center poly
21:05.08brlcadabhi2011: ged_wdbp->tol->dist is there the current tolerance should be stashed
21:26.31*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
22:01.20*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
22:33.52*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
22:55.06CIA-63BRL-CAD: 03abhi2011 * r46857 10/brlcad/trunk/src/libged/simulate/simulate.c: fixed a crash due to usage of memory before mallocing it
23:31.32*** join/#brlcad sparrW (~kvirc@pdpc/supporter/active/sparr)
23:47.56brlcad277MB step file churning away... giggity
IRC log for #brlcad on 20110923

IRC log for #brlcad on 20110923

00:35.41louipcwhoa
02:27.00brlcad102480 surface edges, 27195 edge loops, 51393 edge curves, 18359 advanced faces, 10015 cylindrical surfaces, 2691 bspline surfaces, ...
02:56.31CIA-63BRL-CAD: 03brlcad * r46858 10/brlcad/trunk/src/librt/db_match.c: get rid of the stupid BU_ASSERTING, they're really just UNUSED.
02:56.50CIA-63BRL-CAD: 03brlcad * r46859 10/brlcad/trunk/src/librt/prep.c: client_data isn't actually UNUSED..
02:58.15CIA-63BRL-CAD: 03brlcad * r46860 10/brlcad/trunk/src/librt/ (db_match.c prep.c): ws consistency cleanup
03:11.28CIA-63BRL-CAD: 03brlcad * r46861 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: hit_count is potentially used prior to initialization, account for it and all of his friends by initializing to zero/null.
03:15.19CIA-63BRL-CAD: 03brlcad * r46862 10/brlcad/trunk/src/librt/primitives/ (ehy/ehy.c epa/epa.c hyp/hyp.c rpc/rpc.c submodel/submodel.c): remove a slew of BU_ASSERT hacks that were only added to quell use warnings. use the UNUSED() macro for betterness.
03:15.57CIA-63BRL-CAD: 03brlcad * r46863 10/brlcad/trunk/src/libgcv/bottess.c: someone was just kidding, tol isn't really unused
03:44.09CIA-63BRL-CAD: 03brlcad * r46864 10/brlcad/trunk/src/libged/push.c: curtree is actually used. hard to miss it.
04:11.21CIA-63BRL-CAD: 03brlcad * r46865 10/brlcad/trunk/include/nmg.h: not your responsibility to define NULL and it's a crappy definition anyways.
05:12.06CIA-63BRL-CAD: 03brlcad * r46866 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: more unused LIARS
05:14.57CIA-63BRL-CAD: 03brlcad * r46867 10/brlcad/trunk/src/liboptical/ (sh_air.c sh_light.c): and a few more checks added for quellage, but they're really UNUSED
05:28.59CIA-63BRL-CAD: 03brlcad * r46868 10/brlcad/trunk/src/ (mged/dodraw.c remrt/remrt.c): couple more UNUSED tricksters
05:32.28CIA-63BRL-CAD: 03brlcad * r46869 10/brlcad/trunk/include/common.h:
05:32.28CIA-63BRL-CAD: add a new IGNORE() macro for use by all of the various macros that turn into
05:32.28CIA-63BRL-CAD: 'nothing' if the right compilation flags are set. for now, go with a simple
05:32.28CIA-63BRL-CAD: '(void)param' to quell unused usage warnings but begs testing on msvc2010.
05:32.28CIA-63BRL-CAD: while we're at it, mangle parameters marked as UNUSED() with a prefix so we can
05:32.28CIA-63BRL-CAD: catch failings in both directions, catching instances where UNUSED() was
05:32.29CIA-63BRL-CAD: erroneously set yet the parameter is actually used.
05:34.39CIA-63BRL-CAD: 03brlcad * r46870 10/brlcad/trunk/include/ (bu.h magic.h raytrace.h):
05:34.39CIA-63BRL-CAD: put the new IGNORE() macro to use in place of (void)0 since we were still
05:34.39CIA-63BRL-CAD: getting strict warnings about parameters not being used because they were only
05:34.39CIA-63BRL-CAD: being used in ifdef sections or CK macros. IGNORE() shouldn't be used in
05:34.39CIA-63BRL-CAD: application code, but these bombing/checking macros are perfect use cases.
05:37.06brlcadwhew, finally got all of them
05:43.38*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
07:13.28brlcadboo, hiss .. step import churned and churned but only a few things came in
07:13.42brlcadand the few that did come in aren't looking so hot
07:13.56brlcadwanders
08:24.42*** join/#brlcad dli_ (~dli@dsl-173-248-196-72.acanac.net)
09:43.08*** join/#brlcad dli_ (~dli@dsl-173-248-235-17.acanac.net)
12:54.32abhi2011i have been getting this stranger error whenever I try to include raytrace.h in simphysics.cpp
12:55.30abhi2011the error is : /home/abhi/socis/brlcad/include/brep.h:36:23: fatal error: opennurbs.h: No such file or directory
12:56.21abhi2011raytrace.h:47 > rtgeom.h:42:0, > brep.h
12:56.53abhi2011this is because now I am trying to do librt stuff inside the cpp file
12:57.33abhi2011I need to use rt for detecting overlaps and generate contact points,  but I  do not want to that in the simulate.c file
12:58.08abhi2011so I am going to transforms the objects into their new position in the db and then shoot rays within functions defined in the cpp file
12:58.46abhi2011but it seems that the minute i try to include raytrace.h in the cpp file the build breaks :(
13:00.39abhi2011i of course need raytrace.h included to have access to rt_matrix_transform() to position the simulated objects, after each physics step
13:40.39``Erikprobably means an omission from the cmake/automake file about legitimage paths... though this does expose something; rt_matrix_transform might be better placed as bn_matrix_transform O.o
14:12.10brlcadrt_matrix_transform isn't just a general matrix function
14:12.23brlcadit applies that matrix and writes it out on specified geometry
14:13.10brlcadthe db internal geometry is transformed, not the matrix
14:19.12brlcadabhi2011: so you're somehow missing a common include directory (src/other/opennurbs)
14:19.42brlcadwhat does "make VERBOSE=1" output (pastebin)?
14:27.30``Erikrt_write_matrix(bn_matrix_transform(m)); ?
14:29.47``Erik(symbol documentation, I spew what I assume as a reasonably knowledgeable codemonkey)
14:31.32brlcadthat's my point, there is no transform being done on a matrix
14:31.46brlcadso it's just be a rename to rt_write_matrix perhaps
14:32.05brlcadrt_apply_matrix() is probably more apt
14:32.17brlcadsince it won't necessarily "write" anything
14:33.38*** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav)
14:35.30``ErikI'm in favor of renaming that function, fwiw
14:39.07CIA-63BRL-CAD: 03starseeker * r46871 10/brlcad/trunk/src/libged/CMakeLists.txt: Add the opennurbs include dir to libged's include list
14:40.32starseekerabhi2011: give that a shot
14:42.05brlcadstarseeker: it seems backwards (and it's not your fault, autotools is also to blame) to have to list include dirs like that
14:44.20brlcadthink there should be top-level BU_CPPFLAGS, RT_CPPFLAGS, etc or BU_INCLUDE_DIRS, RT_INCLUDE_DIRS, etc that have those interface paths defined, then lower-level CMakeLists.txt files would just use them if they use the library
14:44.50brlcadotherwise we're just going to end up with "include everything all the time" and that's not very useful or safe
14:45.38starseekerdisagrees - i never liked those vars in autotools, it made it difficult to see where a particular directory was coming from in the logic
14:45.50starseekertoo much obfuscation
14:46.13brlcadthe alternative is excessive replication
14:46.41starseekerhow bad is that, really though?
14:46.51starseekeronce set up, the changes aren't too bad
14:47.00starseeker(this one was a straightforward one-liner)
14:47.24brlcadshort term gain, long term cost (like any code duplication)
14:47.30brlcadchange one of them
14:47.35starseekerif this had happened with toplevel vars, I would have had to track back through to see what the toplevel vars contained and which one might be a logica candidate for this dir...
14:47.49brlcadyou have to find the 400+ instances it's used (or dozens if it's per dir)
14:48.04brlcaddoesn't have to be top-level vars
14:48.24brlcadin terms of encapsulation, it's make more sense for the libs to define their needs
14:49.21brlcadthink of libbu as its own product, it'd declare cppflags that included tcl, for example .. but users of libbu just use libbu's declared interface
14:50.10brlcadthat wasn't done for autotools because it wasn't easily doable with our recursive automake setup, so the variables propagated up to the top
14:50.17brlcadfor cmake, that's not the case
14:50.58starseekerconcedes the point, but still doesn't like the idea of "what gets included" being buried so deep - it feels like C++, digging through layers to find an int at the bottom of the type pile...
14:54.16starseekerbut I always lose these arguments ;-), so let's see... how to do it... probably the BU_INCLUDE_DIRS approach would be best...
14:54.24brlcadanother way to look at it -- just about every app (400+) uses librt which uses libbu which results in *always* needing paths for zlib, regex, tcl, opennurbs, .. always needing to include ${ZLIB_INCLUDE_DIR},  ${REGEX_INCLUDE_DIR}, ${TCL_INCLUDE_DIRS}, ${OPENNURBS_INCLUDE_DIR}
14:54.58starseekernods - yeah, it would be a LoC reduction, no question
14:55.08brlcadthere are minimally about 50 source dirs where those have to be specified
14:55.36brlcadadd one more, rename one, remove one ... that's 50+ edits
14:55.47brlcadmassive DRY fail :)
14:58.18starseekerI'm going to do one additional thing though, if I introduce the BU_INCLUDE_DIRS style mechanisms - I'm going to build a list of dirs and then remove duplicates before the actual include command, to try and keep the command line verbosity down...
15:08.24brlcadyeah, that'd be awesome
15:08.35starseekerblinks in surprise - apparently libbu doesn't use regex
15:09.25brlcadlibrt
15:09.35starseekernods
15:10.01starseekerI knew it was in there, just a little startled it hasn't crept down to the libbu level yet
15:10.23starseekerwould have thought some sort of regex something or other would have been packaged up for general consumption by now ;-)
15:10.31brlcadanother benefit of the encapsulation, catch issues like that more obviously so you don't include regex by default everywhere bu is used
15:11.06brlcadregex it is needed, but indirect
15:11.09brlcadbu -> tcl -> regex
15:11.28brlcadso tcl should have it specified in tcl's include dirs
15:11.35starseekernods
15:12.18brlcadlast night was a good coding night, trying to get some new libbu interfaces in place
15:12.34starseekersweet
15:13.24brlcadbetter string management to help with processing object names and lists of objects (which all of libged could use)
15:13.47brlcadbasic things that makes one slap the forehead and ask why they weren't there 10 years ago
15:14.04brlcadbut some more complex ones too, like globbing
15:14.16starseekersomething beyond fnmatch?
15:14.21brlcadyep
15:15.01starseekerthat would be awesome - I'd love to be able to do per-command globbing on mged command line to avoid having to quote the bejeezus out of search commands...
15:15.03brlcadbasically a corollary to glob(3)
15:15.16brlcadincluding a mechanism for iterating
15:28.32CIA-63BRL-CAD: 03starseeker * r46872 10/brlcad/trunk/src/ (3 files in 3 dirs): Start figuring out how to wrap includes needed for a directory into a variable and use that variable in other CMakeLists.txt files that are including the library
15:48.38brlcadhm, careful use there -- BU_INCLUDE_DIRS only needs to include headers used by the public headers
15:49.00brlcadimplementation headers don't need to be included, they're still just regular include_dirs()
15:49.24*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
15:50.11brlcaduce-dirent, png  being the two examples not publicly used
15:50.47brlcadzlib too, hm!
15:51.09brlcadthose are INCLUDE_DIRS like regex, needed by src/other stuff
15:52.20brlcadopennurbs, png, and tkpng use zlib
15:55.48brlcaddoesn't look like anything uses png publicly
15:56.20brlcadbu, fb, dm, ged, tclcad, and a few util tools use it privately
16:53.22abhi2011brlcad: here is the verbose build output : http://bin.cakephp.org/view/1626192759
16:54.17abhi2011ah ok, just saw starseeker's update, will try it
17:04.50CIA-63BRL-CAD: 03bob1961 * r46873 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Set zclip flag to 0 in ArcherCore::doLighting.
17:13.00*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
17:25.50abhi2011cool, now the raytrace.h related errors are gone, however I also need to  pass gedp to the functions in simphysics.cpp, so I have included ../ged_private.h in the simulate.h file(as that file declares struct ged in ged.h)
17:26.24abhi2011i get this warning : /home/abhi/socis/brlcad/include/ged.h:2289:78: warning: ‘int ged_view(ged*, int, const char**)’ hides constructor for ‘struct ged_view’
17:27.37starseekerso... once we get tcl out of libbu, we'll have no need for BU_INCLUDE_DIRS?
17:32.12CIA-63BRL-CAD: 03n_reed * r46874 10/brlcad/trunk/src/ (conv/obj-g_new.c libgcv/wfobj/tri_face.c): plugged a few leaks
17:36.49abhi2011hmm I think the warning is coming because ged.h is being compiled by the c++ component of gcc
17:37.09abhi2011otherwise no constructor stuff should have been seen
17:39.08abhi2011i do need the gedp as i get the internal representation of a object using GED_DB_GET_INTERNAL(gedp,....
17:39.17abhi2011in the cpp file
17:39.38abhi2011however I ll see if I can use just librt instead, so all gedp references can be removed
17:45.13CIA-63BRL-CAD: 03starseeker * r46875 10/brlcad/trunk/src/ (4 files in 2 dirs): Swap in the new obj-g for the old, stop building both.
17:54.51starseekerdidn't realize the current installed layout wasn't ideal... I'm not really sure how much logic would have to be reworked to suport another layout, I was assuming the current layout was *the* layout...
17:56.36starseekerthought the version number in the share subdirectory was to allow for warnings/wipeouts running one version of brlcad and having the root directory set to another version's location... then attempts to get "version x.y.z" data from that direcory would fail despite being set to the wrong directory...
17:58.32starseekerseemed like a nice way to avoid subtle "almost working but it failed" situations...
19:17.24brlcadabhi2011: you should only include ged_private.h if you use something that header provides -- just include ged.h directly
19:18.27brlcadstarseeker: there's still a need for BU_INCLUDE_DIRS -- it's presently just the top-level include dir
19:19.04brlcadyour logic that eliminates duplicates will take care of keeping only one instance, while letting bu-only and rt-only apps to behave correctly
19:20.47brlcadstarseeker: having the versioned sub-directory does help with multi-version installs, that was also intentional
19:21.50brlcadbut the fact that it's only the datadir wasn't -- the goal was fully versioned installs into a NON-VERSIONED root directory (like /usr)
19:25.09brlcadhaving separation of BRLCAD_DATA and BRLCAD_ROOT provides similar multi-redundancy protections from using the wrong data
19:25.23brlcadshould probably just write this all up on the wiki
19:36.20brlcadn_reed: a cleanup chare, should mark all of the non-public functions as static in wfobj
19:36.59n_reedconsider it done
19:37.58n_reedalthough HIDDEN would be better right?
19:38.16brlcadif there is value in being able to debug into that function, sure
19:38.38brlcadnot for front-end code, that should use static
19:38.58brlcadbut library funcs can use either -- HIDDEN for public API and discretion for non-public
19:42.58n_reedtrying to understand... so the point of HIDDEN is just to allow toggling static-ness
19:49.42CIA-63BRL-CAD: 03n_reed * r46876 10/brlcad/trunk/ (doc/docbook/system/man1/en/obj-g.xml src/conv/obj-g.c): some updates to obj-g documentation
19:56.39starseekererm.  the top level include dir I've been including in *all* of src via the src/CMakeLists.txt file...
19:58.55brlcadn_reed: basically
19:59.50brlcadsome compilers will fully inline static functions at their discretion, making it impossible to set a breakpoint for debugging
20:00.56brlcadso if there is any value at any time to be able to debug into that function as a breakpoint (which there is for most public API, by definition), then HIDDEN should be used instead of static
20:03.05brlcadcoincidentally, it also helps to avoid function name ambiguity by not allowing implementation-detail functions to have the same name as front-end application functions
20:03.43brlcadhelps ensure functions are properly named with some non-conflicting prefix or other name convention
20:09.22*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:30.21CIA-63BRL-CAD: 03starseeker * r46877 10/brlcad/trunk/src/ (7 files in 7 dirs): Make another try at include_dirs updates...
20:30.42starseekerbrlcad: that more what you had in mind?  (before I go any further...)
20:34.40brlcadstarseeker: yeah, that's looking great
20:36.01starseekerk.  actually kinda handy that I was including the toplevel include in src - taking it out makes for a very simple "fail because I'm not converted yet" situation :-)
20:36.16brlcadalso makes a couple low-lying fruit obvious, things that should get fixed
20:36.31brlcadlike libfb needing to include pkg.h .. stupid
20:36.52brlcadshould be hidden in the impl or passed by the caller
20:37.10brlcadit's for just one pointer
20:40.31starseekerI realize it's a bit premature, but with the "every command in libged being a plugin" approach, will the policy be that headers included by the individual commands not be part of the required includeds at the toplevel?  Or, put another way, can we require that any include dir needed for ged users be specified at the toplevel ged CMakeLists.txt and not in the command subdirectories?
20:45.21CIA-63BRL-CAD: 03starseeker * r46878 10/brlcad/trunk/src/ (3 files in 3 dirs): Convert a few more directories to new include_dir scheme
20:52.26starseekerman liborle is so small it's hardly even there...
20:53.23starseekerwonders if that could fold entirely into something else like libicv...
21:28.43brlcadthat's just sad..
21:29.22brlcadcame across some old tcl code in some old directory in my data archive
21:30.27brlcadmy fingerprints are all over it .. naming conventions, code structure, style .. and sure enough my name is in one of the files as the author
21:31.02brlcadbut it took a solid 10 minutes of actually running the code, seeing the gui that pops up, poking on it to even have a glimmer of memory doing that
21:33.07brlcad(it was an inteface for shooting rays at geometry, plotting the hit points (similar to nirt), and providing the option to create actual geometry for the hit points (spheres) and path segments (cylinders/arb8s) .. which someone had requested at some point)
21:35.38starseekerhmm, nifty
21:35.45brlcadstarseeker: liborle and the two tools that use it can be deprecated, but they've just not been a maintenance burden to even bother
21:35.46starseekersurprised it didn't get rolled into mged
21:35.53brlcadit wasn't completed
21:35.58starseekerah
21:36.15starseekerbrlcad: is code tidiness a sufficient motive to depricate? :-P
21:36.19brlcadthe gui is actually pretty far along
21:36.21starseekerdeprecate even
21:37.50brlcad*shrug*, if you want to both go for it, but there are *hundreds* of code tidiness issues like that such that it's been plenty enough as-is to just deprecate when they incur some cost (like a build failure that might take more than 10 seconds to fix)
21:38.30brlcaddeprecating has a cost too .. those little 10 minute activities add up with context switching :)
21:38.32starseeker<snort> in this case, it's just rewriting the CMake logic for liborle everytime a paradigm change takes place - once that stops, I suppose i twon't matter
21:38.46brlcadthat's a maintenance cost actually
21:39.14brlcadso if you deprecate now, they could go when autotools goes
21:39.33brlcadthen you don't even have to worry, let autotools build and yank the cmake
21:39.40starseekernods - let me check which tools those are... - src/util I presume?
21:39.48brlcadfb and util
21:41.10brlcadthat goes MUCH farther back than my tcl discovery today, but i *think* it used to be a hand-rolled rle library that was replaced when urtoolkit's librle came out
21:42.08CIA-63BRL-CAD: 03starseeker * r46879 10/brlcad/trunk/doc/deprecation.txt: list liborle and corresponding tools for deprecation
21:42.15brlcadnew tools were written but the old ones were kept around for some reason that's been lost in time (probably out-perform)
21:42.22starseekernods
21:42.47starseekerhas yet to use *any* of the rle utils at all... guess I just haven't needed 'em yet
21:42.53brlcadshould put the version too
21:43.05starseekerhmm?
21:43.22starseekeroh
21:43.32starseeker7.20?
21:43.35brlcadnods
21:44.05CIA-63BRL-CAD: 03starseeker * r46880 10/brlcad/trunk/doc/deprecation.txt: add version
21:44.51brlcadthat's so deprecations can be cherry-picked into the obsolete section with just a copy-paste
21:46.00CIA-63BRL-CAD: 03starseeker * r46881 10/brlcad/trunk/src/ (8 files in 8 dirs): Add a few more to the 'converted' list for include dirs - got a ways to go, pretty far reaching change.
21:46.39brlcadstarseeker: since there are binaries going away, they get a statement too (see src/util/dbcp.c)
21:47.04starseekereach one gets a statement?
21:47.27brlcadso a message is printed when run
21:47.34starseekeroh, gotcha
21:47.42starseekernot in doc/deprecation, but in the C code itself
21:47.43brlcaddoesn't have to be the same message as dbcp's, but should be something similar
21:47.47brlcadright
21:48.11brlcaddoc/deprecation is meant to let devs know -- if a tool is going to disappear, we just put a statement in the tool
21:48.58brlcad(and in doc/deprecation, but users just aren't likely to or expected to look there .. they just use the tools they know)
21:49.04brlcadwould be good to point them to the new tools
21:49.09CIA-63BRL-CAD: 03starseeker * r46882 10/brlcad/trunk/src/fbserv/CMakeLists.txt: that was easy... convert fbserv to new includes
21:49.16brlcad"Use rle-fb instead!"
21:51.10brlcadbeen consistently using the marker DEPRECATED for both dev code comments and user printing statements
21:51.17brlcadso they're all easy to find
21:51.36starseekerdo I need to support the D option?
21:52.40starseekerinteresting - fb-orle's usage statement says fb-rle
21:55.35CIA-63BRL-CAD: 03n_reed * r46883 10/brlcad/trunk/src/libgcv/wfobj/ (6 files): interface cleanup, including hiding local functions
21:57.27CIA-63BRL-CAD: 03starseeker * r46884 10/brlcad/trunk/src/ (fb/fb-orle.c fb/orle-fb.c util/orle-pix.c util/pix-orle.c): Add deprecation warning messages to the fb and pix tools pertaining to orle.
21:59.40*** join/#brlcad dli (~dli@dyn-157-046.wireless.concordia.ca)
22:14.48CIA-63BRL-CAD: 03starseeker * r46885 10/brlcad/trunk/src/ (5 files in 5 dirs): Convert a few more include dir lists.
23:10.58*** join/#brlcad dli (~dli@dyn-157-046.wireless.concordia.ca)
23:16.57CIA-63BRL-CAD: 03abhi2011 * r46886 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): Moved position transformation functions into simphysics.cpp and rearranged some code to fit in a call to rt
23:42.56*** join/#brlcad dli (~dli@dyn-157-046.wireless.concordia.ca)
IRC log for #brlcad on 20110924

IRC log for #brlcad on 20110924

00:16.12*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
00:16.40*** join/#brlcad dli (~dli@dyn-157-046.wireless.concordia.ca)
03:06.22*** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ)
03:10.44*** join/#brlcad CIA-54 (~CIA@cia.atheme.org)
03:11.44*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
03:35.50CIA-54BRL-CAD: 03starseeker * r46887 10/brlcad/trunk/ (18 files in 18 dirs): A pattern emerges - time for a macro. 4 lines to one line.
04:33.25*** join/#brlcad dli (~dli@66.49.232.173)
09:18.59*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:04.24*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
20:54.47starseek1rhah - grapviz high level view of BRL-CAD's build system:  http://bzflag.bz/~starseeker/brlcad_build_graphviz.png
21:16.18*** join/#brlcad dli (~dli@66.49.232.173)
23:29.31*** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl)
IRC log for #brlcad on 20110925

IRC log for #brlcad on 20110925

00:08.59*** join/#brlcad Otto_ (~Otto@cpe-24-210-25-11.columbus.res.rr.com)
01:15.37brlcadstarseeker: what do the lines represent?
01:21.39starseekeryou mean the lines in the macro?  they're the duplication elimination and setting values in the cache to allow use of the include dirs in other locations
01:21.58starseekeroh, the graphic
01:22.09starseekerbuild dependency information
01:22.31starseekerlibraries and executables (they don't include custom targets, at least for now)
01:22.55starseekerso a line between two nodes means one depends on the other during build
01:25.07brlcadhm, a bit more chaotic than I'd expect actually
01:25.43brlcador just a very poor default layout ..
01:26.13brlcadneat though
01:26.55brlcadmaybe a different layout scheme, not radial .. what's digraph look like?
02:14.15starseekerdigraph?
02:14.51starseekerbrlcad: if you want to play with it, you can generate it with cmake .. --graphviz=brlcad.dot
02:17.29starseekeroriginal svg file is here: http://bzflag.bz/~starseeker/brlcad.svg
02:19.51*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
03:47.01brlcadstarseeker: digraph is an alternate graph style used for directed graphs
07:35.11CIA-54BRL-CAD: 03starseeker * r46888 10/brlcad/trunk/src/ (28 files in 28 dirs): Not sure the sets are absolutely correct, but this should be most of the remaining conversion to the new include_directories setup
07:39.10CIA-54BRL-CAD: 03starseeker * r46889 10/brlcad/trunk/bench/CMakeLists.txt: bench's pixdiff uses libbu
11:24.30*** join/#brlcad kunigami_ (~kunigami@201.82.92.180)
13:07.35*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-185-172.wlan.tudelft.nl)
13:08.29abhi2011hmm ran into some issues the minute I moved the transformation code for transforming objects in the db , into the cpp file
13:09.06abhi2011have to make changes in small increments now...lots of functions that have to be called in the correct sequence
17:31.56CIA-54BRL-CAD: 03abhi2011 * r46890 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): fixing some functions after I had to revert back to resolve some positioning issues, modifying the code step by step now
17:32.04*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
17:57.20*** join/#brlcad ibot (~ibot@rikers.org)
17:57.20*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
IRC log for #brlcad on 20110926

IRC log for #brlcad on 20110926

00:02.07*** join/#brlcad dli (~dli@dsl-69-172-118-38.acanac.net)
00:22.18CIA-54BRL-CAD: 03abhi2011 * r46892 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c): ok, now the functions are arranged the way i want it with the physics properly working again, should be able to shoot rays by tomorrow and create contact manifolds
02:31.34*** join/#brlcad dli_ (~dli@dsl-173-248-194-55.acanac.net)
09:10.11*** join/#brlcad ibot (~ibot@rikers.org)
09:10.11*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
09:30.01*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
10:25.58*** join/#brlcad kunigami_ (~kunigami@201.82.92.180)
11:02.41*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-097.wlan.tudelft.nl)
11:17.17CIA-54BRL-CAD: 03tbrowder2 * r46893 10/brlcad/trunk/doc/docbook/create-book-covers.pl: add prog to generate book covers for pdf
11:24.03*** join/#brlcad abhi2011_ (~chatzilla@wlan-145-94-186-097.wlan.tudelft.nl)
11:25.20*** join/#brlcad CIA-48 (~CIA@cia.atheme.org)
12:22.00CIA-48BRL-CAD: 03tbrowder2 * r46894 10/brlcad/trunk/doc/docbook/Makefile.am: add special non-auto-build target for pdf cover generation and testing
12:49.53*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:20.17CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3170 10/wiki/User:Abhijit: /* Log */
13:24.37CIA-48BRL-CAD: 03brlcad * r46895 10/brlcad/trunk/src/conv/Makefile.am: obj-g.c no longer compiles with autotools since libgcv's wfobj sources aren't set up with autotools, so turn it off
14:18.09*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:46.33CIA-48BRL-CAD: 03tbrowder2 * r46896 10/brlcad/trunk/doc/docbook/create-xml-catalogs.pl: add more rewrite rules for xsl locations
15:47.55CIA-48BRL-CAD: 03tbrowder2 * r46897 10/brlcad/trunk/doc/docbook/Makefile.am: add more defs and rules for making a test pdf doc with covers
15:49.21brlcadstarseeker: heh, you
15:49.29brlcadyou're going to have your work cut out for you!
15:49.33CIA-48BRL-CAD: 03tbrowder2 * r46898 10/brlcad/trunk/doc/docbook/dummy.xml: add short DB source file for testing pdf covers
15:50.31brlcadtbrowder's putting in quite an elaborate document processing build system -- it'll be interesting to get that converted to a build script or (eek) cmake logic
15:50.32CIA-48BRL-CAD: 03tbrowder2 * r46899 10/brlcad/trunk/doc/docbook/book-covers-fo-template.xsl: add covers template
15:52.29CIA-48BRL-CAD: 03tbrowder2 * r46900 10/brlcad/trunk/doc/docbook/brlcad-fo-stylesheet-covers.xsl: add master stylesheeet for DB with covers; location is temporary during initial cover testing
15:56.39CIA-48BRL-CAD: 03tbrowder2 * r46901 10/brlcad/trunk/doc/docbook/brlcad-gendata.xsl: add a stylesheet with common definitions--temporary location during initial covers testing; final location for all stylesheets will be ./resources/brlcad
16:03.00CIA-48BRL-CAD: 03tbrowder2 * r46902 10/brlcad/trunk/doc/docbook/ (. create-book-covers.pl create-index.pl validate.pl): add ignored files
16:38.57CIA-48BRL-CAD: 03brlcad * r46903 10/brlcad/trunk/doc/docbook/ (18 files in 10 dirs): using the application/xml mime puts subversion into binary-diff mode so we don't get to see the diff contents. convert to text/xml instead like our other xsl files, setting the eol-style to native while we're at it.
16:46.20CIA-48BRL-CAD: 03brlcad * r46904 10/brlcad/trunk/doc/docbook/ (10 files in 4 dirs): make all of our xml files use text/xml as their mime-type
16:50.58CIA-48BRL-CAD: 03starseeker * r46905 10/brlcad/trunk/src/ (conv/step/CMakeLists.txt other/CMakeLists.txt): Add (commented out, for now) logic to use generated files from fedex_plus instead of static files
17:13.19*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
17:25.33CIA-48BRL-CAD: 03erikgreenwald * r46906 10/brlcad/trunk/src/libgcv/bottess.c: begin single face splitting
19:05.14CIA-48BRL-CAD: 03erikgreenwald * r46907 10/brlcad/trunk/src/libgcv/bottess.c: kill some debugging stuff. mark actual vertex in vertex/intersectpt test.
20:35.43CIA-48BRL-CAD: 03brlcad * r46908 10/brlcad/trunk/include/bu.h: stub in the preliminary interface declaration for bu_file_glob() prior to definition.
20:48.43CIA-48BRL-CAD: 03bob1961 * r46909 10/brlcad/trunk/ (3 files in 2 dirs):
20:48.43CIA-48BRL-CAD: Added a member to "struct application" for disabling bot normal reversal in
20:48.43CIA-48BRL-CAD: librt/primitive/bot so that hitting a bot would yield, among other things, the
20:48.43CIA-48BRL-CAD: bot's actual normal. With "bot normal reversal" disabled, a ray can be used to
20:48.43CIA-48BRL-CAD: determine if a bot's normal needs to be flipped.
20:54.39CIA-48BRL-CAD: 03bob1961 * r46910 10/brlcad/trunk/src/librt/tcl.c:
20:54.39CIA-48BRL-CAD: Added rt_tcl_rt_set to librt/tcl.c. This adds the ability to get/set the values
20:54.39CIA-48BRL-CAD: of bot_reverse_normal_disabled, onehit and no_bool. Other variables could be
20:54.39CIA-48BRL-CAD: exposed here and the onehit and no_bool subcommands could be deprecated.
21:03.25CIA-48BRL-CAD: 03bob1961 * r46911 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl):
21:03.25CIA-48BRL-CAD: Added bot_flip_check and bot_flip_check_all commands to Archer. bot_flip_check
21:03.25CIA-48BRL-CAD: takes a logfile and a list of bots to be checked for possible flipping. The log
21:03.25CIA-48BRL-CAD: file records whether a bot gets skipped (i.e. if not a volume mode bot), flipped
21:03.25CIA-48BRL-CAD: or not flipped. It also records if the fired ray misses.
21:11.05starseekerstarseeker: eh?
21:11.21starseekerbrlcad: I'm going to have my work cut out for me?
21:11.46starseekeroh, you mean translating all that
21:11.59starseekeryeah, I'm letting it all settle down before I look at it
21:12.53starseekernot real crazy about all the perl, but figure let him get it set up how he wants and then look at how to achieve the effect
21:25.58CIA-48BRL-CAD: 03starseeker * r46912 10/brlcad/trunk/src/ (7 files in 7 dirs): Clean up a little fallout from the new include_dirs setup
21:54.23*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
21:58.35CIA-48BRL-CAD: 03starseeker * r46913 10/brlcad/trunk/src/other/ (CMakeLists.txt step/src/express/CMakeLists.txt): Redo comments a bit in src/other/CMakeLists.txt
22:06.50CIA-48BRL-CAD: 03starseeker * r46914 10/brlcad/trunk/src/other/step/src/express/CMakeLists.txt: oops
22:09.38*** join/#brlcad kunigami_ (~kunigami@201.82.92.180)
22:13.56brlcadstarseeker: given everything it depends on and assumes, it's almost guaranteed to required a unix environment so the best path is probably to just wrap it all in a script and call that if Perl and a posix shell are detected
22:32.07CIA-48BRL-CAD: 03brlcad * r46915 10/brlcad/trunk/CMakeLists.txt: remove trailing ws
22:41.52CIA-48BRL-CAD: 03brlcad * r46916 10/brlcad/trunk/Makefile.am: ws
22:58.18CIA-48BRL-CAD: 03brlcad * r46917 10/brlcad/trunk/ (38 files in 22 dirs): (log message trimmed)
22:58.19CIA-48BRL-CAD: consistently use 0.0005 for a default distance tolerance and 1e-6 for a default
22:58.19CIA-48BRL-CAD: perpedicularity tolerance throughout BRL-CAD. over time, a default of 5e-3 and
22:58.19CIA-48BRL-CAD: 5e-4 have been used for the distance tolerance with the latter used in more
22:58.19CIA-48BRL-CAD: places; similarly 1e-5 and 1e-6 for perpendicularity. choosing the more
22:58.19CIA-48BRL-CAD: prevalent and tighter bounds for both which constitute a default nearness
22:58.20CIA-48BRL-CAD: tolerance of approximately 1/2000ths of 1mm. that is just under the sqrt of
22:59.43CIA-48BRL-CAD: 03brlcad * r46918 10/brlcad/trunk/src/fb/polar-fb.c: missed one tolerance straggler
23:52.30*** join/#brlcad kunigami_ (~kunigami@201.82.92.180)
IRC log for #brlcad on 20110927

IRC log for #brlcad on 20110927

01:12.12CIA-48BRL-CAD: 03tbrowder2 * r46919 10/brlcad/trunk/doc/docbook/ (7 files in 2 dirs): various error corrections to get a working test cover
01:47.31starseekerbrlcad: we've got a conflict on Windows between winbase.h(1090) IGNORE and common.h(251) IGNORE macros
01:52.43brlcadstarseeker: no problem, we can just undef IGNORE before including windows then redef
02:33.23CIA-48BRL-CAD: 03starseeker * r46920 10/brlcad/trunk/ (3 files in 3 dirs): Add a couple more includes that slipped through the cracks and showed up on Windows, plus make a stab at squashing the conflicting definition warning between winbase.h(1090) IGNORE and common.h(251) IGNORE macros.
03:12.21starseekerhuh, cool:  http://clucene.sourceforge.net/
03:39.46CIA-48BRL-CAD: 03brlcad * r46921 10/brlcad/trunk/include/common.h: if IGNORE is already defined, say so and take control
03:41.35CIA-48BRL-CAD: 03brlcad * r46922 10/brlcad/trunk/include/bio.h: don't repeat yourself. stash the IGNORE macro definition and restore it later since windows api defines their own
03:59.35brlcadthat is pretty nifty
04:00.04brlcadsomething the GS could potentially utilize later next year or after
04:08.02CIA-48BRL-CAD: 03brlcad * r46923 10/brlcad/trunk/include/bio.h: do it proper. only need the IGNORE protection if it's defined (which it _usually_ should be but there is no guarantee).
04:26.01CIA-48BRL-CAD: 03brlcad * r46924 10/brlcad/trunk/src/conv/g-obj.c: ws style indent comment cleanup
05:09.29CIA-48BRL-CAD: 03brlcad * r46925 10/brlcad/trunk/include/bn.h: expand macros for initializing and inspecting a bn_tol struct with doxygen comments
05:32.30CIA-48BRL-CAD: 03brlcad * r46926 10/brlcad/trunk/include/ (CMakeLists.txt Makefile.am tol.h):
05:32.30CIA-48BRL-CAD: add a new tol.h header to librt in the style of the new header groupings (albeit
05:32.30CIA-48BRL-CAD: not fully realized until RT_EXPORT is broken out) that declares a new
05:32.30CIA-48BRL-CAD: rt_tol_default() function for obtaining/initializing a tolerance struct with
05:32.30CIA-48BRL-CAD: geometry tolerances common to librt geometry processing (namely, 0.0005 dist tol
05:32.31CIA-48BRL-CAD: and 1e-6 perp tol).
05:34.00CIA-48BRL-CAD: 03brlcad * r46927 10/brlcad/trunk/src/librt/ (CMakeLists.txt Makefile.am tol.c):
05:34.01CIA-48BRL-CAD: add the initial implementation of rt_tol_default() used for returning a
05:34.01CIA-48BRL-CAD: librt-centric tolerance structure useful for geometry processing so we don't
05:34.01CIA-48BRL-CAD: have the issue of hard-coded tolerance values all over the package that get out
05:34.01CIA-48BRL-CAD: of sync over time.
06:15.48*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:50.26*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
09:39.09*** join/#brlcad kunigami_ (~kunigami@201.82.92.180)
13:22.24CIA-48BRL-CAD: 03tbrowder2 * r46928 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeI.xml: change root element to book--required to get a cover in the pdf file
16:17.44*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
16:56.04CIA-48BRL-CAD: 03tbrowder2 * r46929 10/brlcad/trunk/doc/docbook/dummy.xml: correct file format for book and cover
17:15.09CIA-48BRL-CAD: 03bob1961 * r46930 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Updated Archer::bot_flip_check to fire another ray if the first one missed. This time use points from the first triangle to compute the start and target points.
19:12.56CIA-48BRL-CAD: 03indianlarry * r46931 10/brlcad/trunk/src/adrt/isst_tcltk.c: needed "common.h" for build on windows
19:18.25CIA-48BRL-CAD: 03erikgreenwald * r46932 10/brlcad/trunk/src/adrt/CMakeLists.txt: Add OpenGL include dir for issttcltk
21:18.22brlcadfop is a bitch to install via ports, ugh
21:23.53CIA-48BRL-CAD: 03bob1961 * r46933 10/brlcad/trunk/src/mged/mged.c: Supposed to be turning zbuffer back on here.
21:24.13brlcadwell for relative values of bitching, of course .. most ports are downright trivial, but java is a royal pita due to all the custom click-through license agreements (no less than 5 so far)
22:18.28brlcadstarseeker: like how I just volunteered you there?
22:27.11*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
22:38.50*** join/#brlcad kunigami_ (~kunigami@201.82.92.180)
22:43.40*** join/#brlcad dli_ (~dli@dsl-67-55-11-95.acanac.net)
23:20.45*** join/#brlcad Yoshi477 (~jan@d72-39-60-53.home1.cgocable.net)
23:33.20starseekerbrlcad: heh, awesome
23:33.34starseekerfigured
23:34.26starseekeryeah, it's unfortunate that fop is java based, but it's also the *only* open source docbook->pdf tool I know of :-/
23:34.43brlcadno matter, it's all installed now
IRC log for #brlcad on 20110928

IRC log for #brlcad on 20110928

02:27.26starseekerarrgh, gentoo doesn't have fop 1.0
05:14.11*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1096601580.dsl.bell.ca)
06:23.15*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:38.17*** join/#brlcad dli__ (~dli@dsl-69-171-140-58.acanac.net)
10:15.28*** join/#brlcad kunigami_ (~kunigami@201.82.92.180)
11:02.14*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
11:20.24CIA-48BRL-CAD: 03tbrowder2 * r46934 10/brlcad/trunk/doc/docbook/BRLCAD_DOC.pm: mods to pdf cover elements
11:29.20CIA-48BRL-CAD: 03tbrowder2 * r46935 10/brlcad/trunk/doc/docbook/DBPATH.pm.in: need an absolute path for DB cover images for fop
11:35.35CIA-48BRL-CAD: 03tbrowder2 * r46936 10/brlcad/trunk/doc/docbook/resources/brlcad/images/: add new dir for common use images
11:36.16CIA-48BRL-CAD: 03tbrowder2 * r46937 10/brlcad/trunk/doc/docbook/resources/brlcad/images/brlcad-logo-red.svg: new BRL-CAD logo in svg format
11:38.23CIA-48BRL-CAD: 03tbrowder2 * r46938 10/brlcad/trunk/configure.ac: add another dir for DB and fop
11:45.12CIA-48BRL-CAD: 03tbrowder2 * r46939 10/brlcad/trunk/doc/docbook/create-book-covers.pl: mods for a working cover generator
11:53.59CIA-48BRL-CAD: 03tbrowder2 * r46940 10/brlcad/trunk/doc/docbook/DBPATH.pm.in: eliminate dup end value statement
11:55.45CIA-48BRL-CAD: 03tbrowder2 * r46941 10/brlcad/trunk/doc/docbook/create-xml-catalogs.pl: make catalog resolver paths relative; name xml catalog in same dir as resolver
11:57.12CIA-48BRL-CAD: 03tbrowder2 * r46942 10/brlcad/trunk/doc/docbook/book-covers-fo-template.xsl: mods to get a working and decent pdf book cover
12:07.37CIA-48BRL-CAD: 03tbrowder2 * r46943 10/brlcad/trunk/doc/docbook/resources/offo-hyphenation-source-v2.0/ (66 files in 2 dirs): add offo v2.0 source so licenses are available for reference
12:46.11CIA-48BRL-CAD: 03tbrowder2 * r46944 10/brlcad/trunk/doc/docbook/README.DB_authors_notes: special notes and aids for DB authors--may want to rename this file HACKING to parallel the HACKING file for thetop-level dir
12:46.52CIA-48BRL-CAD: 03tbrowder2 * r46945 10/brlcad/trunk/doc/docbook/README: add more on DB processing and supporting files and dirs
14:03.39CIA-48BRL-CAD: 03tbrowder2 * r46946 10/brlcad/trunk/doc/docbook/make-svg.sh: add svg equation tool
14:08.26CIA-48BRL-CAD: 03tbrowder2 * r46947 10/brlcad/trunk/doc/docbook/README: add more info on DB processing, tools, and requirements
14:11.04starseekerbrlcad: http://www.cmake.org/pipermail/cmake/2011-September/046455.html
14:12.08CIA-48BRL-CAD: 03tbrowder2 * r46948 10/brlcad/trunk/doc/docbook/README: add a note on MathML to SVG processing
14:18.34CIA-48BRL-CAD: 03tbrowder2 * r46949 10/brlcad/trunk/doc/docbook/README.DB_authors_notes: clarify that the listitems customization is in the brlcad stylesheets
14:29.02CIA-48BRL-CAD: 03starseeker * r46950 10/brlcad/trunk/CMakeLists.txt: Figure out what Apache FOP version we've got.
14:45.09CIA-48BRL-CAD: 03tbrowder2 * r46951 10/brlcad/trunk/doc/docbook/README: add specific recommendation for fop version 1.0
14:46.13CIA-48BRL-CAD: 03tbrowder2 * r46952 10/brlcad/trunk/doc/docbook/README: add specific recommendation for fop version >= 1.0
14:54.09CIA-48BRL-CAD: 03tbrowder2 * r46953 10/brlcad/trunk/doc/docbook/resources/brlcad/book-covers-fo-template.xsl: move to final location
14:54.36CIA-48BRL-CAD: 03tbrowder2 * r46954 10/brlcad/trunk/doc/docbook/book-covers-fo-template.xsl: move to final location
14:57.21CIA-48BRL-CAD: 03tbrowder2 * r46955 10/brlcad/trunk/doc/docbook/ (6 files in 2 dirs): move xsl files to final location; modify prog to use new location
15:13.58*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:16.04CIA-48BRL-CAD: 03tbrowder2 * r46956 10/brlcad/trunk/doc/docbook/resources/brlcad/images/brlcad-logo-green.svg: add a green logo
15:37.26CIA-48BRL-CAD: 03tbrowder2 * r46957 10/brlcad/trunk/doc/docbook/resources/brlcad/images/ (brlcad-logo-green.svg brlcad-logo-red.svg): correct color values
15:38.10CIA-48BRL-CAD: 03tbrowder2 * r46958 10/brlcad/trunk/doc/docbook/resources/brlcad/images/ (brlcad-logo-blue.svg brlcad-logo-limegreen.svg): add new color choices
15:40.56CIA-48BRL-CAD: 03tbrowder2 * r46959 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-fo-stylesheet-covers.xsl: correct for new file location; add provision for auto color changes
16:01.48brlcadstarseeker: the fact that it's a symbolic link is beside the point
16:02.04brlcadit could just as easily be a data file or text file named as such
16:06.23brlcadwhat is it about build system programmers that make them so resistant to admitting fault or limitations of design ...
16:08.28brlcadthat macro might as well be called "find_file_by_name"
16:08.50brlcada glorified call to fnmatch()
16:57.31CIA-48BRL-CAD: 03brlcad * r46960 10/brlcad/trunk/doc/docbook/Makefile.am: avoid gnu-makeisms by expanding the list manually since we still need to portably build via autotools for a few more releases. cmake should have a better solution.
17:00.26CIA-48BRL-CAD: 03brlcad * r46961 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-xhtml-stylesheet.xsl: seems the base URI path is doc/docbook/resources/brlcad? .. refer to docbook.xsl with a relative path
17:00.40*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
17:04.01CIA-48BRL-CAD: 03brlcad * r46962 10/brlcad/trunk/doc/docbook/Makefile.am: getting an error about 'make[1]: *** No rule to make target all'. Stop.' .. don't yet know who is supposed to be generating that.
17:05.17CIA-48BRL-CAD: 03brlcad * r46963 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-man-stylesheet.xsl: another absolute reference that made compilation unhappy. refer to xsl with relative path. now completes successfully.
17:09.15CIA-48BRL-CAD: 03tbrowder2 * r46964 10/brlcad/trunk/doc/docbook/resources/brlcad/images/ (4 files): add logo svg files in brlcad site palette shadow colors
17:26.11CIA-48BRL-CAD: 03tbrowder2 * r46965 10/brlcad/trunk/doc/docbook/resources/brlcad/book-covers-fo-template.xsl: make cover color a variable input
17:26.59CIA-48BRL-CAD: 03tbrowder2 * r46966 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-fo-stylesheet-covers.xsl: remove incorrect include file
17:27.54CIA-48BRL-CAD: 03tbrowder2 * r46967 10/brlcad/trunk/doc/docbook/BRLCAD_DOC.pm: make cover color a variable input
17:30.28CIA-48BRL-CAD: 03tbrowder2 * r46968 10/brlcad/trunk/doc/docbook/create-book-covers.pl: make cover color a variable; use color code to allow for hex color definition
18:06.28*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:39.19CIA-48BRL-CAD: 03tbrowder2 * r46969 10/brlcad/trunk/doc/docbook/Makefile.am: correct final location of stylesheets
18:47.58CIA-48BRL-CAD: 03tbrowder2 * r46970 10/brlcad/trunk/doc/docbook/Makefile.am: only want first dependency for the commands to operate on
19:09.35*** join/#brlcad FAMULUS (~mark@ool-44c47217.dyn.optonline.net)
19:10.00FAMULUSIn BRL CAD, how do I select menu command with my keyboard?
19:10.06FAMULUSon a mac
19:34.56*** join/#brlcad FAMULUS (~mark@ool-44c47217.dyn.optonline.net)
19:45.22CIA-48BRL-CAD: 03tbrowder2 * r46971 10/brlcad/trunk/doc/docbook/resources/brlcad/ (3 files): updating include references to use the prefix rewrite rules in the catalog
19:46.08CIA-48BRL-CAD: 03tbrowder2 * r46972 10/brlcad/trunk/doc/docbook/fop.xconf.in: updating some font info
19:46.40CIA-48BRL-CAD: 03tbrowder2 * r46973 10/brlcad/trunk/doc/docbook/resources/brlcad/: adding some ignores
20:13.20CIA-48BRL-CAD: 03bob1961 * r46974 10/brlcad/trunk/src/libdm/ (dm-ogl.c dm-wgl.c): Initialize light and zbuffer when creating display manager windows.
20:25.19CIA-48BRL-CAD: 03erikgreenwald * r46975 10/brlcad/trunk/src/libgcv/bottess.c: Detect vertex intersection cases, Stub logic for splitting.
20:26.08CIA-48BRL-CAD: 03bob1961 * r46976 10/brlcad/trunk/src/tclscripts/mged/openw.tcl: Set zbuffer after dm creation.
20:35.12brlcadstarseeker: http://www.gnu.org/s/hello/manual/autoconf/Libraries.html
20:35.41brlcadthe autoconf way does specify a symbol (but that symbol can be "main" if you don't care/know)
20:35.56brlcadtried and true
21:05.17CIA-48BRL-CAD: 03brlcad * r46977 10/brlcad/trunk/TODO: killall is reporting lookup failures
21:50.25*** join/#brlcad kunigami_ (~kunigami@201.82.92.180)
22:27.46*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:33.17*** join/#brlcad kunigami_ (~kunigami@201.82.92.180)
IRC log for #brlcad on 20110929

IRC log for #brlcad on 20110929

00:50.03starseekerbrlcad: yow, there's a lot of perl code for the docbook stuff
00:50.24starseekerdo we go with that or did you want it translated into CMake+xml?
00:51.48starseekerwonders how much of this generation of pages can be done using templates and configure_file...
00:54.00starseekersets up the autotools build to see what is being done...
00:55.01starseekerprefers not to rely on perl if we don't have to... don't think there's anywhere else we need it...
00:57.58starseekerbrlcad: http://www.cmake.org/pipermail/cmake/2011-September/046475.html
01:00.10starseekerno dice :-/
02:22.33*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
03:15.23CIA-48BRL-CAD: 03tbrowder2 * r46978 10/brlcad/trunk/doc/docbook/create-book-covers.pl: allow for both xml and fo suffixes to be recognized for generation to work
03:16.26CIA-48BRL-CAD: 03tbrowder2 * r46979 10/brlcad/trunk/doc/docbook/fop.xconf.in: correct font data to cover font substitution warnings
03:18.38CIA-48BRL-CAD: 03tbrowder2 * r46980 10/brlcad/trunk/doc/docbook/Makefile.am: add targets for testing book covers\nexectute create-book-covers for bot fo and pdf due to files changes with color changes for each volume
04:01.13brlcadstarseeker: installing perl on windows wouldn't be an unreasonable requisite if we want to make building the pdfs on windows possible
04:01.21brlcadso it's really about converting the Makefile.am logic into cmake terms
04:02.48brlcadif perl isn't detected, it doesn't try
04:02.52brlcadjust like fop
04:06.07brlcadstarseeker: as for the find_library reply, he sets it up for you right there at the end...  "job is to find library files"
04:36.45brlcadstarseeker: sent you what I'd reply, not that you have to use it.. but his response was a particularly heavy stuffed straw-man
04:37.17starseekerwas trying to figure out how to continue the discussion without pissing him off
04:37.46*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
04:38.02*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
04:38.05brlcadhe's intentionally trolling for some reason (or is just a bit of a jerk)
04:38.38brlcadreminds me of one of the bz devs, hyperbole overload
04:41.24brlcadleft to implement tools like 'ls', you'd not actually get a current listing of files because, well, you can't actually detect if the disk drive failed or if the filesystem is corrupted, so it's better if it just returns the listing that was there at boot-up
04:44.05*** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
04:52.42starseekerbrlcad: he mentioned /usr/lib/x86_64-linux-gnu/libc.so on ubuntu is a linker script - would that be all <128 characters?
04:56.40brlcadstarseeker: yep that would be, though that's actually one of the points I'm claiming -- that's not a library, it's a gnu linker script
04:57.18``Erik<PROTECTED>
04:57.19brlcadbasically a gnu-ld-specific symbolic link of sorts
04:58.11brlcadit's not a libtool archive .. they actually gang up and use the same filename/suffix pattern -- ld reads the file and recognizes it as an ld script
04:58.19brlcadf'd up
04:58.29``Erikthat's... very.... linuxy.
04:58.43``Eriksorry, gnu/linuxy
04:59.41brlcad"special" is the word
04:59.53brlcadneeds-a-helmet "special"
05:00.20``Erikmeh, synonymous O:-)
05:00.44brlcadstarseeker: that gets back to the original point that the only real way to tell it to try and link it
05:01.17brlcadif you're cross-compiling, you just don't halt/fail/test/whatever .. though presumably I have a cross-compiler and cross-compilation libs somewhere that will work!
05:02.37``Erikthat'd be an interesting experiment... install a cross compiler from /usr/ports/, try to build BRL-CAD, then try to run it in an emulator for that platform O.o
05:06.38starseekerhas never tangled with cross-compilation - scary sounding stuff from the early days of bootstrapping computers is where I know the phrase from
05:08.17``ErikI used to do it on linux to target win32, and have fairly recently done it to generate an arm fbsd tftp/nfsboot
05:09.41``Erikas far as the compiler, it's no big deal, just CC=/usr/local/bin/gcc-mingw32 make... figuring out how to set all the right config options and flags can expose a lot in an automatic configuration system, though :)
05:20.16starseekeronce more unto the breach dear friends... http://www.cmake.org/pipermail/cmake/2011-September/046478.html
05:48.27brlcadthinks the glorified fnmatch() comparison was warranted, but not too shabby
05:48.54brlcadleft yourself open to attack in a few places, but the point was in there
06:19.34starseekeris a rather straightforward sort, not too good at this sort of manuvering
06:45.42brlcadnot that straighforward .. very wordy reply :)
06:47.27brlcadmy tort respones were direct, you're timidly beating around the bush trying to be polite while skirting around your point before getting to it
06:47.38brlcadat least that's my take, it's still good
06:49.30brlcadI just suspect he'll nit pick something minor, hemhaw on some irrelevant detail, and ignore your points (like how he basically ignored your earlier reference to AC_CHECK_LIB)
06:52.42kanzurehi brlcad
06:52.49kanzurethanks for the scl/step update
07:39.13*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:08.45*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:26.56*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
10:06.54*** join/#brlcad kunigami_ (~kunigami@201.82.92.180)
10:10.56*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
10:14.23*** part/#brlcad kunigami_ (~kunigami@201.82.92.180)
10:44.18*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
11:37.46*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-170-216.wlan.tudelft.nl)
11:44.59*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:19.30CIA-48BRL-CAD: 03tbrowder2 * r46981 10/brlcad/trunk/doc/docbook/README: added scribus as a program for DB authors for converting eps to svg format
12:22.12CIA-48BRL-CAD: 03tbrowder2 * r46982 10/brlcad/trunk/doc/docbook/README.DB_authors_notes: add info on pdf graphics and eps conversions
12:29.52CIA-48BRL-CAD: 03tbrowder2 * r46983 10/brlcad/trunk/doc/docbook/Makefile.am: trimmed some fat; added missing tools to dist list
12:49.20*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-196-228.wlan.tudelft.nl)
13:36.32brlcadkanzure: no problem
13:41.21starseekeryawns
13:42.46brlcadyawns
13:49.15starseekerhttp://www.cmake.org/pipermail/cmake/2011-September/046479.html
13:49.23starseekereven better, http://www.cmake.org/pipermail/cmake/2011-September/046481.html
13:52.58*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
14:04.39CIA-48BRL-CAD: 03d_rossberg * r46984 10/brlcad/trunk/CMakeLists.txt:
14:04.39CIA-48BRL-CAD: the current setting of compiler flags does not work for the MSVC compiler, it results in a broken build
14:04.39CIA-48BRL-CAD: (The CMake standard for MSVC is linking with the C-runtime-DLL, which is OK. The ridiculous gcc flags force MSVC to use its own standards: Linking every DLL statically with a separate C-runtime.)
14:05.18starseekerd_rossberg: hmm.  I just built with MSVC a day or two ago...
14:05.49starseekeryou mean MSVC is mis-interperting a gcc flag?
14:07.10d_rossbergi'm afraid it misinterprets every gcc flag (see the compiler warnings)
14:08.20d_rossbergthe gcc flags will only be set for the choosen build type
14:09.25d_rossbergi.e. if you have choosen release for CMake but compiling Debug with your Visual Studio the build could work
14:10.20starseekerwinces
14:10.20d_rossbergbut otherwise asc2g will crash many time during the build
14:11.13starseekerthat business of allowing MSVC and/or XCode to have multiple configs is a real pain
14:11.15d_rossbergbtw: i couldn't find a way to build libitcl.dll
14:11.48starseekeryou mean it crashes?
14:11.52d_rossbergthe CMake defaults are doing a good job for MSVC
14:12.29d_rossbergthere are undefined symbols in itcl
14:12.55starseekerbrlcad: what's your take - should we let the MSVC defaults ride?
14:13.20starseekerd_rossberg: can you post a build log for itcl?  (also, which Visual Studio?  I recently built with 10...)
14:23.16d_rossbergdo you mean something like this: http://brlcad.org/~rossberg/BuildLog.htm
14:24.35d_rossbergMSVC 2008 (German :)
14:25.28starseekerthat looks right...
14:30.22d_rossbergall i did was making a svn checkout and choosing an "aBuild" subdirectory as cmake working directory
14:30.51starseekerwhat library implements sprintf in MSVC2008?
14:31.20starseekerthat looks like we need another MSVC library in the linker line, but I'm not sure which one
14:33.36starseekerthis might pertain to one of those linker errors... http://support.microsoft.com/kb/894573
14:35.15d_rossbergsprintf is part of the c-runtime library
14:35.31*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
14:35.38starseekerwhat do we feed to the linker list to get the c-runtime?
14:41.31starseekeris there a /GS or /Gs flag in the build somewhere?
14:42.09d_rossbergi think saying /MD or /MDd does it, /NODEFAULTLIB would remove all defaults (in this case one had to set the libraries all by hand)
14:43.53starseekerd_rossberg: go ahead and add what you need - I'll try it on 2010 later
14:53.08d_rossberg1st: it looks like its a problem with the debug configuration, release is ok (at least at the moment)
14:53.41brlcadstarseeker: they're obsessing over symbolic links, but that's still ignoring the elephant in the room to me -- just looking at the file name makes it a glorified fnmatch() wrapper
14:54.34d_rossbergthen i could compile and link the debug too by changing the c-runtime to debug-dll in the compiler settings
14:55.01d_rossbergit looks like the is somewhere a /MD instead of /MDd ...
15:03.09brlcadhow are gcc flags getting added to the msvc build?  a simple compile test should ensure that they're detected as non-functional
15:03.20brlcadif they're not, sounds like the compile test is flawed
15:03.25starseekerhah, cool:  http://www.evilmadscientist.com/article.php/visdiff
15:04.24starseekerbrlcad: if I understood him correctly, it's when you tell CMake one thing for build configuration and then do the other thing in MSVC
15:04.42starseekerXCode probably has similar issues
15:04.58brlcadhow would that result in it thinking that -pipe is a valid flag?
15:05.34starseekerd_rossberg: what were the specific errors you were seeing?  (and what compile flags were getting passed in?)
15:05.59brlcadthere should have been a -pipe test (which fails), and both debug and release configs would use $PIPE_FLAG or whatever so it'd never get added
15:06.30starseekerI don't know if it was pipe specifically
15:06.39brlcadhis error log lists a -pipe
15:07.03brlcadif pipe got through, they all would probably get through
15:07.13starseekerd_rossberg: do you happen to have your CMake log handy?
15:08.52starseekerthat's the itcl build, it's probably a lot dumber than our mail BRL-CAD build
15:09.44starseekermain even
15:10.27starseekerdid he post a build log for the original gcc compile failure?
15:10.45brlcadnot that I saw
15:10.51starseekerthat'd be the one we need
15:11.38brlcador examine the build log on our end with that action, cmake as debug, change to release in studio, compile
15:11.44d_rossbergunknown compile flags are ignored (what you can see in the log)
15:12.07starseekerignored and the compile succeeds?  (crud)
15:13.00d_rossbergthe problem arise when you replace the reasonable cmake defaults by garbage
15:13.32d_rossbergthen you have the msvc defaults, which are not optimal bor brl-cad
15:13.39starseekerclang has that same issue - it'll cheerfully ignore unknown flags and succeed
15:14.15starseekerthe cmake defaults shouldn't be getting replaced by garbage though
15:14.19d_rossbergadding garbage is no problem, replacing the right settings is
15:14.44starseekerif we need to add MSVC specific compiler tests to make sure the right MSVC settings are there, then we should do that in CompilerFlags.cmake
15:16.00d_rossbergbtw, i think i found the place to chage in the itcl configuration; there are similar settings in other tcl/tk libraries; need some time to test it out
15:16.15starseekercool, thanks
17:29.32brlcadyay, search crashed
17:40.16CIA-48BRL-CAD: 03brlcad * r46985 10/brlcad/trunk/src/librt/search.c: prevent search from crashing if we can't get a directory pointer to a specified path. encountered this with an object erroneously containing slashes in the name.
17:50.23CIA-48BRL-CAD: 03brlcad * r46986 10/brlcad/trunk/src/librt/ (db_anim.c db_tree.c prep.c tcl.c tree.c wdb.c): check other callers of DB_FULL_PATH_CUR_DIR() to make sure we don't try to dereference a NULL pointer.
17:56.45CIA-48BRL-CAD: 03brlcad * r46987 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: don't use the file path as the toplevel object name. use its basename instead since the slashes cause hell.
18:10.13CIA-48BRL-CAD: 03tbrowder2 * r46988 10/brlcad/trunk/doc/docbook/README: add info on the saxon-he xslt 2.0 processor and news of the recent release of the DB xslt 2.0 stylesheets
18:49.36CIA-48BRL-CAD: 03tbrowder2 * r46989 10/brlcad/trunk/doc/docbook/Makefile.am: current process for DB book covers does not allow parallel make processes so using special .NOTPARALLEL target; also requires having book pdf generation in one recipe from xml to fo to pdf
18:50.48CIA-48BRL-CAD: 03tbrowder2 * r46990 10/brlcad/trunk/doc/docbook/README: reword; add release date of new DB stylesheets for XSLT 2.0
20:23.56*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:59.02CIA-48BRL-CAD: 03starseeker * r46991 10/brlcad/trunk/src/librt/comb/comb.c:
20:59.02CIA-48BRL-CAD: Gah. Older versions of BRL-CAD are hard-coded to look for oshader in the
20:59.02CIA-48BRL-CAD: attributes when importing combs. This makes the particular label oshader an
20:59.02CIA-48BRL-CAD: actual part of the .g file format itself, and NOT writing it out was breaking
20:59.02CIA-48BRL-CAD: import of shaders when a .g file is created in a new version of BRL-CAD and
20:59.03CIA-48BRL-CAD: subsequently opened in an older version. Need to check what other hard-coded
20:59.04CIA-48BRL-CAD: assumptions got accidently messed with.
22:17.08*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
22:26.44CIA-48BRL-CAD: 03bob1961 * r46992 10/brlcad/trunk/src/tclscripts/archer/images/component_select.png: Update component_select image.
IRC log for #brlcad on 20110930

IRC log for #brlcad on 20110930

01:49.44*** join/#brlcad DarkCalff (DC@173.231.40.98)
04:12.03*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
04:12.03*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
04:12.03*** join/#brlcad CIA-48 (~CIA@cia.atheme.org)
04:12.03*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
04:12.03*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
04:12.03*** join/#brlcad piksi (piksi@pi-xi.net)
04:12.03*** join/#brlcad yiyus (1242712427@je.je.je)
04:12.03*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
04:12.03*** join/#brlcad kanzure (~kanzure@131.252.130.248)
04:45.49CIA-48BRL-CAD: 03brlcad * r46993 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeIV.xml:
04:45.49CIA-48BRL-CAD: looks like this has been 'wrong' since the original. add the requisite dashes
04:45.49CIA-48BRL-CAD: to all of the various -whatever command-line options so users aren't trying to
04:45.49CIA-48BRL-CAD: type things like 'g-dxf o file.dxf file.g object'. that detail was picked up
04:45.49CIA-48BRL-CAD: and reported on the help forum recently by kerryhall.
06:17.02*** join/#brlcad DarkCalff (DC@173.231.40.98)
07:13.11*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:35.17CIA-48BRL-CAD: 03d_rossberg * r46994 10/brlcad/trunk/src/other/ (6 files in 6 dirs): (log message trimmed)
07:35.17CIA-48BRL-CAD: removed release build-type specific MSVC compiler option
07:35.17CIA-48BRL-CAD: CMake generates per default many configurations for MSVC, e.g.
07:35.17CIA-48BRL-CAD: "Debug;Release;MinSizeRel;RelWithDebInfo". However, the /MD option (use
07:35.17CIA-48BRL-CAD: muti-thread DLL C-runtime) is valid for release configurations only. The debug
07:35.17CIA-48BRL-CAD: needs the /MDd option (muti-thread debug DLL C-runtime, for example. Using the
07:35.18CIA-48BRL-CAD: wrong C-runtime may lead to unresolved symbol errors during linking.
08:16.14*** join/#brlcad merzo (~merzo@171-13-133-95.pool.ukrtel.net)
08:40.28*** join/#brlcad hackrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
08:40.28*** join/#brlcad merzo (~merzo@171-13-133-95.pool.ukrtel.net)
08:40.28*** join/#brlcad DarkCalff (DC@173.231.40.98)
08:40.28*** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
08:40.28*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
08:40.28*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
08:40.28*** join/#brlcad CIA-48 (~CIA@cia.atheme.org)
08:40.28*** join/#brlcad kunigami (~kunigami@loco-gw.ic.unicamp.br)
08:40.28*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
08:40.28*** join/#brlcad piksi (piksi@pi-xi.net)
08:40.28*** join/#brlcad yiyus (1242712427@je.je.je)
08:40.28*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
08:40.28*** join/#brlcad kanzure (~kanzure@131.252.130.248)
08:40.47*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
08:40.47*** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no)
08:41.12*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
08:41.12*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
08:41.12*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
09:21.13*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:10.45*** join/#brlcad merzo (~merzo@171-13-133-95.pool.ukrtel.net)
11:49.02CIA-48BRL-CAD: 03bob1961 * r46995 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Added code to call rt_gettrees and prep etc. only when the display list changes.
11:53.06CIA-48BRL-CAD: 03bob1961 * r46996 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Got rid of some dead code (i.e. mouse_ray). Removed everything related to COMP_ERASE_MODE. Added a component pick mode and associated menu for using the component pick button for many different purposes.
15:43.48*** join/#brlcad ibot (~ibot@rikers.org)
15:43.48*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
16:00.27CIA-48BRL-CAD: 03tbrowder2 * r46999 10/brlcad/trunk/doc/docbook/Makefile.am: remove unused dependencies in suffix rules
18:00.15*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
19:11.22CIA-48BRL-CAD: 03bob1961 * r47000 10/brlcad/trunk/src/libged/bot_split.c: Update libged/bot_split.c to return a list of sublists where each sublist contains the original bot and a subsublist containing the new bots created by the split.
19:17.54CIA-48BRL-CAD: 03bob1961 * r47001 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl:
19:17.54CIA-48BRL-CAD: Comparing mRayCurrWho with mRayLastWho is not adequate for determining whether
19:17.54CIA-48BRL-CAD: or not to create a ray object or use the old one. The current and previous who
19:17.54CIA-48BRL-CAD: lists may match and yet contain a different hierarcy (i.e. things could have
19:17.54CIA-48BRL-CAD: changed out from under it). More needs to be done here.
19:22.15CIA-48BRL-CAD: 03bob1961 * r47002 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl):
19:22.15CIA-48BRL-CAD: Cleaned up a bit of crud in Archer.tcl. Also added code to enhance bot_split
19:22.15CIA-48BRL-CAD: when splitting via component pick mode. The old bot (i.e. the one getting split)
19:22.15CIA-48BRL-CAD: becomes a group containing the newly created bots resulting from the split.
20:28.13*** join/#brlcad merzo (~merzo@152-234-132-95.pool.ukrtel.net)
20:38.10CIA-48BRL-CAD: 03tbrowder2 * r47003 10/brlcad/trunk/doc/docbook/Makefile.am: added a test for the xml catalog, and regeneration if necessary, to all suffix rules that use xsltproc; added xml catalog as a dependency to other rules using xsltproc
21:05.27CIA-48BRL-CAD: 03tbrowder2 * r47004 10/brlcad/trunk/doc/docbook/books/en/images/ (11 files): add missing Vol IV images
21:58.21*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
23:16.14CIA-48BRL-CAD: 03n_reed * r47005 10/brlcad/trunk/doc/ (4 files): added notes on converting bison/flex to re2c/lemon
23:48.22CIA-48BRL-CAD: 03n_reed * r47006 10/brlcad/trunk/src/other/step/src/express/ (Makefile.am expparse_new.y): added initial bison to lemon syntax conversion of expparse.y
23:50.59*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:57.20CIA-48BRL-CAD: 03abhi2011 * r47007 10/brlcad/trunk/src/libged/simulate/simulate.c:
23:57.20CIA-48BRL-CAD: Added code to display bounding boxes, recalculating the BB every iteration is
23:57.20CIA-48BRL-CAD: causing boxes that have moved to stay bent in their new position as each
23:57.20CIA-48BRL-CAD: bounding box is inserted as a new cube in the next iteration. This problem
23:57.20CIA-48BRL-CAD: should disappear when contact points are calculated correctly
23:59.21CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3171 10/wiki/User:Abhijit: /* Log */
23:59.50CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3172 10/wiki/User:Abhijit: /* Log */
IRC log for #brlcad on 20111001

IRC log for #brlcad on 20111001

03:50.58*** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
06:07.26*** join/#brlcad merzo (~merzo@152-234-132-95.pool.ukrtel.net)
06:56.34*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:27.18*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
10:24.56abhi2011Getting some weird cases like this now : http://postimage.org/image/lkepvy2s/full/
10:25.08abhi2011its due to recalculation of the bb each iteration
10:28.03abhi2011but should be gone when I start calculating the points using rt
10:28.26abhi2011the challenge now is to generate contact points between colliding objects based on the same criteria that bullet does
10:36.20abhi2011apparently it generates points exactly along edges or to maximize the area covered by them
11:40.23CIA-48BRL-CAD: 03abhi2011 * r47008 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simphysics.cpp simulate.c): Added code to check the collision points during collision processing
13:20.45CIA-48BRL-CAD: 03abhi2011 * r47009 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simulate.c simulate.h): Added contact manifold related members to the sim_params struct to communicate them back to libged and display them
13:53.30brlcadabhi2011: looking great!
13:54.00brlcadI expected that the bounding box recalc would cause "wrong" collision detection, but it's right ;)
13:54.42brlcadso bullet can basically do preliminary intersection calculations applying velocity and rotation adjustments on objects that aren't touching without problem
13:55.00``Erikbullet does 'sweep' cd, iirc
13:55.14brlcaduntil two bounding boxes intersect, at which point rays have to be fired to determine whether they "actually" intersect yet (and where those points are)
13:58.08abhi2011brlcad: yes, well bullet also calculates the same bounding box as we do at the start of each iteration, so the results should be ok
14:00.45abhi2011yes, so after every iteration I am going to fire a bunch of rays and report upto 4 points for every case where objects touch
14:01.01abhi2011these have to have the maximum possible volume
14:01.17abhi2011which should be easy to get, just get the points with maximum x,y
14:01.24abhi2011and minimum
14:04.55abhi2011so where can i find some code to help me draw arrows in mged
14:05.32abhi2011i need to draw the contact normals to check if they are being calculated correctly, then reproduce the same through rt
14:06.07abhi2011the normals have to point correctly so that forces are apllied in the right direction
19:43.47abhi2011thats strange , I am trying to setup a linked list of manifold points, but I get an error  after the function that allocates memory for each node has completed
19:44.06abhi2011#0  0x00007fffe2e6a6eb in malloc_consolidate () from /lib64/libc.so.6
19:44.08abhi2011#1  0x00007fffe2e6be14 in _int_malloc () from /lib64/libc.so.6
19:44.09abhi2011#2  0x00007fffe2e6ed99 in malloc () from /lib64/libc.so.6
19:47.25CIA-48BRL-CAD: 03abhi2011 * r47010 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simulate.c simulate.h): Trying to pass contact manifolds via a linked list back to libged
20:13.56abhi2011are there any issues with bu_malloc() in c++
20:27.29*** join/#brlcad merzo (~merzo@177-241-132-95.pool.ukrtel.net)
20:48.54CIA-48BRL-CAD: 03abhi2011 * r47011 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simulate.c): Fixed some memory bugs
20:49.00abhi2011ah shoot, it was a bug in my code...casting aspersion on bu_malloc() unnecessarily :P
20:54.45abhi2011ah frack!!!....had the arguments for VMOVE() reversed, was therefore pushing weird data into the bullet simulation instead of getting points out and got some extremely strange results.....get a grip abhi !!!
20:55.23CIA-48BRL-CAD: 03abhi2011 * r47012 10/brlcad/trunk/src/libged/simulate/simcollisionalgo.cpp: fixed order of arguments in the VMOVE() which retrieve the collision points
21:04.12CIA-48BRL-CAD: 03abhi2011 * r47013 10/brlcad/trunk/src/libged/simulate/simulate.c: More bug fixes, forgot to uncomment the memory cleanup routine
23:37.54*** join/#brlcad piksi (piksi@pi-xi.net)
IRC log for #brlcad on 20111002

IRC log for #brlcad on 20111002

09:08.56CIA-48BRL-CAD: 03abhi2011 * r47014 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c):
09:08.56CIA-48BRL-CAD: checked to see if some subtle positioning issues could be solved by not
09:08.56CIA-48BRL-CAD: calculating the BB each iteration, but that created large differences between
09:08.56CIA-48BRL-CAD: the correct and rendered position, so sticking with the recalculation of BB each
09:08.56CIA-48BRL-CAD: iteration approach and focusing on adding rt
09:14.39abhi2011I was wondering if I can add a fix to the primitive editor in mged to take the in focus object by default and show its attributes, instead of having to type in the name each time
10:36.18*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:06.00abhi2011hmm there  seems to be no options for an overlap function in struct application_bundle
11:10.53abhi2011hmm I ll just shoot the rays one by one at the moment using the single ray shooting functions, translating their position a bit across and up/down to shoot a grid
11:23.54abhi2011hmm so to get the exact bounds of the overlap I ll have to shoot at least a 100 rays in each of the x,y, z direction
11:23.59abhi2011probably more
11:24.06abhi2011if the scene is large
11:24.58abhi2011I ll probably get the bounding box of the scene and shoot rays at 0.1 mm intervals in each of the 3 directions in a 3d grid
13:19.22``Erikthat'd be an awful lot of rays... the "marching cubes" tesselator does that kinda thing and can take gobs of cpu time on even simple stuff
13:20.22``Erikum, try "g-stl -8 -a 10 /path/to/db/m35.g component" for an idea, -8 uses marching cubes and -a is grid spacing in mm
13:21.29``Erik(and it only shoots one direction until intersections are found)
13:23.02``Erikconversly, raytrace the three views at -s100000 or so, which'd ignore the book keeping and matching parts *shrug*
14:34.11abhi2011umm ok, I actually need to use librt functions to do this, so I cant do it in the command line
14:35.15abhi2011if 100 is too high will probably have to settle for smaller scenes as of now with max about 20 rays in each direction
14:39.19``Erikjust noting ways to see the amount of computation necessary, not saying how to do your certain task :)
14:44.44abhi2011:)
14:55.37abhi2011hmm I need to undo a affine transformation and I have the matrix that did the transformation
14:55.42abhi2011so I need to invert the matrix
14:55.56abhi2011no direct macro for that I guess
14:56.01abhi2011in vmath.h
15:47.08abhi2011hmm ok just transposing the upper left 3 by 3 matrix and inverting the translation vector seems to work for inverting an affine transf.
16:05.15abhi2011phew!...solved a particularly annoying positioning issue : http://postimage.org/image/113v0wsmc/full/
16:06.17abhi2011since bullet returns world transformations, it's important to undo the object transformation in mged, before applying rt_matrix_transform()
16:06.35abhi2011I was inverting the translation from the previous iteration
16:06.39abhi2011but not the rotation
16:07.02abhi2011leading to subtle differences, like objects outside their BB over large iterations
16:07.59CIA-48BRL-CAD: 03abhi2011 * r47015 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simulate.c simulate.h): Corrected positioning code and removed BB calculation in every iteration
16:09.07abhi2011Also another change is that I do not calculate the BB every iteration, just at the first iteration, to give me something(a cuboid) to create as a collision shape in the bullet world
16:11.37abhi2011after that bullet manages the aabb quiet well and its best not to recalculate the AABB and insert larger cubes into the physics world when the simulation has begun
16:12.19abhi2011that tends to lock the objects into their rotated position leading to no manifolds being generated etc.....well all set to shoot rays now
16:17.01CIA-48BRL-CAD: 03abhi2011 * r47016 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simulate.c): Corrected some // comments in C code to prevent warnings
17:27.32CIA-48BRL-CAD: 03tbrowder2 * r47017 10/brlcad/trunk/doc/docbook/resources/brlcad/book-covers-fo-template.xsl: mod to allow unique colors file per each en book
17:28.16CIA-48BRL-CAD: 03tbrowder2 * r47018 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-fo-stylesheet-covers.xsl: remove old multi-book file not usable for parallel make
17:29.18CIA-48BRL-CAD: 03tbrowder2 * r47019 10/brlcad/trunk/doc/docbook/resources/brlcad/ (4 files): add unique entry stylesheet per en book
17:30.40CIA-48BRL-CAD: 03tbrowder2 * r47020 10/brlcad/trunk/doc/docbook/BRLCAD_DOC.pm: mods for generating and inserting unique color file per en book
17:32.28CIA-48BRL-CAD: 03tbrowder2 * r47021 10/brlcad/trunk/doc/docbook/create-book-covers.pl: mods for generating and using unique cover and color file per en book
17:34.09CIA-48BRL-CAD: 03tbrowder2 * r47022 10/brlcad/trunk/doc/docbook/Makefile.am: mods to allow en book pdf generation with no parallel make restrictions; some convenience definition macros used
18:28.20abhi2011hmm trying to find a simple way to draw a line for the rays, like nirt does
18:28.44abhi2011draw.c seems to do it by inventing a solid....a bit confusing what its doing though
18:29.03abhi2011_ged_invent_solid() in draw.c
20:26.36*** join/#brlcad merzo (~merzo@237-14-132-95.pool.ukrtel.net)
22:23.42*** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no)
22:23.42*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
22:23.42*** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
23:55.32CIA-48BRL-CAD: 03abhi2011 * r47023 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simphysics.cpp simulate.c simulate.h): Added manifold drawing code
IRC log for #brlcad on 20111003

IRC log for #brlcad on 20111003

07:45.06*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:48.46*** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl)
10:17.35*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-018.wlan.tudelft.nl)
11:05.31*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-184-236.wlan.tudelft.nl)
13:04.44*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:27.55*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:38.23*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:58.16CIA-48BRL-CAD: 03tbrowder2 * r47024 10/brlcad/trunk/doc/docbook/README.DB_authors_notes: add figure template and explanation for better control of DB images
14:14.29CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3173 10/wiki/User:Abhijit: /* Log */
14:20.20CIA-48BRL-CAD: 03bob1961 * r47025 10/brlcad/trunk/src/librt/primitives/bot/bot.c: Modified rt_bot_split_func() to look for shared edges instead of a shared point.
14:24.06*** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net)
15:03.58CIA-48BRL-CAD: 03tbrowder2 * r47026 10/brlcad/trunk/doc/docbook/README.DB_authors_notes: corrected role settings
15:35.55CIA-48BRL-CAD: 03tbrowder2 * r47027 10/brlcad/trunk/doc/docbook/README.DB_authors_notes: reword section on image control, add DB references
15:59.35CIA-48BRL-CAD: 03n_reed * r47028 10/brlcad/trunk/src/other/step/src/express/expparse_new.y: indent/ws
16:43.10CIA-48BRL-CAD: 03tbrowder2 * r47029 10/brlcad/trunk/doc/docbook/css/ (. brlcad.css): add css stylesheet for BRL-CAD html docs
16:45.04CIA-48BRL-CAD: 03tbrowder2 * r47030 10/brlcad/trunk/doc/docbook/Makefile.am: add suffix rule dependencies portably; remove recipe statements no longer needed; add helpful comments
16:46.00CIA-48BRL-CAD: 03tbrowder2 * r47031 10/brlcad/trunk/doc/docbook/lessons/en/mged01_creating_primitive_shapes.xml: changes to improve appearance of first figure in html and pdf
16:46.43CIA-48BRL-CAD: 03tbrowder2 * r47032 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-xhtml-stylesheet.xsl: add reference to new BRL-CAD css stylesheet for html
17:04.05*** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl)
18:23.25*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:01.51CIA-48BRL-CAD: 03tbrowder2 * r47033 10/brlcad/trunk/doc/docbook/Makefile.am: ensure doc/docbook/css dir and files are installed
19:45.37CIA-48BRL-CAD: 03brlcad * r47034 10/brlcad/trunk/src/libged/simulate/simulate.c: use vls strings instead of a fixed buffer. strcat for efficiency. may want to consider bn_mat_print*() functions instead of rolling your own like this. remove c++-style comment.
19:47.12CIA-48BRL-CAD: 03brlcad * r47035 10/brlcad/trunk/src/libged/simulate/simulate.c: ws indent style cleanup. should be following HACKING.
19:53.41CIA-48BRL-CAD: 03bob1961 * r47036 10/brlcad/trunk/src/libged/bot_split.c: Modified libged/bot_split to reset make_name's counter before creating new bots.
20:08.14*** join/#brlcad DarkCalf (DC@173.231.40.98)
20:12.33CIA-48BRL-CAD: 03brlcad * r47037 10/brlcad/trunk/src/libged/simulate/ (5 files): more mass ws indent style comment cleanup. very hard to follow when even the file itself is so self-inconsistent. update copyright year to 2011 as year of inception.
20:27.33*** join/#brlcad merzo (~merzo@40-197-132-95.pool.ukrtel.net)
21:16.14brlcadtrudges through commits
21:56.51*** join/#brlcad DarkCalff (DC@2002:ade7:2862::ade7:2862)
22:09.52*** join/#brlcad DarkCalfz (DC@173.231.40.98)
22:13.30*** join/#brlcad DarkCalff (DC@2002:ade7:2862::ade7:2862)
23:17.52*** join/#brlcad DarkCalfz (DC@173.231.40.98)
23:25.21CIA-48BRL-CAD: 03n_reed * r47038 10/brlcad/trunk/src/other/step/src/express/expparse_new.y: making choice for ambigous reduction explicit to suppress conflict error from lemon
23:33.00*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
23:58.12brlcadabhi2011: several :)
23:59.47brlcadabhi2011: if you run the sh/ws.sh and sh/indent.sh scripts on your files from time to time, that should help keep them in order
IRC log for #brlcad on 20111004

IRC log for #brlcad on 20111004

00:01.58brlcadbasically should always be clean, even if temporary code or works in progress -- not a huge deal but it becomes more and more important as code tends to hang around much longer than the original author and becomes paramount as a codebase grows and ages
00:03.20brlcadit's a "clean house all the time" not just when you have guests (because it's a huge hotel and there are always guests)
00:09.15brlcadnice, tessellation of 5th level sphflake is still going (4+ days)
00:09.27brlcadthe 6th level might be impractical.. :)
00:15.03starseekerif it's exponential... how long did the 4th level take?
00:36.26CIA-48BRL-CAD: 03n_reed * r47039 10/brlcad/trunk/ (2 files in 2 dirs): seems lemon requires real type name in type declaration
01:02.07*** join/#brlcad _pseudonym (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net)
01:02.31*** part/#brlcad _pseudonym (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net)
01:03.11*** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net)
01:13.31*** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net)
01:13.31*** join/#brlcad DarkCalfz (DC@173.231.40.98)
01:13.31*** join/#brlcad merzo (~merzo@40-197-132-95.pool.ukrtel.net)
01:13.31*** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net)
01:13.31*** join/#brlcad piksi (piksi@pi-xi.net)
01:13.31*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
01:13.31*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
01:13.31*** join/#brlcad CIA-48 (~CIA@cia.atheme.org)
01:13.31*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
01:13.31*** join/#brlcad yiyus (1242712427@je.je.je)
01:13.31*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
01:13.31*** join/#brlcad kanzure (~kanzure@131.252.130.248)
01:14.18*** part/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net)
01:50.14starseekerglowers at all these perl routines generating xml pages... I'm kinda wondering if this shouldn't be some .xml.in files
01:50.23starseekerfeels like overkill
01:54.36*** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net)
02:41.08brlcadstarseeker: dunno, few hours maybe or a half a day or something
02:41.52brlcadundoubtedly overkill but if it works, it's definitely great progress .. can't wait to see everything getting regenerated nightly
02:42.33brlcadso the build worked for you?  I'm seeing the previous error still but haven't done a clean rebuild to see if it's some other issue
02:42.37brlcaddoc build
02:45.06starseekerhad to manually run the perl script to create that catalog file, then change the APACHEFOP invocation
02:45.19starseekerhe hardcoded the fop path
02:46.46starseekermy sense is we can do most of what he's doing with .in files, and the little bit that can't be (e.g. pulling subversion revision number) can be handled without perl
02:46.54starseekersounds like he may agree
02:49.59starseekerI'll poke at it more tomorrow - need to run the wife in to work, she's got car trouble
02:50.40starseekersince I have to go exactly the wrong way in the morning anyway, might as well come back here and do fop stuff :-)
02:54.45starseekerhere's what got generated for volume 1:  http://bzflag.bz/~starseeker/BRL-CAD_Tutorial_Series-VolumeI.pdf
02:57.31brlcadthe svn revision number doesn't really belong -- it should be using the include/conf files with good ol' revision numbers or a date stamp ala 20110412
02:58.19starseekereven easier then
02:59.24starseekerlooks like at least one extra title page, and probably we need some way to tell it not to do things like figure lists when n=1...
02:59.50starseeker'course, "volume 1" isn't properly a book at all...
02:59.53starseekernot now, anyway
05:46.42starseekerbrlcad: http://www.cmake.org/pipermail/cmake/2011-October/046553.html
05:46.58starseekerhttp://www.cmake.org/pipermail/cmake/2011-October/046554.html
06:12.54*** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net)
06:28.14*** join/#brlcad piksi (piksi@pi-xi.net)
06:45.47*** join/#brlcad merzo (~merzo@193.254.217.44)
07:09.27*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
08:05.12*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:10.38*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
10:15.47*** join/#brlcad mattS_ (792cfb6c@gateway/web/freenode/ip.121.44.251.108)
10:16.26mattS_Hi!  Is anyone around here?
10:17.42pacman87~ask
10:17.43ibotQuestions in the channel should be specific, informative, complete, concise, and on-topic.  Don't ask if you can ask a question first.  Don't ask if a person is there; just ask what you intended to ask them.  Better questions more frequently yield better answers.  We are all here voluntarily or against our will.
10:18.34mattS_Hm, the bot is telling me to ask better questions...
10:19.18mattS_OK, I am interested in getting the sweep / revolve feature working, and may have the time to do it these days.
10:19.35mattS_Not so sure about the programming skills, but that's to be determined.
10:19.57pacman87Ah, I was the one who suggested you come here
10:20.07mattS_Indeed.
10:20.31mattS_So, where should I look?
10:21.15pacman87From what I remember, the revolve uses a "sketch" as its base, and only straight line segments are supported for the revolve
10:21.29pacman87do you have the code checked out?
10:21.37pacman87~brlsvn
10:21.37ibottry ~cadsvn instead
10:21.42pacman87~cadsvn
10:21.42ibotTo obtain BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad
10:22.10mattS_ack.  no svn client on this particular computer...
10:22.16pacman87what OS?
10:22.20mattS_OK, lemme put one on.
10:22.23mattS_OSX.
10:22.24mattS_yuck
10:23.08pacman87try https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/librt/primitives/
10:23.53mattS_That's rather a lot for a browser based approach.
10:24.00mattS_lemme find an svn client.
10:24.16pacman87specifically, https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/librt/primitives/revolve/
10:24.28pacman87revolve.c, revolve.h, and revolve_brep.cpp
10:25.46mattS_kk
10:25.56mattS_u+p for svn checkout?
10:26.31pacman87try blank
10:27.29pacman87if not, try your sourceforge user/pass
10:28.09mattS_blank it is.
10:28.11mattS_got it.
10:28.25pacman87yeah, you should only need user/pass for commit access
10:28.38mattS_Makes sense.
10:30.27mattS_so in a sentence or two, how far did you get with this project?
10:33.29pacman87I think it should work for sketches with only straight-line segments
10:33.58mattS_Great!
10:34.33pacman87since straight line + revolve axis = cone/cylinder/plane
10:34.41pacman87so the intersection calculation wasn't too hard
10:35.35pacman87the next step would probably be to look up what other segment types are supported by the sketch primitive, and start adding those
10:35.51mattS_Indeed.  Ah yes, I recall now that you were taking a different approach to this than what I had first thought of...  
10:36.13pacman87probably circular arcs would be easiest, since that's a toroid
10:36.21mattS_Any chance you have a document somewhere outlining your approach?
10:36.28pacman87http://brlcad.org/wiki/Revolve_Primitive
10:36.49mattS_Circular arcs would be next logical step, yes.
10:38.24mattS_OK, I need some sleep.  I will have a look + think about this tomorrow.
10:38.32mattS_Thanks for your help!
10:38.46pacman87from https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk/src/librt/primitives/sketch/sketch.c , it looks like the sketch can have line segments, circular arcs, nurb, and bezier curves
10:39.03pacman87re: sleep, me too
10:40.03*** part/#brlcad mattS_ (792cfb6c@gateway/web/freenode/ip.121.44.251.108)
10:44.39pacman87brlcad: looks like the revolve primitive may be getting some work soon (see above)
10:59.27*** join/#brlcad merzo (~merzo@193.254.217.44)
12:56.52CIA-48BRL-CAD: 03n_reed * r47040 10/brlcad/trunk/src/other/step/src/express/ (CMakeLists.txt expscan.re): Added disabled macros to build temp fedex_new target for development. Added expscan.re to build against, but it has not yet been converted to re2c.
13:31.25CIA-48BRL-CAD: 03bob1961 * r47041 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl:
13:31.26CIA-48BRL-CAD: bot_split2, if the specified bot was split, now returns a list containing the
13:31.26CIA-48BRL-CAD: name of the original bot and the backup name. The original name is used for the
13:31.26CIA-48BRL-CAD: group containing the new bots resulting from the split. The backup name
13:31.26CIA-48BRL-CAD: references the original bot.
13:33.59CIA-48BRL-CAD: 03bob1961 * r47042 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added bot_split_all, bot_sync_all and bot_fix_all. Updated bot_flip_check to return a built up string instead of spewing things directly to the command window.
13:55.49``Erikhttp://gcc.gnu.org/wiki/CompileFarm
15:33.21CIA-48BRL-CAD: 03bob1961 * r47043 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Ripped out Archer's undo mechanism in preparation for using transactions.
15:38.54brlcad``Erik: nifty, going to set us up the bomb?
15:40.35brlcadmm, that might explain why my revolve sketch performance test case was crashing if it only supports straight line segments...
15:46.29``ErikI sent a request for an account just before linking it
15:50.35CIA-48BRL-CAD: 03starseeker * r47044 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt resources/brlcad/brlcad-xml-catalog.xml.in):
15:50.35CIA-48BRL-CAD: First baby steps towards more advanced Docbook processing with CMake. Make the
15:50.35CIA-48BRL-CAD: catalog file a CMake configure template, and add the environment variables
15:50.35CIA-48BRL-CAD: needed for xsltproc to the custom command invocations. Lot more and lot tricker
15:50.36CIA-48BRL-CAD: to come, but this is a start.
16:15.32CIA-48BRL-CAD: 03starseeker * r47045 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt resources/brlcad/brlcad-xml-catalog.xml.in): switch a couple of the xsl stylesheet targets, fix paths.
16:54.04CIA-48BRL-CAD: 03starseeker * r47046 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt books/CMakeLists.txt): Getting closer to getting pdf working, but not finding fonts... missing something.
16:58.22CIA-48BRL-CAD: 03starseeker * r47047 10/brlcad/trunk/doc/docbook/ (articles/en/CMakeLists.txt presentations/en/CMakeLists.txt): Couple stray leftover variables.
17:16.48*** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net)
17:29.56CIA-48BRL-CAD: 03starseeker * r47048 10/brlcad/trunk/doc/docbook/CMakeLists.txt: fix typo. Try and get the fop command line to match that from autotools
17:41.00*** join/#brlcad n_reed (~nreed1@ool-457cb1ab.dyn.optonline.net)
17:47.23CIA-48BRL-CAD: 03abhi2011 * r47049 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simphysics.cpp simulate.c simulate.h): Added more code to check the generated manifolds
18:16.06CIA-48BRL-CAD: 03bob1961 * r47050 10/brlcad/trunk/src/libged/ (bot_flip.c bot_split.c bot_sync.c): Modify bot_split, bot_sync and bot_flip to accept arguments containing full paths to bots.
18:20.46CIA-48BRL-CAD: 03brlcad * r47051 10/brlcad/trunk/src/libged/simulate/simulate.h: separate out struct members into one per line so they can be individually documented; revert the ws changes.
18:21.16brlcadabhi2011: your previous commit just undid all of the whitespace corrections applied yesterday
18:24.40brlcadthe only way that would occur is if either a) you got a conflict and resolved it incorrectly or b) ran a source formatter before committing and applied the wrong style
18:26.56CIA-48BRL-CAD: 03bob1961 * r47052 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Simplify ArcherCore::redrawObj.
18:28.38CIA-48BRL-CAD: 03brlcad * r47053 10/brlcad/trunk/src/libged/simulate/simulate.c: use vmath macros where appropriate, reduces line count. restore indent for the affected functions.
18:31.55abhi2011brlcad: I just applied the sh/ws.sh and sh/indent.sh on all the files in simulate/* files
18:32.06abhi2011before committing
18:32.28abhi2011is only one of them supposed to be run and not both ?
18:39.50abhi2011hmm the indentation should be 4 spaces, however after i ran indent.sh it indented everything by 2 spaces
18:43.06CIA-48BRL-CAD: 03brlcad * r47054 10/brlcad/trunk/src/libbu/ (11 files): trailing ws and indent cleanup
18:43.11brlcadabhi2011: yeah, something didn't go right with the indent
18:43.31brlcadfor what it's worth, you should always separate ws/indent commits from logic changes
18:43.38brlcadotherwise you can't tell what the changes were
18:44.00abhi2011ok
18:44.10brlcadsomething apparently went wrong with the indent.sh script -- do you use emacs?
18:44.13abhi2011hmm i just ran indent again and its indented everything by 2 spaces
18:44.15abhi2011yes
18:44.20abhi2011i instaled emacs today
18:44.28brlcaddo you have a C hook registered?
18:44.30abhi2011does it require configuration
18:44.32abhi2011no
18:44.53abhi2011i do not have a C hook registered
18:45.00brlcadit shouldn't require configuration, but if you have an existing config it can override the file settings
18:45.20brlcadtry running indent.sh on one file and see what it does
18:45.31brlcadpastebin the output
18:46.33abhi2011http://bin.cakephp.org/view/530534711
18:46.44abhi2011i ran : sh/indent.sh src/libged/simulate/simulate.c
18:47.26CIA-48BRL-CAD: 03tbrowder2 * r47055 10/brlcad/trunk/doc/docbook/resources/other/: start of resources restructuring
18:47.50abhi2011i think after installation, emacs needs to be told to indent by 4 spaces, else it defaults to 2
18:47.56brlcadI meant the output from indent.sh :)
18:47.58abhi2011hmm maybe something missing in the trailer
18:48.00abhi2011ok
18:48.51abhi2011http://bin.cakephp.org/view/2025222878
18:49.08abhi2011i think the trailer needs to contain the indentation info in the c file
18:49.12abhi2011i ll add it and see
18:49.43abhi2011though I would have thought that the one already there will work
18:50.33CIA-48BRL-CAD: 03tbrowder2 * r47056 10/brlcad/trunk/doc/docbook/resources/ (docbook/ docbook-5.0/): rename to remove version
18:50.34brlcadabhi2011: c-file-style: "stroustrup" sets an indentation of 4
18:50.39abhi2011hmm trailer in the simulate.c file is same as any other file
18:50.41abhi2011yes
18:51.11abhi2011emacs messing around with my code :P
18:51.17brlcadwhat version of emacs?
18:51.32abhi2011GNU Emacs 23.2.1
18:52.17CIA-48BRL-CAD: 03tbrowder2 * r47057 10/brlcad/trunk/doc/docbook/resources/ (docbook/ docbook-schema/): rename for clarity; avoid confusion with stylesheets
18:53.12abhi2011something needs to be put in .emacs
18:53.25brlcadhm, yours is slightly newer than mine, what does M-x describe-variable c-file-style report?
18:53.41CIA-48BRL-CAD: 03tbrowder2 * r47058 10/brlcad/trunk/doc/docbook/resources/ (docbook-schema/ other/docbook-schema/): segregate external resources
18:54.41*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:54.59CIA-48BRL-CAD: 03tbrowder2 * r47059 10/brlcad/trunk/doc/docbook/resources/ (other/standard/ standard/): segregate external resources
18:55.14brlcadI have nothing in my .emacs
18:55.32brlcadthe only thing that might be affecting this is if local variable parsing is off by default in 23.2.1
18:55.43CIA-48BRL-CAD: 03tbrowder2 * r47060 10/brlcad/trunk/doc/docbook/resources/ (fonts/ other/fonts/): segregate external resources
18:55.58brlcaddo you know how to run M-x describe-variable c-file-style  ?
18:56.22brlcad(run that with a buffer open to src/libged/simulate/simulate.c
18:56.22abhi2011_brlcad: no I dont
18:56.45brlcadM-x is the starting key binding, usually "ESC x" or "ALT+x"
18:56.58CIA-48BRL-CAD: 03tbrowder2 * r47061 10/brlcad/trunk/doc/docbook/resources/other/offo/: restucturing external resources
18:57.03brlcadthen type "describe-variable[ENTER]"
18:57.21brlcadit'll prompt you for a variable name, type "c-file-style[ENTER]"
18:57.27abhi2011_ok
18:57.34brlcadif should split the buffer and show you the value
18:57.52brlcadsaying something like "Its value is 'stroustrup'"
18:57.57CIA-48BRL-CAD: 03tbrowder2 * r47062 10/brlcad/trunk/doc/docbook/resources/ (4 files in 4 dirs): segregate external resources
18:58.09abhi2011_ok got it, alt x
18:58.36abhi2011_hmm No match
18:58.39brlcadctrl-g ctrl-g if you mess up :)
18:58.52abhi2011for c-file-style
18:58.56abhi2011i ll have to set it
18:59.14brlcadno you don't
18:59.21abhi2011yeah its thr in the file
18:59.41brlcadM-x describe-mode
19:00.26brlcadshould be something like "C/l mode"
19:01.00abhi2011no match there either
19:01.15abhi2011though i did get lot of messages
19:03.20brlcadthen you're doing something wrong :0
19:03.22brlcad:)
19:03.27brlcadthere's always a mode
19:03.32abhi2011http://bin.cakephp.org/view/916412370
19:03.56brlcadah, Fundamental mode
19:04.01abhi2011:P
19:04.02brlcadthat's wrong
19:04.14brlcador you were in the wrong buffer
19:05.08abhi2011ok wait
19:05.24abhi2011i think i did not open a buffer to simulate.c
19:05.27abhi2011thats why
19:05.35brlcadah, yes
19:05.42brlcad*before* running M-x .. make sure your cursor is in the buffer for simulate.c
19:06.07brlcad"C-x o" will jump to the "other"/next buffer
19:06.30CIA-48BRL-CAD: 03tbrowder2 * r47063 10/brlcad/trunk/doc/docbook/resources/other/fonts/truetype/stix-v1.0.0/README: document version of the STIX fonts
19:06.51abhi2011ok c file style is strousup
19:07.07abhi2011*stroustrup
19:07.20brlcadso last thing to check..
19:07.38brlcadand that's "good" because it means it read the local vars block
19:07.53abhi2011mode is C/l mode
19:08.20brlcadM-x describe-variable c-indentation-style
19:08.24brlcadgreat
19:09.10abhi2011stroustrup
19:09.23abhi2011next must check indetation value
19:10.05abhi2011c-indentation-style's value is "stroustrup"
19:10.08abhi2011Local in buffer simulate.c; global value is nil
19:12.04brlcadthat's right
19:12.57abhi2011it indents c++ files correctly
19:13.02abhi20114 spaces
19:13.25brlcadnow the big one: M-x describe-variable c-style-alist
19:13.58brlcadpastebin the whole thing or at least the section where "stroustrup" begins
19:14.27CIA-48BRL-CAD: 03tbrowder2 * r47064 10/brlcad/trunk/doc/docbook/resources/other/fonts/truetype/ (stix/ stix-v1.0.0/): rename to remove version
19:15.54abhi2011http://bin.cakephp.org/view/1824577032
19:16.11abhi2011(c-basic-offset . 2)
19:16.42abhi2011hmm no for stroustrup its correct at 4
19:16.59brlcadexactly, something else is going on
19:17.31brlcadgo to the first function in simulate.c and press tab down each line starting at the beginning of the function
19:17.40brlcaddoes it indent the lines to 4 or leave them at 2 ?
19:18.14CIA-48BRL-CAD: 03tbrowder2 * r47065 10/brlcad/trunk/doc/docbook/resources/other/fonts/truetype/ (dejavu-lgc/ dejavu-lgc-fonts-ttf-2.33/): rename to remove version
19:20.27*** join/#brlcad merzo (~merzo@137-237-132-95.pool.ukrtel.net)
19:20.44CIA-48BRL-CAD: 03tbrowder2 * r47066 10/brlcad/trunk/doc/docbook/resources/other/fonts/ (dejavu-lgc/ stix/ truetype/dejavu-lgc/ truetype/stix/): restructure external resources
19:20.50abhi2011hmm no matter what i insert : spaces or tab at the beginning of each line of the 1st function, its forcing it all back to 2 spaces indent
19:21.15abhi2011maybe i can try running the formatting command from inside emacs
19:21.26abhi2011as soon as I know wat it is :P
19:23.59CIA-48BRL-CAD: 03tbrowder2 * r47067 10/brlcad/trunk/doc/docbook/resources/other/fonts/truetype/: remove unused dir
19:24.23brlcadabhi2011: if tab isn't indenting to column 4, something else is still overriding
19:24.52brlcadwith mode C/l and style stroustrup, indent shoudl be 4
19:25.04brlcaddo you have a .emacs file?
19:25.09abhi2011yes
19:25.14brlcadpastebin?
19:26.13abhi2011http://bin.cakephp.org/view/994500422
19:26.20starseekernever could get emacs to indent right...
19:26.38brlcadstarseeker: or vim :P
19:27.10starseekerbrlcad: what about using astyle?  can it do what we need?  That would avoid requiring any specific editor (or version of that editor...)
19:27.27starseekerhttp://astyle.sourceforge.net/
19:27.53CIA-48BRL-CAD: 03tbrowder2 * r47068 10/brlcad/trunk/doc/docbook/resources/other/offo/README: document what version of offo this is
19:28.19brlcadstarseeker: are you offering to set up the style file? :)
19:28.46brlcada tool is a tool, you'd still have to spell out the style in detail to astyle just like is being done here
19:28.50starseekerif it would resolve all of this and give us a consistent, editor independent way to proceed it would be worth it
19:29.00CIA-48BRL-CAD: 03tbrowder2 * r47069 10/brlcad/trunk/doc/docbook/resources/other/offo/ (binary/ offo-hyphenation-binary-v2.0/): rename to remove version
19:29.01starseekernods - I can give it a go
19:29.14abhi2011hmm there is a .gnu-emacs file too
19:29.16brlcadfrom indent.sh's pespective, it isn't an editor -- it might as well be running astyle
19:29.21abhi2011in /etc/skel
19:29.30abhi2011thats probaly loaded
19:29.35brlcadabhi2011: but is there a .gnu-emacs in your home dir?
19:29.46CIA-48BRL-CAD: 03tbrowder2 * r47070 10/brlcad/trunk/doc/docbook/resources/other/offo/ (offo-hyphenation-source-v2.0/ source/): rename to remove version
19:29.49abhi2011no
19:30.16starseekerbrlcad: right.  I just mean it's probably a better bet to get astyle doing the exact same thing consistently than an editor (I'm clearly not the only one having emacs troubles...)
19:30.16brlcadwhat's in the one in skel?
19:30.57starseekergrabs astyle for a look while tbrowder2 is organizing...
19:31.11brlcadstarseeker: I don't disagree, it's just actually at least a solid days work to get the style spelled out correctly
19:31.50abhi2011saw this in the gnu-emacs file: http://bin.cakephp.org/view/89434569
19:31.59starseeker<snort> considering the number of times I barf all over ws/indenting, I'll probably make up the time in fairly short order (or save you cleaning it up, anyway :-P)
19:32.06brlcadand last I checked, astyle had some significant bugs that made it parse either macros or C++ files poorly .. been a while
19:32.49brlcadabhi2011: that looks benign
19:34.42brlcadbasically saying that it "should" be a better bet to get something like astyle going, but five years ago emacs was the only one that actually got it right for both our C and C++ files by just saying "use stroustrup style" plus a few pedantic tweaks
19:35.37starseekernods - well, it looks like astyle has been developed since then so perhaps worth anothe rlook
19:35.44brlcadif it does better now, that'd be great but it'll beg for some careful testing
19:36.12brlcadfor example, libbu is pretty clean right now -- should be able to run it on the files there and basically have nothing change
19:36.47abhi2011i wrote a * c-basic-offset: 4 in the trailer :P
19:36.53abhi2011it worked now
19:37.15brlcadexcept maybe for a few nicities that astyle can manage that emacs cannot, like making sure there is curlies on the if clause there are curlies on the else clause and vice-versa
19:37.21abhi2011beginners can get really silly :P
19:37.33brlcadabhi2011: that's still *highly* suspect
19:37.45brlcadthat means it's not necessarily applying stroustrup style
19:37.47CIA-48BRL-CAD: 03tbrowder2 * r47071 10/brlcad/trunk/doc/docbook/create-xml-catalogs.pl: rename dirs for new structure
19:37.52abhi2011hmm yeah
19:38.31brlcadindent them and commit, I can retest on my end to see if anything else changes
19:44.04CIA-48BRL-CAD: 03tbrowder2 * r47072 10/brlcad/trunk/doc/docbook/fop.xconf.in: make more general - absolute file path for out-of-directory build
19:45.41abhi2011hmm, the indenting seems to have a number of passes , it indented the simulate.h correctly while doing these passes (i reloaded the file while it was indenting) then in some subsequent pass it indented back to 2
19:45.50abhi2011the simulate.c file is still correct
19:46.01abhi2011says its Loading vc-svn...
19:47.56CIA-48BRL-CAD: 03tbrowder2 * r47073 10/brlcad/trunk/doc/docbook/fop.xconf.in: update font path for restucturing
19:48.25abhi2011will do a build then commit
19:49.22brlcadvc-svn is to be expected, it knows the file is from svn
19:49.57brlcadabhi2011: another thing you can try, use this .emacs file: http://brlcad.org/wiki/Emacs
19:50.08brlcadyou'll have to restart emacs in order for it to be loaded properly
19:50.43brlcadshouldn't affect anything but it might turn off some hook that was being registered by default
19:51.57abhi2011ok, btw I dont use emacs for normal editing, eclipse is kinda easier :P
19:54.58CIA-48BRL-CAD: 03brlcad * r47074 10/brlcad/trunk/src/libged/bot_flip.c: instead of manually searching down path elements, just use bu_basename(). it does exactly that and is the well defined reusable interface.
20:00.29abhi2011hmm that .emacs didnt make a difference
20:02.32CIA-48BRL-CAD: 03brlcad * r47075 10/brlcad/trunk/src/libged/ (bot_split.c bot_sync.c):
20:02.32CIA-48BRL-CAD: more reuse of bu_baseame() instead of replicating the same strrchr() code.
20:02.32CIA-48BRL-CAD: probably deserves a librt routine for getting a basename from a path so we can
20:02.32CIA-48BRL-CAD: avoid dynamic memory but this is still a reuse improvement for now.
20:02.53brlcadabhi2011: well that's good to hear -- it shouldn't have made a difference :)
20:03.36brlcadso there's basically just something else going on that is perhaps specific to emacs 23, which I don't have handy to test on
20:04.18abhi2011brlcad: time to upgrade :)
20:05.29CIA-48BRL-CAD: 03abhi2011 * r47076 10/brlcad/trunk/src/libged/simulate/ (simulate.c simulate.h): Corrected indenting by adding c-basic-offset: 4 to file trailer and running indent.sh only
20:06.12brlcadabhi2011: and emacs is notorious for it's learning curve -- it takes a solid week to get the basics fluent -- but definitely pays off in the long run with the usability and programmability efficiencies it affords (at least in my experience and everyone I've known that made it over the learning curve)
20:10.38CIA-48BRL-CAD: 03brlcad * r47077 10/brlcad/trunk/misc/batch-indent-region.el: set the c-basic-offset forcibly in case there's something specific about batch mode in emacs23
20:11.16brlcadabhi2011: you said it was working sometimes indenting correctly and other times not?
20:13.14abhi2011well no, i reloaded the file in gedit while the indentation was going on, and then i noticed that the lines in simulate.h only were indented by 4 spaces
20:13.40abhi2011but when the indent script finished, i reloaded again and it was 2 spaces again
20:14.13abhi2011that made me think that maybe it was doing it correctly, but later on something over rode the default indenting
20:18.02brlcadif you remove the local variable (the line in the footer) and re-run indent.sh after r47077, does it correctly indent to 4?
20:30.27abhi2011brlcad: nope, its back to 2 again
20:31.52*** join/#brlcad _pseudonym (~tvanruite@yoshi.ece.utexas.edu)
20:34.20brlcadabhi2011: k, researching
20:34.40abhi2011brlcad: thanks :)
20:35.01brlcadpretty awesome.. fully svg website: http://emacsformacosx.com/
20:35.55CIA-48BRL-CAD: 03brlcad * r47078 10/brlcad/trunk/misc/batch-indent-region.el: no-go, remove the basic offset since files are supposed to define it via their style.
20:38.07n_reedbrlcad: nice. if i scale the page in my browser, i can see the fallback msg for people with ie
20:39.53CIA-48BRL-CAD: 03tbrowder2 * r47079 10/brlcad/trunk/doc/docbook/Makefile.am: correct path for new offo hyphenation binary
20:43.44starseekerah, phooey - astyle --style=stroustrup isn't a no-op on vls.c
20:44.03brlcadabhi2011: bah, 23.3 is working just fine here...
20:44.51brlcadstarseeker: stroustrup might be the same word but doesn't necessarily mean the same thing to those two apps
20:45.07starseekernods
20:45.22brlcadyou'd hope it meant something close to similar
20:45.44brlcadbut to astyle's credit, they have a lot more knobs to worry about when it comes to formatting
20:45.51starseekerwhitespace didn't agree, other than that just a few bracket placements
20:46.07starseekerwill poke at it some more
20:46.08abhi2011hmm
20:46.25brlcadstarseeker: like I said, it's going to take nearly a full day at best to get right
20:46.44brlcaduseful to have, but it is a distraction
20:46.44starseekernods
20:47.09starseekerso is trying to figure out why emacs is being quirky :-P
20:47.34brlcadonly because I don't have access to his box to poke at it myself
20:48.12brlcaduntil I updated, could only assume it was something 23-specific, but even that isn't proving to be the case
20:48.58brlcadabhi2011: so don't worry about style for now -- but ws.sh should still work
20:49.08brlcadit uses manual regexps
20:49.25brlcadif you're going to use emacs, I can send you some lines to put in your .emacs file that will make it work
20:49.58brlcadotherwise you'll just have to follow convention on braces and internal spacing
20:51.18abhi2011brlcad: yes please send me the lines, I ll be using emacs to format it , through the indent.sh script
20:52.51starseekerhere's what astyle is doing with vls.c by default:  http://bzflag.bz/~starseeker/vls_astyle.c
20:53.13starseekeractually doesn't look bad, at a glance...
20:55.24abhi2011so is there an easy way to draw a line in the mged window
20:55.29abhi2011I need to draw some normals
20:55.40starseekersome of the stuff it indented, I'm almost wondering why it wasn't indented that way initially...
20:56.18abhi2011otherwise i ll use a bot, with 1 triangle
20:57.10*** join/#brlcad mattS_ (cb3af1be@gateway/web/freenode/ip.203.58.241.190)
20:59.02mattS_Hi there, looking for some background info on the "revolve" project; is there anyone here who knows a bit about it?  Specifically, I'm looking for some fundamental background details, as opposed to questions about the current code.
21:03.07brlcadstarseeker: yeah, I'm seeing lots of undesirableness already
21:03.24brlcadat least, rather drastic style changes
21:03.41mattS_Or, for that matter, anyone familiar with the projective geometry employed in most any raytrace alg. in brlcad.
21:03.45brlcadeliminated all tabs, unindented case statements
21:03.48brlcadmattS_: howdy
21:04.02mattS_brlcad: Hi.
21:04.27brlcadmattS_: I saw your thread with pacman87 earlier, sounds fantastic
21:04.49brlcadhopefully can help, what are your questions?
21:05.14brlcad"<starseeker> some of the stuff it indented, I'm almost wondering why it wasn't indented that way initially"  such as?
21:05.24mattS_well, the thing I'm struggling with at the moment is *why* everything involves a hyperbolic transformation.
21:05.57brlcadyou'll have to point me at some code, what are you referring to specifically?
21:06.19mattS_Hm, hang on...
21:07.20brlcadotherwise, I'm not sure that's a true statement .. some of the primitives are cubit, quadratic, quartic, ...
21:07.30mattS_This is from an old correspondence with pacman that I left hanging:
21:07.33mattS_There are two parts to a sweep: the sketch (2d surface outline), and the path (3d spline).  For a revolve, the path is a circle.  My basic algorithm for shot() is: 1. Calculate a transformation to make the sweep path a straight line. 2. Apply the transformation to the ray. 3. Project the transformed ray onto the sketch plane. 4. Find all intersection points between the ray and the sketch.  The ray is given in terms of a point, vector
21:08.08mattS_<PROTECTED>
21:08.17starseekerbrlcad: line 57 - the bu_bomb
21:08.28mattS_The sketch uses 4 types of lines: line segments, circular arcs, bezier splines, and nurbs.  If the 3d spline is piece-wise define, then the transformation will also be piecewise defined, and the intersection check in (4) will have to check each ray piece with each sketch piece.
21:08.41mattS_For the specific case of a revolve, the transformed ray will be a hyperbola in 2d, so steps 1-3 can be condensed into finding the hyperbola given the point and vector of the ray, and the point and vector about which to revolve.
21:09.01mattS_<end quote>
21:09.03brlcadstarseeker: it didn't change the indent on that line, it removed the tab
21:09.20starseekerah
21:09.30starseekertries with tabs turned on...
21:09.37mattS_So, what I'm missing is where the hyperbola comes from in the transformation...
21:09.55mattS_Or, more specifically, what the transformation is, I guess.
21:10.33mattS_I'm assuming that something similar is done elsewhere in the software, hence the approach.
21:11.21mattS_But, in order to attempt to finish things off, I need to "get" what it is that is going on.
21:12.01brlcadmattS_: actually, I don't believe that approach is taken elsewhere in the software (because it doesn't need to)
21:12.15brlcadexcept for maybe the hyperbola primitive ;)
21:12.24brlcadhyperboloid
21:12.42mattS_OK, so if I were to try something different, that wouldn't mess things up elsewhere?
21:13.00brlcadwhich actually may be where he's got the idea from -- he implemented the hyperboloid of one sheet primitive
21:13.20mattS_Yes, I saw that.
21:15.52mattS_OK, I'll try putting something together then, and if I can get it working at all, then I'll hope that somebody here with better programming skills than me (I'm an engineer with a strong mathematics background) can help me clean things up.
21:16.28mattS_But I really would like to understand the logic behind what he's done...
21:16.30brlcadI'm not exactly seeing how it's a hyperboloid myself, but then I've only been thinking about it all of 2 minutes now
21:16.51mattS_Yeah, that's where I'
21:16.59brlcadthings make much more sense to me in code form ;)
21:17.13mattS_I'm stuck.  The steps are all fairly straightforward, I just don't get why he's done them.
21:17.55mattS_OK, have a look at brlcad/trunk/src/librt/primitives/revolve/revolve.c
21:18.20brlcadmattS_: I assume you have a general understanding of the transformations being aplied to the ray in general, yes?
21:18.42mattS_I thought I did...
21:18.46brlcadeven for something as simple as the sphere, it's not just plugging in values into the quadratic formulat
21:19.03mattS_Yes, I know that.
21:19.13brlcadit transforms the sphere into an idealized unitized sphere at the origin, then transforms the ray to match
21:19.20brlcadin order to give stable numerics
21:20.38mattS_Yup, based around a mapping of the surface onto the plane.
21:21.36mattS_So there would be a transformation of the g_{ij} metric based on...
21:21.42mattS_some sort of projection.
21:21.44mattS_?
21:22.30mattS_I'm assuming it's this projection that leads to the hyperbolic transform, which is where I guess my question lies.
21:23.00brlcadhm, maybe
21:23.18brlcadthat'd actually be a great question to pose to the mailing list or to d_rossberg if you can catch him in here
21:23.34mattS_Do you know where I could read up on this sort of stuff?
21:23.36brlcadhe was pacman's gsoc mentor so he's a lot more familiar with the project and approach taken
21:23.54brlcadmailing list: brlcad-devel on sourceforge
21:24.02mattS_OK, I could try emailing him as well...
21:24.11mattS_do you know if that's possible?
21:24.37brlcadthat'd be the mailing list
21:24.56mattS_I'm new to this; how do I access the mailing list?
21:25.00brlcadeasiest way to reach him and maybe get some input from other devs too
21:25.23brlcadmailing lists are all listed here: https://sourceforge.net/mail/?group_id=105292
21:25.36brlcadyou'll want to subscribe to at least this one: https://lists.sourceforge.net/lists/listinfo/brlcad-devel
21:26.16brlcada source code reference that *may* be of reference that goes into extensive math detail is the elliptical hyperboloid primitive
21:26.31brlcadit documents the algorithm in nicedetail
21:26.39brlcadsrc/librt/primitives/ehy/ehy.c
21:27.31brlcadif pacman is somehow approaching the surface as some sort of hyperboloid transformation, he may be using similar techniques that would be documented in the hyp primitive
21:27.37brlcader ehy primitive
21:27.53mattS_Could be.
21:28.37brlcadstarseeker: also note that case statements should be indented from switches, as should case body lines
21:29.47mattS_OK, subscribed.  I'll have a look at ehy.c, and post question(s) to the mailing list.
21:29.53mattS_Thanks for the help!
21:29.57starseekerbrlcad: I'm emailing the astyle author - not immediately clear to me if he supports the mixed spaces and tabs style we're using
21:30.24starseekerwhen I turn on tabs, it replaces our 4 space indents with tabs too
21:32.10starseekermight be a bug, more probably I'm doing something wrong
21:32.14mattS_OK, back to work for now...
21:32.48brlcadmattS_: a much simpler algorithm explanation of a quadratic is in src/librt/primitives/ell/ell.c
21:33.03brlcadpacman would have also have gone over that as a foundation
21:33.14brlcadstarseeker: definitely does
21:33.55brlcadit's one of only three common indent styles
21:34.02brlcadonly spaces
21:34.03brlcadonly tabs
21:34.07brlcadand mixed
21:34.43brlcadthen you have the concept of indent levels and tabstops to get what you want
21:35.33starseekerso far has yet to find a combination of options that doesn't rejigger our whitespace
21:39.08*** part/#brlcad n_reed (~nreed1@ool-457cb1ab.dyn.optonline.net)
21:41.25brlcadstarseeker: what about "-s4 -t"
21:41.49brlcador -s4 -T4
21:42.26starseekershakes his head - neither one
21:42.45starseekerwas thinking along those same lines - that's why I emailed him, one of those ought to have worked
21:44.04starseekerbrlcad: might be able to add -S and -K to address some of the switch/case concerns
21:44.15starseekerif we can get the whitespace to behave
21:44.37brlcadon the offchance it doesn't, I'd shelve the project for the time-being since changing the indent is going to affect every file and is a bit more of a major change
21:44.47starseekernods
21:45.04starseekeryeah, I have no desire to tangle with it
21:45.21starseekerjust thought I'd check and see if the problem could be solved once and for all
21:46.55*** join/#brlcad merzo (~merzo@137-237-132-95.pool.ukrtel.net)
21:49.41brlcadstarseeker: what about -s4 -t8
22:03.56starseekernope :-/
22:05.29starseekerauthor just replied - "currently no way to do this with astyle"
22:12.53*** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net)
22:27.11brlcadstarseeker: wow, that's surprising
22:27.25brlcadoh well
22:29.31brlcadwe could update our style to the next best compromise, but it'd probably be better to hold off for a planned minor
23:02.14starseekernods - yeah, change on that scale'd be a minor for sure
23:02.50starseekergrins - maybe we could plan it for the same time as the copyright update - as long as we're touching so many files anyhow, kill two birds with one stone
23:04.13starseekerooo, interesting:  http://code.google.com/p/chibi-scheme/
23:27.52*** join/#brlcad bhinesley (~bhinesley@99.144.92.88)
IRC log for #brlcad on 20111005

IRC log for #brlcad on 20111005

01:00.47CIA-48BRL-CAD: 03brlcad * r47080 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simphysics.cpp): minor alignment
02:39.49CIA-48BRL-CAD: 03starseeker * r47081 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt resources/brlcad/brlcad-xml-catalog.xml.in): Accomidate new directory locations
03:05.51CIA-48BRL-CAD: 03brlcad * r47082 10/brlcad/trunk/src/librt/comb/comb.c: leave a NOTE about the anamoly so it's documented and so someone doesn't accidentally remove it later without understanding the implications.
03:18.36CIA-48BRL-CAD: 03brlcad * r47083 10/brlcad/trunk/src/libged/simulate/simulate.h: include vmath. headers need to include the headers they require.
03:25.59CIA-48BRL-CAD: 03brlcad * r47084 10/brlcad/trunk/src/libged/simulate/ (4 files): header cleanup. helps to identify redundant and avoid cyclic includes.
03:48.50CIA-48BRL-CAD: 03brlcad * r47085 10/brlcad/trunk/NEWS:
03:48.50CIA-48BRL-CAD: richard improved the g-vrml exporter so that it no longer halts conversion on
03:48.50CIA-48BRL-CAD: the first bomb encountered, but now keeps track of the failure count and
03:48.50CIA-48BRL-CAD: continues processing (similar to the other converters). this feature was
03:48.50CIA-48BRL-CAD: requested by tim mallory and has been mentioned by other users.
04:00.57CIA-48BRL-CAD: 03brlcad * r47086 10/brlcad/trunk/NEWS:
04:00.57CIA-48BRL-CAD: I implemented a new g-dot exporter for exporting to the Graphviz DOT format,
04:00.57CIA-48BRL-CAD: allowing for impressive visualization of geometry structure's DAG. intended as
04:00.57CIA-48BRL-CAD: a plugin piece for the GCV/GS and new geometry editor (way) down the road.
04:07.54CIA-48BRL-CAD: 03brlcad * r47087 10/brlcad/trunk/NEWS: (log message trimmed)
04:07.55CIA-48BRL-CAD: richard also added new options to the g-vrml exporter. to quote: Significate
04:07.55CIA-48BRL-CAD: updates to the 'g-vrml' converter. Some logic bugs were fixed. Triangulation was
04:07.55CIA-48BRL-CAD: changed to use 'nmg_triangulate_model' instead of its own function which was
04:07.55CIA-48BRL-CAD: very limited. Added two new options. A '-b' option to perform a bot dump (all
04:07.55CIA-48BRL-CAD: csg geometry is ignored) and '-e' to perform an evaluation or all opjects
04:07.56CIA-48BRL-CAD: including bots. By default bots are dumped and csg evaluation is perform
06:39.32*** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net)
06:40.34*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
06:40.53*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
09:42.16*** join/#brlcad merzo (~merzo@193.254.217.44)
11:01.31CIA-48BRL-CAD: 03abhi2011 * r47088 10/brlcad/trunk/src/libged/simulate/simulate.c: Added code to display the normals generated at each manifold
11:48.05CIA-48BRL-CAD: 03tbrowder2 * r47089 10/brlcad/trunk/HACKING: add comma
12:24.16CIA-48BRL-CAD: 03abhi2011 * r47090 10/brlcad/trunk/src/libged/simulate/simutils.c: Number of functions hitting the roof, moving utility stuff out to seperate file
12:24.47CIA-48BRL-CAD: 03abhi2011 * r47091 10/brlcad/trunk/src/libged/simulate/simutils.h: Number of functions hitting the roof, moving utility stuff out to separate file
12:26.15CIA-48BRL-CAD: 03abhi2011 * r47092 10/brlcad/trunk/src/libged/ (CMakeLists.txt simulate/simulate.c): Modified simulate.c to use the the utils from the utility files now and some related cmake changes
13:20.42CIA-48BRL-CAD: 03abhi2011 * r47093 10/brlcad/trunk/src/libged/simulate/ (simulate.c simutils.c simutils.h): Corrected some code related to prefixing names
13:46.48CIA-48BRL-CAD: 03bob1961 * r47094 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added ArcherCore::redrawWho.
13:52.04CIA-48BRL-CAD: 03bob1961 * r47095 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl:
13:52.04CIA-48BRL-CAD: Added a tool panel to the attributes view panel and initially populated it with
13:52.04CIA-48BRL-CAD: a set of component pick mode radiobuttons and a few bot related buttons for
13:52.04CIA-48BRL-CAD: splitting, syncing and/or flipping bots. Added a radiobutton to the attribute
13:52.04CIA-48BRL-CAD: view's toolbar and updated the images associated with the buttons.
13:56.28CIA-48BRL-CAD: 03bob1961 * r47096 10/brlcad/trunk/src/tclscripts/archer/images/ (5 files): Added tools.png and option_edit.png. Removed option_tree.png. Updated option_text.png
14:30.22brlcadabhi2011: you have a series of memory leaks in the simulate code
14:31.11brlcadif you know how to run valgrind or some other memory debugger, it'd probably be a good time to clean up memory management
14:31.35brlcadbasically for every bu_malloc/bu_calloc there needs to be a corresponding bu_free call
14:32.03brlcadand for every bu_vls, there needs to be a bu_vls_free() call
14:32.36*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
14:37.06CIA-48BRL-CAD: 03brlcad * r47097 10/brlcad/trunk/NEWS:
14:37.06CIA-48BRL-CAD: bob added a new panel (and menu) of edit pick options to archer for cleaning up
14:37.06CIA-48BRL-CAD: non-solid BoT geometry. initially populated it with a set of component pick
14:37.06CIA-48BRL-CAD: mode radiobuttons and a few bot related buttons for splitting, syncing and/or
14:37.06CIA-48BRL-CAD: flipping bots.
14:40.59brlcadstarseeker: browder's latest reminds me that cmake should be doing a test for perl existence if it's not already, and disabling docs if it doesn't exist (assuming perl is used in any fashion)
15:13.13starseekerbrlcad: I just this second (literally, within the minute ;-) got a pdf build with the covers using just CMake and templates :-)
15:13.43starseekerlet me commit and we'll see what he thinks
15:21.47CIA-48BRL-CAD: 03starseeker * r47098 10/brlcad/trunk/doc/docbook/ (3 files in 2 dirs): Add CMake logic to support the covers on the Tutorial volumes.
15:30.53abhi2011brlcad:  yes, i was trying pinpoint them using valgrind yesterday
15:31.22abhi2011haven't quite figured out which functions exactly yet
15:34.13abhi2011any easier tool that can be used to detect the region of code whr leaks are happening
15:40.51CIA-48BRL-CAD: 03brlcad * r47099 10/brlcad/trunk/NEWS:
15:40.51CIA-48BRL-CAD: the obj-g importer has gotten lots of love and attention from nick and richard
15:40.51CIA-48BRL-CAD: over the past year. none of it was user-visible until very recently, so begin
15:40.51CIA-48BRL-CAD: documenting the changes. bigger announcement will get added on the next minor
15:40.51CIA-48BRL-CAD: bump summarizing the new importer.
15:44.46brlcadabhi2011: valgrind is about as good as it gets :)
15:45.08brlcadit tells you exactly where the allocation occurred that wasn't released
15:45.46brlcadone place, for example, is a function you wrote that adds a prefix -- it creates a vls, prints into it, then returns the char * to that vls
15:46.04CIA-48BRL-CAD: 03starseeker * r47100 10/brlcad/trunk/doc/docbook/CMakeLists.txt: handle brlcad.css
15:46.06brlcadonce you leave that function, you no longer have access to that vls, so you cannot call bu_vls_free() to properly release the memory allocated
15:47.20brlcadbest is to probably return the vls* instead of a char* so you can free it later
15:47.28abhi2011yes
15:47.51brlcador just start with a vls beforehand
15:47.56brlcadthen you don't even need that function
15:47.57abhi2011was thinking something might be wrong with that, due to the cha* inside
15:48.07brlcadit's basically a one-liner print
15:48.30abhi2011yes, that would be better
15:48.44abhi2011the linked lists should be ok though
15:48.48abhi2011there is 1 big list
15:48.50starseekerwoo hoo!
15:48.53abhi2011for the rigd bodies
15:49.01abhi2011and another for the manifolds
15:49.36brlcadstarseeker: what was the last/current status on the exists command?  is it in there usable now, or not yet?
15:49.37abhi2011i think the last iteration , causes the manifold list to not be freed
15:50.03starseekerum, iirc it's usable but still very basic
15:50.05brlcadmanual linked list or a bu_list ?
15:50.13brlcadstarseeker: that's fine - but it's there?
15:50.18starseekernods
15:50.20abhi2011manual linked list
15:50.21brlcadok
15:50.43starseekerman page is a lier at the moment because I was trying to outline all the eventual planned features
15:51.04brlcadwhat was the original command name from bob? was it test?
15:51.07starseeker*might* have basic boolean operations going, but not sure how robust that'll be
15:51.18starseekerurm
15:51.29starseekerdon't recall - I can ask him later today
15:51.33brlcad'urm' is a funny command name :)
15:51.38starseekerhehe
15:51.44starseekergood alias for help
15:52.04starseekeris at home at the moment - needed the flexible setup for Apache FOP stuff
15:52.27brlcadnods, no worry -- just getting a commit message worded right
15:52.45starseekerI think it's in the commit history
15:53.06starseekerLOL - "Ubuntu" - an African word meaning "Gentoo is too hard for me".
15:53.28CIA-48BRL-CAD: 03brlcad * r47101 10/brlcad/trunk/NEWS:
15:53.28CIA-48BRL-CAD: sparked by a new testing command added by bob parker, cliff stubbed in initial
15:53.29CIA-48BRL-CAD: functionality for a new 'exists' command. this command is intended to be a
15:53.29CIA-48BRL-CAD: corollary to the unix 'test' command with features for detecting various
15:53.29CIA-48BRL-CAD: geometry conditions and expressions
15:56.25CIA-48BRL-CAD: 03brlcad * r47102 10/brlcad/trunk/BUGS: make a note, exists documentation claims more than is possible
16:09.25CIA-48BRL-CAD: 03brlcad * r47103 10/brlcad/trunk/BUGS: bot bbox routine isn't calculating the bbox correctly
16:12.13CIA-48BRL-CAD: 03brlcad * r47104 10/brlcad/trunk/NEWS: by converting the flex/bison logic to re2c/lemon, that effectively ported the obj-g importer to windows since it can now be compiled without the flex/bison dependency.
16:17.31CIA-48BRL-CAD: 03brlcad * r47105 10/brlcad/trunk/NEWS:
16:17.31CIA-48BRL-CAD: a lot of fingers have been in the obj-g pie. document the new obj parser
16:17.31CIA-48BRL-CAD: engine, originally written by mike tegtmeyer, integrated by richard weiss, and
16:17.31CIA-48BRL-CAD: rewritten/translated by nicholas reed. the fact that it's a structured parser
16:17.31CIA-48BRL-CAD: improves parsing robustness.
16:18.29brlcadwhew.. only 218 to go
16:22.23CIA-48BRL-CAD: 03brlcad * r47106 10/brlcad/trunk/NEWS: abhijit nandy (abhi2011) fixed an mged crash where bad things happened if you killed an object that was illuminated for editing. no longer crashes by testing for NULL.
16:23.22abhi2011naaaaece :)
16:25.17CIA-48BRL-CAD: 03brlcad * r47107 10/brlcad/trunk/NEWS:
16:25.17CIA-48BRL-CAD: abhijit nandy added a new 'simulate' command to mged/archer that allows applying
16:25.17CIA-48BRL-CAD: physical interactions such as gravity, friction, and linear/angular
16:25.17CIA-48BRL-CAD: accelleration forces. this is anticipatory documentation for the next minor
16:25.17CIA-48BRL-CAD: release bump, but warrants a paragraph highlight with additional detail.
16:27.00abhi2011*acceleration
16:56.35CIA-48BRL-CAD: 03brlcad * r47108 10/brlcad/trunk/src/librt/db_path.c: add common footer, update style
17:03.31brlcadabhi2011: heh, noted
17:15.57CIA-48BRL-CAD: 03abhi2011 * r47109 10/brlcad/trunk/src/libged/simulate/ (simulate.c simutils.c simutils.h): Got rid of the prefix_name function which was hogging memory, directly using bu_vls instead
17:32.59brlcadabhi2011: heh, looks much better .. though you could have just named your vls strings prefixed_reg_name or whatever instead of having a separate pointer for the char*
17:33.39brlcadvls ARE strings
17:34.37abhi2011yeah I can do that, since I only need the actual pointer when passing command arguments
17:34.44abhi2011the char* I mean
17:35.03brlcadnods
17:39.20CIA-48BRL-CAD: 03brlcad * r47110 10/brlcad/trunk/src/librt/ (CMakeLists.txt Makefile.am parse.c): wow, duplicate file ignored (yet updated and maintained) for many years that doesn't even belong in here any longer. the struct parsing functions were migrated to libbu a long time ago, so delete this remnant file.
18:04.15CIA-48BRL-CAD: 03brlcad * r47111 10/brlcad/trunk/src/librt/uvpoints.cpp: add missing footer, update style and ws
18:08.21CIA-48BRL-CAD: 03brlcad * r47112 10/brlcad/trunk/src/librt/ (26 files): comment cleanup, remove F U N C T I O N _ N A M E S written out in comments since the reasoning becomes moot with the migration of comments into headers and automatic doxygen parsing.
18:09.32CIA-48BRL-CAD: 03brlcad * r47113 10/brlcad/trunk/src/librt/ (23 files): sweepting ws style indent and comment cleanup
18:56.23*** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net)
19:30.12CIA-48BRL-CAD: 03bob1961 * r47114 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Minor tweak to Archer::handleTreeSelect.
19:35.23``Erikbrlcad: bob is reporting issues with libged bot_* stuff on windows, it's doing bu_basename() on db stuff, which uses / on all platforms
19:55.06brlcad``Erik: ahhh, yes... that's because bu_basename() was changed to NOT use / on all platforms ...
19:55.25brlcadit was / .. and my mod would have worked
19:55.53brlcadbut I think he changed it to the platform's dir separator a while back, forgot about that
19:55.56brlcadI'll revert
20:01.45``Erikbu_db_basename() ?
20:04.34CIA-48BRL-CAD: 03bob1961 * r47115 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Tweaked Archer::pluginLoader to accomodate spaces in a filename.
20:05.15CIA-48BRL-CAD: 03brlcad * r47116 10/brlcad/trunk/src/libged/ (bot_flip.c bot_split.c bot_sync.c): revert the bu_basename() modification, back to r47050, since that function was updated to not only handle '/' but whatever the platform separator is. sorry bob.
20:11.48starseekeror just db_basename, since it's for .g files?
20:23.27``Erik<-- fond of the library prefix munge
20:39.10CIA-48BRL-CAD: 03abhi2011 * r47117 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simulate.c simulate.h simutils.c): Converted some strings to vls
21:00.45*** join/#brlcad mattS_ (cb3af1be@gateway/web/freenode/ip.203.58.241.190)
21:05.26brlcadhm, it might be as simple as keeping support for '/' in basename
21:06.21brlcadit would basically mean we wouldn't allow windows files with a / in the file name, which I don't think windows allows either
21:29.40``Erikdos used / as a mandatory switch, "dir/w"
21:29.47``Erikd'no about nt variants
21:43.26brlcadsure, but still wouldn't be in a path
21:44.06brlcadthis is isolated to places that would call basename()/dirname() feeding a path
21:45.38brlcadgiven we're not implementing dir with /switches, should be a safe assumption
22:22.39CIA-48BRL-CAD: 03brlcad * r47118 10/brlcad/trunk/src/libbu/test_basename.c: add a few more tests to make sure we get reasonable (dos-style) drive prefix behavior
22:36.10CIA-48BRL-CAD: 03brlcad * r47119 10/brlcad/trunk/ (include/bu.h src/libbu/basename.c): (log message trimmed)
22:36.10CIA-48BRL-CAD: enhanced bu_basename(), now with more slashy flavor. always interprets '/' as a
22:36.10CIA-48BRL-CAD: path separator in addition to whatever the native separator is so that we can
22:36.10CIA-48BRL-CAD: use libbu for geometry paths as well as filesystem paths. also added a quick
22:36.11CIA-48BRL-CAD: check to make sure drive paths are removed if this is windows so we don't get
22:36.11CIA-48BRL-CAD: the drive letter returned as a path. also started to add code to recognize
22:36.12CIA-48BRL-CAD: escaped paths but it turns out that the system basename() (bsd/mac) doesn't
22:36.15brlcadthere, now it should work
22:38.50CIA-48BRL-CAD: 03brlcad * r47120 10/brlcad/trunk/src/libged/ (bot_flip.c bot_split.c bot_sync.c): unrevert the r47116 revert of r47050, making the routines use bu_basename() for path trimming instead of rolling custom. does that fix it, bob?
23:24.00starseekergrowls... the hacked up hv3 tcl/tk html browsers we've been using aren't going to cut it when we add .css files into the mix, looks like
23:24.16starseekershould just get the full browser working...
23:24.48brlcador a Qt HTML window/app for down the road
23:25.11starseekereventually sure, but right now we don't want to add Qt as a requirement for help...
23:25.42starseekerhas had the full hv browser running in the past - thought I could "streamline" it down to just what we need but apparently that's not so simple
23:25.51CIA-48BRL-CAD: 03brlcad * r47121 10/brlcad/trunk/src/libbu/basename.c: simplify, just call bu_strdup() like bu_dirname() does
23:26.59starseekerI suppose there's no particular reason *not* to have http support...
23:28.49starseekeroh, well - I guess this is a good time to move the hv3 code back into src/other too
23:57.39CIA-48BRL-CAD: 03brlcad * r47122 10/brlcad/trunk/src/libbu/test_basename.c: couple more test cases, make sure escaping behavior works as expected (more important on windows where it becomes a dir separator).
IRC log for #brlcad on 20111006

IRC log for #brlcad on 20111006

00:02.12CIA-48BRL-CAD: 03brlcad * r47123 10/brlcad/trunk/src/libbu/ (Makefile.am test_dirname.c): add in a new unit test for bu_dirname() similar to bu_basename().
00:03.40CIA-48BRL-CAD: 03brlcad * r47124 10/brlcad/trunk/src/libbu/CMakeLists.txt: enable logic for new test_dirname binary. also removing what should be unnecessary link libraries (htond doesn't use libpng) and comment on bad MSVC platform toggle.
00:06.07CIA-48BRL-CAD: 03brlcad * r47125 10/brlcad/trunk/src/libbu/dirname.c:
00:06.07CIA-48BRL-CAD: similar to bu_basename(), make bu_dirname() also always treat unix-style '/'
00:06.07CIA-48BRL-CAD: forward slashes as path separators even on platforms that use a different
00:06.07CIA-48BRL-CAD: directory separator (windows). that will make the function continue to be
00:06.07CIA-48BRL-CAD: useful for geometry paths, which are always url/unix-style. fixed a bug
00:06.08CIA-48BRL-CAD: detected during unit testing while at it, collapsing sequences of trailing path
00:06.09CIA-48BRL-CAD: separators to just one.
00:18.30CIA-48BRL-CAD: 03brlcad * r47126 10/brlcad/trunk/include/bu.h: document the new bu_dirname() particulars as well as cleaning up the wording on bu_basename() too to be consistent.
00:19.23CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3174 10/wiki/User:Abhijit: /* Log */
00:20.54CIA-48BRL-CAD: 03brlcad * r47127 10/brlcad/trunk/include/bu.h: how about an informative parameter name
00:21.14*** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net)
00:25.09CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3175 10/wiki/User:Abhijit: /* Updated Development Time line(Sept 14th) */
00:26.03CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3176 10/wiki/User:Abhijit: /* Updated Development Time line(Sept 14th) */
00:27.32CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3177 10/wiki/User:Abhijit: /* Detailed project description */
00:30.22abhi2011Normals and contact manifolds getting drawn ok now : http://postimage.org/image/2dqu5964k/full/
00:30.42CIA-48BRL-CAD: 03brlcad * r47128 10/brlcad/trunk/NEWS: minor code, but technically user-visible -- archer will now load plugins with spaces in the name.
00:30.54abhi2011These are still bullet output, have to convert to raytrace yet
01:01.26CIA-48BRL-CAD: 03abhi2011 * r47129 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Began implementing a raytrace based manifold generator
01:07.34CIA-48BRL-CAD: 03abhi2011 * r47130 10/brlcad/trunk/src/libged/ (CMakeLists.txt simulate/simulate.c simulate/simulate.h): Related changes to simulate command to use the raytraced manifolds
01:33.59brlcadcool
02:12.36*** join/#brlcad mattS_ (cb3af1be@gateway/web/freenode/ip.203.58.241.190)
02:48.49CIA-48BRL-CAD: 03brlcad * r47131 10/brlcad/trunk/NEWS:
02:48.49CIA-48BRL-CAD: richard fixed a bug which caused a seg fault if a loopuse contained a single
02:48.49CIA-48BRL-CAD: vertex instead of an edgeuse. presumably this improves a tess case where
02:48.49CIA-48BRL-CAD: invalid geometry ends up in a loopuse that would later result in a bomb or
02:48.49CIA-48BRL-CAD: crash.
03:10.26CIA-48BRL-CAD: 03brlcad * r47132 10/brlcad/trunk/TODO: need to rerun previous conversion comparison to see how things have changed with all of the recent NMG changes
03:23.16starseekerhmm:  http://www.xmailserver.org/xdiff-lib.html
03:29.28starseekerhttp://code.google.com/p/dtl-cpp/
03:32.50CIA-48BRL-CAD: 03brlcad * r47133 10/brlcad/trunk/TODO: need to test the new edit command.
04:13.55CIA-48BRL-CAD: 03brlcad * r47134 10/brlcad/trunk/NEWS: richard fixed a bug in mged's mater command (in r45415) where the inheritance could not be changed unless the color is changed at the same. should affect archer too, but only tested with mged.
04:16.56CIA-48BRL-CAD: 03brlcad * r47135 10/brlcad/trunk/NEWS:
04:16.56CIA-48BRL-CAD: richard also committed a fix to a bug in the rm/erase command affecting at least
04:16.56CIA-48BRL-CAD: mged and presumably archer too. A segmentation fault would occur when a region
04:16.56CIA-48BRL-CAD: is displayed in 'mged' and the 'rm' command is used to remove a member of the
04:16.56CIA-48BRL-CAD: displayed region and the member occurs in the region more than once.
04:28.10CIA-48BRL-CAD: 03brlcad * r47136 10/brlcad/trunk/src/libgcv/bottess.c: there's no need to call rt_bot_ifree2() directly. create an rt_db_internal with the right juju and we can call rt_bot_ifree() which will call ifree2 for us. no more wet shoes.
04:29.24CIA-48BRL-CAD: 03brlcad * r47137 10/brlcad/trunk/src/libgcv/ (bottess.c region_end_mc.c): ws
04:34.32CIA-48BRL-CAD: 03brlcad * r47138 10/brlcad/trunk/src/librt/primitives/bot/bot.c: And lead us not into temptation, but deliver us from evil. rename rt_bot_ifree2() to bot_ifree2() so it's not considered public api. in fact, mark it hidden too.
04:38.22CIA-48BRL-CAD: 03brlcad * r47139 10/brlcad/trunk/NEWS:
04:38.23CIA-48BRL-CAD: richard made a slew of changes to improve NMG processing which have been
04:38.23CIA-48BRL-CAD: enabled, but not yet independently validated so schedule their announcement in
04:38.23CIA-48BRL-CAD: the next minor bump. one specific example is r45358 where he improved the
04:38.23CIA-48BRL-CAD: success of boolean ops when there coplanar faces. this affects mged
04:38.23CIA-48BRL-CAD: tessellation commands (facetize, E, ev) as well as most of our exporters.
04:40.22CIA-48BRL-CAD: 03brlcad * r47140 10/brlcad/trunk/NEWS: another category of changes richard made centered around improving boolean evaluation and NMG processing performance. don't yet have specific numbers, but document the changes anyways (see r45319)
04:46.01CIA-48BRL-CAD: 03brlcad * r47141 10/brlcad/trunk/src/librt/CMakeLists.txt: is this why autotools is still catching more errors that cmake build? remove the -Wno-error flag from non-static compilation.
04:52.58CIA-48BRL-CAD: 03brlcad * r47142 10/brlcad/trunk/NEWS: cliff improved the mged/archer 'attr' command to only halt on read-only databases if it's a write attr action. allow get/list/show
04:55.36CIA-48BRL-CAD: 03brlcad * r47143 10/brlcad/trunk/NEWS: cliff improved the mged/archer 'attr' command to only halt on read-only databases if it's a write attr action. allow get/list/show. credited to the .0 release.
04:58.04CIA-48BRL-CAD: 03brlcad * r47144 10/brlcad/trunk/NEWS:
04:58.04CIA-48BRL-CAD: bob worked around some glitches with the windows gl display manager by copying
04:58.04CIA-48BRL-CAD: display list data into a GLdouble array before sending to opengl (r44645)
04:58.04CIA-48BRL-CAD: remedying strange behavior on windows where arrows were sometimes being drawn
04:58.04CIA-48BRL-CAD: incorrectly. sounds like corrupt memory, but this works around the issue
04:58.05CIA-48BRL-CAD: successfull.
05:07.26CIA-48BRL-CAD: 03brlcad * r47145 10/brlcad/trunk/NEWS: keith improved the step-g importer fixing some issues importing ellipse and circle conics. another user-visible change that didn't make the .0 release notes.
05:09.55CIA-48BRL-CAD: 03brlcad * r47146 10/brlcad/trunk/NEWS: keith also improved the step-g importer presumably preventing it from crashing or otherwise doing bad things where it was overrunning an array during cubit interpolation. another undocumented change to the .0 release.
05:12.24brlcadstarseeker: r44618 looks no good.  if we don't have a void* then the void* test is flawed... that's kinda important to just gloss over it with a conditional..
05:16.34brlcadstarseeker: hm, looks like that was later fixed? (apologies, reading commits in reverse)
05:17.47brlcadi think what triggered caution is that I think I've seen the fallback case where it spits out "CMAKE_SIZEOF_VOID_P is not defined - assuming 32 bit platform" and that just shouldn't happen for any platform less than two decades old
05:24.49brlcadwasn't even you that made the original patch .. so that's probably a cue that my eyes are getting tired and need a walkabout break
05:32.53CIA-48BRL-CAD: 03brlcad * r47147 10/brlcad/trunk/misc/CMake/BRLCAD_CompilerFlags.cmake: ffast-math is never a good option for our code because the math that results is extremely unstable an unreliable for useful calculations.
05:58.43CIA-48BRL-CAD: 03brlcad * r47148 10/brlcad/trunk/src/librt/uvpoints.cpp: big cleanup. remove 'using namespace std' abomination, quell warnings, fix shadowings, and more.
06:03.35*** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net)
06:08.33brlcadpacman87: you still on the dev mailing list? question posed by the guy you referred in here about how exactly the ray path is hyperbolic
06:09.26brlcadstarseeker: better question, r44413 .. curious that black is not being written out.  the default color is actually white, so does that mean I can't create black objects? :)
06:10.16brlcadstarseeker: and AGAIN.. I see that you noticed the err in r44414! .. okay, I'll stop :)
06:11.11brlcadneeds to learn that there's probably a follow-up commit that addresses the red flag
06:35.07*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:40.43*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:25.26pacman87brlcad: it looks like d_rossberg has answered it fairly well, were there any specific points that still need to be addressed?
08:27.30pacman87http://en.wikipedia.org/wiki/Skew_lines#Skew_lines_and_ruled_surfaces might also be useful
10:47.33abhi2011is it possible to specify a rectangular grid of rays to be shot in a specific direction
10:47.58abhi2011rather than shooting the rays one by one, translating the direction across and up/down
11:23.30*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
11:23.46pawleeqhello
11:24.58pawleeqI am building current svn check and make ended with errors: http://pastebin.com/jrejqagB
11:49.16CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3178 10/wiki/User:Abhijit: /* Log */
12:03.42CIA-48BRL-CAD: 03abhi2011 * r47149 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simutils.c simutils.h): Added initial code to create the AABB overlap regions
12:33.31d_rossbergpawleeq: Makefile.am is out of date in src/tclscripts/archer/images but CMake should work
12:39.33pawleeqd_rossberg: i tried cmake brlcad, but cmake also failed, result is here: http://pastebin.com/GPfiMqXs
12:46.32d_rossbergi may only guess what's wrong: sometimes cmake needs to run twice; i've no *nix brl-cad at hand to test it
12:56.24CIA-48BRL-CAD: 03abhi2011 * r47150 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c simutils.c): Finished creating the AABB overlap regions
13:37.23CIA-48BRL-CAD: 03abhi2011 * r47151 10/brlcad/trunk/src/libged/simulate/ (5 files): Merged bullet and rt manifold info in 1 structure, easier that way
13:49.37CIA-48BRL-CAD: 03n_reed * r47152 10/brlcad/trunk/src/other/step/src/express/expparse_new.y: working through type-mismatch compile errors
13:54.19abhi2011pawleeq: you need to install ITK
13:54.34abhi2011thats the object oriented extension to tcl/tk
13:55.02abhi2011then the ITK_LIBRARY path will be set to the .so files which implements that library
13:56.08brlcadexcept we bundle itk so something else seems to be going wrong, unless it's using an incompatible system tcl/tk
13:56.17starseekerbinks - that shouldn't happen...
13:56.35starseekerpawleeq: can you post your configure log?
13:57.39starseekerwe really really really really need to get package require Itk working from bwish and friends
13:58.03abhi2011hmm then maybe he is not building itk during make
13:58.20starseekerno, it's not finding the ITK library
13:58.39starseekerbut it must be finding the Itk package itself, othewise it should have been turned on
13:59.53starseekermy best guess is that line 339 in src/other/CMakeLists.txt isn't succeeding
14:00.55starseekerpawleeq: where is the libitk.so on your system?
14:01.29starseekerif they stuck it in a weird place, that would explain the ITK_LIBRARY issue
14:02.27starseekerwe're not set up for it right now, but I suppose what I should be doing in those special cases is to build the local one in the case of ITCL_LIBRARY or ITK_LIBRARY not being found
14:03.13starseekerit breaks the paradigm being used for all the other Tcl/Tk packages, but it looks like I may not have a choice since the ITK_LIBRARY issue has appeared in the wild
14:03.34starseekerpawleeq: if you want to work around it, you can just feed cmake -DBRLCAD_BUNDLED_LIBS=Bundled
14:04.36CIA-48BRL-CAD: 03erikgreenwald * r47153 10/brlcad/trunk/src/libgcv/wfobj/tri_face.c: common.h needs to come before bu.h
14:14.24CIA-48BRL-CAD: 03starseeker * r47154 10/brlcad/trunk/src/other/CMakeLists.txt: Make a stab at turning Itcl/Itk back on if we can't find the libraries.
14:14.38starseekerew
14:14.44starseekerpawleeq: see if that helps...
14:16.36starseekermight end up having to build both Itcl and Itk if ITK_LIBRARY doesn't show up...
14:39.14pawleeqstarseeker: I will give it try and report back, but right now I am babysittter rather than brlcad enthusiast :)
14:46.05CIA-48BRL-CAD: 03erikgreenwald * r47155 10/brlcad/trunk/ (NEWS src/tclscripts/mged/reid.tcl): return last assigned id value from reid command
15:28.16CIA-48BRL-CAD: 03erikgreenwald * r47156 10/brlcad/trunk/ (NEWS src/tclscripts/mged/reid.tcl): Added a -n <val> arg to reid for incrementing by a specified value.
15:48.08*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
16:56.53CIA-48BRL-CAD: 03n_reed * r47157 10/brlcad/trunk/src/other/step/src/express/ (CMakeLists.txt expparse_new.y): got lemon source compiling; not yet operational
17:04.51pawleeqstarseeker: so the workaround with cmake -DBRLCAD_BUNDLED_LIBS=Bundled failed this way: http://pastebin.com/VmDaFq7L
17:09.13pawleeqstarseeker: pastebin does not accept my, so I uploaded it here: www.pawleeq.com/config.log
18:10.43abhi2011whats is the use of the ap.a_uptr = (genptr_t)a_tab.attrib; while initializing the struct application ap; in nirt
18:10.57abhi2011is it used to specifiy some special attributes
18:11.25abhi2011was wondering if I can NOT set it and just use the rest of the application structure
18:26.33CIA-48BRL-CAD: 03abhi2011 * r47158 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c): Added initial code to shoot rays during manifold generation
18:30.06*** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net)
19:36.54*** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net)
21:11.06CIA-48BRL-CAD: 03abhi2011 * r47159 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simutils.c): Trying to get the overlap points by shooting raysat the AABB overlap region
21:39.03abhi2011that is strange, just compiled bullet to use double precision , and bullet compiled fine
21:39.12abhi2011the demos of bullet are also running
21:39.17abhi2011however mged crashes
21:39.26abhi2011inside the bullet related code
21:39.44abhi2011specifically when allocating memory for a particular bullet object
21:41.08abhi2011http://bin.cakephp.org/view/1090178448
21:41.24abhi2011the crash seems to be in malloc
21:52.03abhi2011hmm tried a clean build but that didnt work either, I ll switch bullet back to single precision, maybe malloc is unable to allocate 64 bits
21:52.19abhi2011though I dont know how the demos work  then
22:09.23abhi2011now it works fine again after switching back to single precision!
22:36.54*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:53.56*** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net)
IRC log for #brlcad on 20111007

IRC log for #brlcad on 20111007

00:43.55CIA-48BRL-CAD: 03abhi2011 * r47160 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simutils.c): Began to actually shoot rays towards simulation geometry, needs some debugging(issues during memory cleanup)
00:45.44CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3179 10/wiki/User:Abhijit: /* Log */
02:14.18CIA-48BRL-CAD: 03starseeker * r47161 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: Hmm. Don't try moving things if source and destination are the same...
02:14.42starseekerbet that's what pawleeq hit
02:48.39brlcadabhi2011: your build is lacking debug information -- you should get a much more informative crash report, but what's there obviously indicates memory management gone bad
02:49.15brlcadswitching to single precision more than likely just changes memory alignment so you just happen to avoid the crash, but the problem is still there -- just not provoking a crash (yet)
02:49.58brlcadif you run valgrind, it will report all of the allocation problems (you should have a perfectly clean report except for one or two structures in librt
02:50.38starseekerwoot - got the hv3 browser up and running again.  this time I'll try and work with it instead of gutting it :-)
02:50.49brlcadthe crash does shed light that the memory problem is not with brl-cad structures, but rather with some bullet or memory with one of your classes
02:50.57brlcadyay
02:51.19brlcadstarseeker: be sure to bring an appetite.. there very well may be too much food
02:51.26brlcadmight have to send people home with some :)
02:51.29starseekerhehe :-)
02:51.56starseekereverything coming together OK?
02:52.26brlcadas good as to be expected, it's a lot being coordinated
02:52.31starseekernods
02:53.01starseekerhmm... actually, if this sucker works on Mac and Windows it could be a good "demo app" for the conference...
02:53.01brlcadnothing fancy, nice and casual, but there are a lot of things coming together and everything was too short notice to get into as much detail as we would have liked
02:53.08brlcadnods
02:53.46starseekerthe new venue worked out?
02:53.58starseekerrecalls concerns it might be too large...
03:47.21brlcadyeah, it'll be just fine
03:51.36brlcadnot as neat as the boathouse, but in a really gorgeous garden area
03:51.57brlcadthough we'll be indoors where it's cooler and bug free ;)
06:04.21*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:04.42*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:33.12*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
10:10.17abhi2011a conference about to happen with lots of food I hear :)
10:22.00*** join/#brlcad cvds (~leila@s537510ac.adsl.wanadoo.nl)
10:22.36*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
10:31.14cvdsHello, I ma just starting with brl-cad and was wondering if one could reuse regions in different combinations where the regions would be in a different position ?
13:18.11*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
14:02.15brlcadcvds: absolutely
14:03.29brlcadbasically you apply a matrix transformation to a parent combination
14:03.44brlcadsee the oed tutorial/overview on the website for lots of examples and explanation
14:05.14brlcadif you have /some/path/to/region and /some/path/another/region where you want 'region' to be in different places for the 'to' and 'another' combinations, you'd run oed
14:06.16brlcad"oed /some/path/to region/down/towards/a/primitive" and "oed /some/path/another region/down/towards/a/primitive" would do the trick
14:22.07*** join/#brlcad ibot (~ibot@rikers.org)
14:22.08*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
14:26.08cvdsbrlcad: thanks! I shall check that tutorial after I finished thise goblet. (ota is one "interesting"  command to specify on the command line btw)
14:59.34cvdsnow to find out why it wont render with rt ..
15:00.25cvdsand now it works ...
17:23.09cvdsIt seems that I can not use the tra command to translate my solid using only the dz component (tra 0 0 0.5) Am I missing something ?
17:50.50``Eriksolids don't have translation matrices associated yet, what about putting your solid in a comb/region/assmbly, doing the tra on that, then doing an xpush to modify the solid directly? (if I grok right, I might not)
18:04.00*** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net)
18:05.37cvds``Erik: I see.. odd tho, since I can use tra if I make all arguments non-zero, would that be a fluke ?
18:09.39``ErikI'm unqualified to say anything, there may be a bug :) I almost exclusively work in the low level C stuff and know nothing of the interface
18:15.31cvdsI see :) .. and darn this tutorial document is vast
18:30.39``Erikknowledgable people respond usually within ~24hr, so *shrug* ask and lurk :)
18:31.44*** join/#brlcad merzo (~merzo@40-119-133-95.pool.ukrtel.net)
18:39.50abhi2011valgrind reports a lot of definitely lost memory for mged code
18:40.04abhi2011I mean the normal execution code, without invoking simulate
18:43.43*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
19:08.16abhi2011hmm after calling rt_free_rti(rtip), there are still some blocks reachable : by 0x70BC003: rt_free_rti (prep.c:159), 512 bytes in 1 blocks are still reachable in loss record 3,106 of 3,598, assuming this can be ignored as its some rt related structures
19:16.25cvdsRiddle me this... according to the tutorial I should specify a command, but then I noticed that the result is different and it seems that I need to use the <v6.0 version of the command
19:17.13cvdshowever a mged -version gives me a 7.18.4 which seems to contradict the fact that I need the pre6.0 version.
19:17.27cvdscommand in question is inside
19:33.26abhi2011hmm thats strange I have got reasonably valgrind-clean code now barring a few functions which are related to librt which are producing reachable/definitely lost blocks, but switching bullet to double precision still causes a crash : http://bin.cakephp.org/view/1315005894
19:35.01abhi2011seems there are some invalid writes by Bullet code
20:17.24starseekercvds: there may be tutorial bugs
20:17.51starseekerthe pdfs on the website are quite old, unfortuantely
20:18.08starseekerif you have specific issues, let us know and we'll try to clarify
20:39.40cvdsstarseeker: at the moment its mainly some parameter ordering that seems to be inconsistent. Only "odd" thing was the tra command not working for input: 0 0 0.5 in solid edit mode (sed).
21:11.54CIA-48BRL-CAD: 03starseeker * r47162 10/brlcad/trunk/src/other/ (30 files in 12 dirs): Try to make the 8.5.9 tcl build logic look a little more like the latest 8.6b2 files.
21:12.43*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
21:14.39cvds_Good night all. This client will stay open so I can check the answers in the morning.
21:29.45CIA-48BRL-CAD: 03n_reed * r47163 10/brlcad/trunk/src/other/step/src/ (4 files in 2 dirs): added new version of express.c with lemon parsing loop; building fedex_plus with lemon as well
22:19.41CIA-48BRL-CAD: 03starseeker * r47164 10/brlcad/trunk/src/other/ (95 files in 7 dirs):
22:19.41CIA-48BRL-CAD: Add the full hv3 browser to src/other - preliminary for switching from
22:19.41CIA-48BRL-CAD: special-purpose man and help viewers to customizations of the more powerful hv3
22:19.41CIA-48BRL-CAD: browser. Prompted by the css additions to the Docbook output, but may also
22:19.41CIA-48BRL-CAD: provide a text searching capability.
22:20.02brlcad"ota" ?
22:22.14starseekerota?
22:22.20brlcadcvds_: huh, tra 0 0 0.5 should have worked -- sounds like maybe a bug got introduced recently
22:22.36brlcad10:26 < cvds> brlcad: thanks! I shall check that tutorial after I finished thise goblet. (ota is one "interesting"  command to specify on the command line btw)
22:22.46starseekerah, found it
22:22.51brlcaddon't know what ota is
22:23.07starseekernods
22:24.58brlcadcvds_: you definitely don't need a pre6.0 version, but things certainly have changed a little since the tutorials were written so (very) minor changes (mostly syntactic) are to be expected -- some bugs in the documentation have already been fixed but we've not yet posted new versions of them onto the web (actively being worked on)
22:25.30brlcadthat said, could try the 'translate' command instead of tra -- slightly different parameters, I believe using absolute positions instead of relative
22:44.43*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:05.50*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
IRC log for #brlcad on 20111008

IRC log for #brlcad on 20111008

00:19.36*** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
01:02.08CIA-48BRL-CAD: 03abhi2011 * r47165 10/brlcad/trunk/src/ (5 files in 2 dirs): Fixed list freeup issues for the overlap and hit list generated while shooting rays, also searched and destroyed some memory leaks
01:52.04*** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
02:30.43*** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
03:57.31brlcadabhi2011: nice set of memory fixes!
03:57.43brlcadis the valgrind close to clean?
03:58.10brlcadcleaning up the rtip is a known leak case (there's no free so librt doesn't know when to release the cpu-specific resources)
05:26.15*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
06:18.45cvds_Good morning
06:19.58cvds_brlcad: I meant eliptical torus (eto)
06:21.15cvds_brlcad: indeed translate works fine.
07:10.21cvds_Is there a way to multipane the attached X screen from mged -c ?
11:22.59CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3180 10/wiki/User:Abhijit: /* Log */
13:10.19brlcadcvds_: yes and no
13:11.39brlcadcvds_: you can't mulitpane a plain attached X display, but you can get a multipane from -c
13:11.49brlcadif you run: set mged_default(multi_pane) 1
13:12.12brlcador turn on multipane on the menu or set it in your config file, whatever
13:12.17brlcadand then run "gui"
13:12.25cvds_tries
13:12.38brlcadyou can close the command window and you'll be left with just a multipaned window
13:12.56brlcadotherwise you could run "attach X" four times :)
13:14.30cvds_Nice that will work, that setting is on a per run basis unless I put it in the config file ?
13:14.39brlcadwhich setting?
13:14.51brlcadset mged_default(multi_pane) ?
13:15.28brlcadrunning attach X multiple times doesn't require a setting (and you could put that in your config file)
13:15.44brlcadsetting the multi_pane default could also be put into your config file
13:15.53cvds_that mged_default yes
13:16.20cvds_and running attach x and trying to draw something made mged crash
13:16.26brlcadon the GUI File menu, there's an item for "Update/Create .mgedrc"
13:16.36brlcado.O
13:17.51cvds_something about X not liking the input. I think yakuake or fancy kde things are interfering sometimes
13:18.30CIA-48BRL-CAD: 03brlcad * r47166 10/brlcad/trunk/BUGS: report of attach X crashing after attempting to draw an object in classic mode
13:18.49brlcadwill look into it
13:19.39*** join/#brlcad merzo (~merzo@218-96-132-95.pool.ukrtel.net)
13:20.24cvds_Ah this is nice, a normal X window that I can control with ae and a multipane next to it
13:22.55cvds_well lets continue the oed tutorial
13:23.13CIA-48BRL-CAD: 03abhi2011 * r47167 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c simutils.c): More memory leak search n' destroy
13:23.49abhi2011brlcad: yes it seems reasonably clean now, though there are some I dunno how to get rid of yet....will discuss them
13:24.32abhi2011man! valgrind really slows the mged to a crawl
13:25.28brlcadnods
13:27.28brlcadthat last round of cleanup seems fishy.. bu_free()'ing specific ranges of some array .. should be none or all (in which case you can use bu_free_array())
13:27.41cvds_brlcad: http://pastebin.com/mpYhaKWe is what it tells me, this was ataching an ogl window after closing one
13:28.49brlcadcvds_: yeah, there's some bug there where it's not keeping track of the window properly
13:29.33cvds_okies
13:30.39abhi2011brlcad: yes, the specific ranges contains bu_strdup() 'ed strings
13:30.53abhi2011so they have to be freed afaik
13:31.18abhi2011they show up as lost blocks in valgrind
13:31.37brlcadunderstood, but that's my point :)
13:31.46brlcadshould be none or all
13:32.08brlcadi.e., don't strdup them if you can or strdup the others so you can categorically free them all
13:32.14abhi2011ok
13:32.17abhi2011yeah
13:32.34brlcadhaving a 5-17 loop is just very error-prone
13:32.40abhi2011yes
13:32.43abhi2011true
13:32.51abhi2011right i ll correct that
13:56.37cvds_hmm the rot command is still baffeling me, also it seems that the output after object inspection is totally different from the tutorial
14:12.42cvds_Is there any documentation on how rot acutally works cause the effect apears to be totally random to me
14:14.44cvds_hmm does it depend ae, but that would mean that I am not actually editing the combination but just rotating the view
14:19.09cvds_seems that using orot instead of rot actually does more or less what I expect
15:55.46CIA-48BRL-CAD: 03erikgreenwald * r47168 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: quell uninitialized variable warning
15:59.48CIA-48BRL-CAD: 03erikgreenwald * r47169 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: quell uninitialized variable warning
17:17.13CIA-48BRL-CAD: 03brlcad * r47170 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: can use V2INIT_ZERO for initialization
18:47.47cvds_what is the easiest way to define a single parameter of a shape, if I want to change the height of a cylinder I now kill the shape and then add it again
18:49.46CIA-48BRL-CAD: 03brlcad * r47171 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: fix typo and turn them into vect2d_t
19:56.24cvds_well there is ted of course
21:32.12*** join/#brlcad merzo (~merzo@134-5-132-95.pool.ukrtel.net)
IRC log for #brlcad on 20111009

IRC log for #brlcad on 20111009

05:46.50*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:36.22cvds_having a "pretend" switch for inserting a solid would be nice, you could fiddle with the params without actually creating the object till you are done
08:37.31cvds_or is there some edit mode I am not aware of that does the same thing ?
10:01.07cvds_subtracting a disc (rcc) from the top a cube (rpp) such that I should have a small concave corner does not seem to work
10:03.04cvds_I expected a quarter pie to be removed from the top of the cube, instead only 2 small bars are removed
15:51.32starseekercvds_: can you post your .g file somewhere?
16:29.33CIA-48BRL-CAD: 03abhi2011 * r47172 10/brlcad/trunk/src/libged/simulate/simutils.c: Eliminating some fishy memory leak fixes
20:56.45cvds_starseeker: euhm let me check if I still have it. I switched to using a pipe to cut away that layer and that seems to work
21:06.27cvds_starseeker: I am afraid I can no longer reproduce the effect
21:07.54cvds_Most likely I did something wrong myself
21:47.11*** join/#brlcad merzo (~merzo@64-4-133-95.pool.ukrtel.net)
IRC log for #brlcad on 20111010

IRC log for #brlcad on 20111010

00:23.32CIA-48BRL-CAD: 03abhi2011 * r47173 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c simutils.c simutils.h): Added ray shooting in the X direction in the manifold generator to query the overlap area(of the AABBs) of 2 regions
01:32.17*** join/#brlcad kanzure (~kanzure@131.252.130.248)
07:02.57*** join/#brlcad merzo (~merzo@193.254.217.44)
07:23.48*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:50.47cvds_Is there a place that explains the datastructure in more detail. I am mainly interested in how references work and are created. It seems that running cp makes a shallow copy of the combination for instance. Meaning that I can change the refered shape but is the same true for adding a shape ? This kind of behavior is what I would like to read up on, I think it will help me reusing more shapes / combinations with less effort to change things in the mode
11:44.59*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
14:54.53*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-187-190.wlan.tudelft.nl)
16:53.13*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:53.04*** join/#brlcad merzo (~merzo@230-115-133-95.pool.ukrtel.net)
21:09.29*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
IRC log for #brlcad on 20111011

IRC log for #brlcad on 20111011

00:35.35*** join/#brlcad piksi (piksi@pi-xi.net)
01:59.28brlcadcvds_: have you read the mged tutorial?
01:59.53brlcadcvds_: cp will perform a shallow copy and clone will perform a deep copy
02:03.35brlcadas for adding a shape, it is only added to the combination you specify -- so if you cp FROM TO or clone FROM TO and then add to the TO object, it will not affect the FROM object
02:06.53brlcadif you *do* want to affect "all instances", then you can simply keep a base combination that you reference in your various usages .. e.g., make a REAL1 comb/region that references BASE, a REAL2 comb/region that also references BASE .. then if you modify BASE it'll affect both REAL1 and REAL2 or you can modify REAL1 or REAL2 directly to just modify that instance
02:07.13brlcadvol3 goes into more detail as does the oed tutorial (both on the website under the Docs section)
05:14.08*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
06:13.51*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:43.31*** join/#brlcad merzo (~merzo@193.254.217.44)
07:45.47*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
14:24.39*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
15:01.30*** join/#brlcad hackrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
15:44.44*** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net)
16:01.30cvds_brlcad: thanks, I shall dig up vol3. but running a cp on an combibation X giving me an X' will mean that whatever I do to X will end up in X' ?
16:03.43cvds_ALso, the oed command one is a very useful read
16:05.58cvds_just which one is the third, I did introduction to mged, the oed command and principles of effective modelling.
17:13.27brlcadcvds_: if you cp X to X1 then whatever you do to X will NOT end up in X
17:13.29brlcad'
17:13.54brlcadprinciples of effective modeling is Vol3
17:14.10brlcadtalks about how to structure geometry
17:14.23brlcadas does volume 2 (into mged) but it's spread across multiple tutorials
17:17.36cvds_will reread the passeges in effective modelling then
17:18.24cvds_and I did some experimenting already, that oed command + shallow copies is realy nice
17:53.40*** join/#brlcad DarkCalf (DC@173.231.40.98)
17:54.41cvds_is it normal when rendering a combination to get overlap warnings when raytracing (I am getting these on a union of shapes I put together
18:14.32brlcadcvds_: it's normal when you have modeling "errors", sure ;)
18:14.55brlcadif you've not defined any regions, then the raytracer assumes that primitives are regions
18:15.23brlcada region is brl-cad terminology for a part, when something becomes solid and occupies physical space
18:16.12brlcadprobably as simple as marking your combination as a region or creating a region that unions that one combination you were using
18:16.21brlcad(see the 'r' command)
18:20.03cvds_brlcad: That is what I expected, but wrapping the combination in a region and raytracing it still gave me the erros. I revised the combination to just substract overlapping solids
18:21.04cvds_and now the raytracer is happy again
18:55.12CIA-48BRL-CAD: 03erikgreenwald * r47174 10/brlcad/trunk/src/libgcv/bottess.c: fix broken indentation
18:58.41brlcadcvds_: I suspect when you wrapped it in a region, you were still displaying the non-region combination, so it would have still resulted in primitives getting turned into regions resulting in overlaps
19:08.09cvds_that would make sense -_- I thought I blasted it tho. Let met try this
19:12.12cvds_brlcad: that seems to be it indeed
19:24.36CIA-48BRL-CAD: 03starseeker * r47175 10/brlcad/trunk/src/other/ (5 files in 5 dirs): TCL_CHECK_LIBRARY -> CHECK_LIBRARY_EXISTS
19:29.09CIA-48BRL-CAD: 03starseeker * r47176 10/brlcad/trunk/src/other/ (4 files in 4 dirs): Whoops, not a simple one to one mapping of the macros.
19:30.08CIA-48BRL-CAD: 03starseeker * r47177 10/brlcad/trunk/src/other/sqlite3/tcl/CMake/tcl.cmake: missed one...
19:30.50cvds_Is there a more powerful insert command that does not add an object to the end of the combination? Since adding to the end of the tree does not always result in the result I want because of the boolean operator precedence
19:34.47brlcadcvds_: hm!  that's actually not come up before (of recent memory)
19:36.28brlcadI've thought about that myself -- a command that allows position-based insertion/removal -- but afaik, doesn't exist
19:36.50brlcadit's usually easy enough to modify the comb with the gui or text edit (red command) or get/put commands
19:37.23brlcadnote that the latter is very powerful, but also very unforgiving if you mess up (even simple typos can result in an unusable comb)
19:37.34brlcadput/get is about as low-level as it gets
19:42.42cvds_brlcad: red seems to work just fine :). I wonder if I should more lower level combinations to prevent very large trees from forming ...
19:43.09cvds_if I should create*
19:50.21CIA-48BRL-CAD: 03starseeker * r47178 10/brlcad/trunk/src/other/incrTcl/ (itcl/CMakeLists.txt itk/CMakeLists.txt): Make a stab at updating the incrTcl CMakeLists.txt files
19:51.27cvds_also considering to wrap a combination that I intend to duplicate around inside a wrapper object before copying. That way I hope that I can add solids the base object and see it propagate over the copties
19:57.28cvds_heh the c command looks interesting as well
19:59.17cvds_or can one use parenthesis in comb as well /me tests
20:08.08cvds_parenthesis are not allowed in comb but are in c, results seems to be the same tree. Using an extra wrapper before making shallow copies allows me to add solids to the copies by adding them to the base combination
20:15.17CIA-48BRL-CAD: 03starseeker * r47179 10/brlcad/trunk/src/other/tk/CMakeLists.txt: Oops - handle X11 dirs better for tk
20:30.23CIA-48BRL-CAD: 03brlcad * r47180 10/brlcad/trunk/TODO:
20:30.23CIA-48BRL-CAD: some reid support requests from the modeling team. add an option to increment
20:30.23CIA-48BRL-CAD: with values other than 1 and another for reporting/detecting if the region
20:30.23CIA-48BRL-CAD: numbers being used conflict with existing region numbers elsewhere in the
20:30.23CIA-48BRL-CAD: database.
20:33.06CIA-48BRL-CAD: 03brlcad * r47181 10/brlcad/trunk/HACKING: there is a facebook and twitter feed, mention them as part of the release process (ask me for the pw if you need to post)
21:32.50CIA-48BRL-CAD: 03bob1961 * r47182 10/brlcad/trunk/src/libbu/dirname.c: In bu_dirname, need to check to see if slash is NULL (i.e. we could be on Windows and actually using a forward slash instead of BU_DIR_SEPARATOR which is a backslash on this platform). Don't you just love Windows?
21:40.20*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
21:59.55CIA-48BRL-CAD: 03n_reed * r47183 10/brlcad/trunk/doc/bison_to_lemon.txt: additions and corrections
22:26.20CIA-48BRL-CAD: 03starseeker * r47184 10/brlcad/trunk/src/other/sqlite3/ (CMakeLists.txt tcl/CMakeLists.txt): Couple tweaks to the sqlite3 build - we have now successfully run hv3 on Windows.
22:30.48brlcad``Erik: indentation is broken because the macros are missing semi's
22:31.48brlcadthey're expected after all the vmath macros (even if they technically expand to code that might not need it, that's not the intent)
22:47.20CIA-48BRL-CAD: 03brlcad * r47185 10/brlcad/trunk/src/mged/ (CMakeLists.txt Makefile.am fbserv_win32.c): remove the unused-and-not-being-compiled fbserv_win32.c file, especially now that cmake is building fbserv.c across all platforms. file was referring to a non-existing pkgtypes.h libfb header too.
22:49.41CIA-48BRL-CAD: 03brlcad * r47186 10/brlcad/trunk/src/conv/iges/ (CMakeLists.txt Makefile.am spl.c): remove the similarly unused spl.c file that was referring to a non-existent b_spline.h header.
22:57.14CIA-48BRL-CAD: 03brlcad * r47187 10/brlcad/trunk/src/other/step/src/clutils/ (dirobj.cc stat.h): #include ridiculousness. full path to sys/stat.h (and dirent) is not portable.
23:01.34CIA-48BRL-CAD: 03brlcad * r47188 10/brlcad/trunk/src/librt/ (CMakeLists.txt Makefile.am timer52brl.c):
23:01.35CIA-48BRL-CAD: remove timer52brl.c for referring to header files that haven't existed in about
23:01.35CIA-48BRL-CAD: a decade. there doesn't seem to be much utility in even keeping this bsd-style
23:01.35CIA-48BRL-CAD: implementation around for reference since it just emulates bsd calls, and
23:01.35CIA-48BRL-CAD: nowhere close to a compiling state regardless.
23:07.42CIA-48BRL-CAD: 03brlcad * r47189 10/brlcad/trunk/src/adrt/ (4 files in 2 dirs): tie.h no longer lives in a libtie subdir
23:11.03CIA-48BRL-CAD: 03starseeker * r47190 10/brlcad/trunk/src/other/sqlite3/CMakeLists.txt: More sqlite3 CMake tweaks
23:20.48CIA-48BRL-CAD: 03brlcad * r47191 10/brlcad/trunk/src/libbu/dirname.c:
23:20.48CIA-48BRL-CAD: bob's change in r47182 made it obvious that there is more logic failure and
23:20.48CIA-48BRL-CAD: potential for crash.. need to make sure both slash and slash2 are non-null
23:20.48CIA-48BRL-CAD: before setting them (and we want to always set them if they're not at the
23:20.48CIA-48BRL-CAD: beginning of the path)
23:24.45CIA-48BRL-CAD: 03brlcad * r47192 10/brlcad/trunk/src/libbu/dirname.c: rename slash/slash2 to found_dslash/found_fslash respectively so logic is a lil easier to read
23:25.56*** part/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net)
23:49.59*** join/#brlcad mattS_ (cb3af1be@gateway/web/freenode/ip.203.58.241.190)
IRC log for #brlcad on 20111012

IRC log for #brlcad on 20111012

00:09.43*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
01:15.12CIA-48BRL-CAD: 03starseeker * r47193 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: even if we're in toplevel src, we need to rename lemon's output if we're doing cpp instead of c files - give this a try.
01:44.37CIA-48BRL-CAD: 03starseeker * r47194 10/brlcad/trunk/src/libgcv/ (7 files in 2 dirs): obj_grammar.h is being overwritten by lemon before its output gets renamed to obj_grammer.hpp when srcdir=bindir. Rename the file to obj_grammar_decls.h to avoid the problem.
01:46.30CIA-48BRL-CAD: 03starseeker * r47195 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: Fix lemon comment
01:53.07starseekerthat should fix the in-src-dir cmake build
06:50.14*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
06:57.28*** join/#brlcad merzo (~merzo@193.254.217.44)
07:06.31starseekerO.o http://compcert.inria.fr/compcert-C.html  too bad it's not properly open source
07:34.48cvds_I must say I am amazed that a 1979? software tool is still being actively worked on
07:39.40*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
09:55.24starseekercvds_: BRL-CAD?  Oh, there are others - maxima and reduce computer algebra systems come readily to mind
09:57.15starseekerspice:  http://embedded.eecs.berkeley.edu/pubs/downloads/spice/index.htm
10:06.48cvds_starseeker: fair point, adn actually I hope to get into spice a little later when I need to start on the electronic design
11:51.32*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:01.12cvds_there has to be a better way to change the height of a rcc than ted
12:31.56*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:54.57*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:55.55starseekercvds_: sed in mged is how I usually do it
12:56.14starseekerdraw the specific primitive, sed it, and then use the gui controls
12:56.42starseekeror use the edit menu to select the height parameter and then use the p command on the mged command line
12:58.01starseekercvds_: actually, most commercial cad systems have at least ancestor codes that date way back - a task so complex just takes a LOT of time to get done
13:04.59cvds_starseeker: I am not using the gui
13:05.21cvds_fonts are way to small to read from the couche :)
13:05.42cvds_right... debugging in 3d is fun
13:32.41brlcadcvds_: the fonts are fully customizable
13:33.06brlcadyou may also appreciate the "press" command
13:34.21brlcadyou can "press" any edit option that would be on the edit menu, so like to edit an rcc value, it's something like: sed myrcc ; press "Edit H" ; p 10.4 ; accept
13:35.01brlcadjust an example, it might not actually be "Edit H" .. don't recall the options from memory
13:40.28CIA-48BRL-CAD: 03bob1961 * r47196 10/brlcad/trunk/src/libdm/ (dm-ogl.c dm-wgl.c): Restore calls to glOrtho in wgl_reshape() and ogl_reshape().
14:19.11cvds_brlcad: I tried to customize the fonts, but they did not seem to scale a lot. Tho that could be my window manager and dpi settings. The press command seems realy interesting tho
14:19.41cvds_also did find the 0.5 mm offset that was wrong
14:55.29starseekeryawns
15:29.28brlcadcvds_: if you select "Update/Create .mgedrc" on the file menu, it'll put a .mgedrc configuration file in your home directory -- in there, you can change the font values to whatever your system allows, potentially much greater than the gui allows
15:47.33*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
16:28.33cvds_Interesting, I must try that sometime. Tho I am quite happy using yakuake and having the model full screen at the moemnt
16:29.07brlcadnods
16:31.37cvds_or rather.. all 5 of them
16:34.07*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
17:04.30*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
17:14.04CIA-48BRL-CAD: 03n_reed * r47197 10/brlcad/trunk/src/other/step/src/express/CMakeLists.txt: build new scanner output into new libexpress
17:23.11cvds_is there an example sheet of primitives about.. like I am trying to figure out the vector A and B for a rec
17:25.41cvds_ah the tutorial2 had one for the walkie talky
17:27.32CIA-48BRL-CAD: 03n_reed * r47198 10/brlcad/trunk/src/other/step/src/express/ (expparse_new.y token_type.h): putting token type definition in its own header
18:02.11*** join/#brlcad akissimouyt (~arcosauro@ppp-115-45.32-151.iol.it)
18:02.21akissimouytHello!
18:02.27akissimouyt!list
18:02.37*** part/#brlcad akissimouyt (~arcosauro@ppp-115-45.32-151.iol.it)
18:03.28*** join/#brlcad akissimouyt (~arcosauro@ppp-115-45.32-151.iol.it)
18:04.18*** part/#brlcad akissimouyt (~arcosauro@ppp-115-45.32-151.iol.it)
19:22.16CIA-48BRL-CAD: 03brlcad * r47199 10/brlcad/trunk/src/tclscripts/archer/images/Makefile.am: option_tree is no more
19:43.14CIA-48BRL-CAD: 03n_reed * r47200 10/brlcad/trunk/src/other/step/ (include/express/lexact.h src/express/lexact.c): replaced conditional variable declarations with explcit ones to simplify building
19:50.36CIA-48BRL-CAD: 03n_reed * r47201 10/brlcad/trunk/src/other/ (10 files in 3 dirs): making lemon parser sources the only parser sources
19:52.57CIA-48BRL-CAD: 03bob1961 * r47202 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: update bot_flip_check to set the flipped bot's orientation to rh if previously oriented
19:53.31CIA-48BRL-CAD: 03n_reed * r47203 10/brlcad/trunk/src/other/step/src/express/express.c: remove debug output
20:16.39CIA-48BRL-CAD: 03starseeker * r47204 10/brlcad/trunk/src/other/sqlite3/CMakeLists.txt: Er, oops - how about -D
20:33.52brlcadcvds_: there's a list of most primitives at the end of vol2
20:42.04CIA-48BRL-CAD: 03starseeker * r47205 10/brlcad/trunk/src/other/togl/include/GL/glew.h: glew.h patch from Tim Myers for Mac
20:44.25*** join/#brlcad mattS_ (cb3af1be@gateway/web/freenode/ip.203.58.241.190)
20:46.10*** join/#brlcad merzo (~merzo@115-2-132-95.pool.ukrtel.net)
20:48.27cvds_brlcad: perfect
22:00.25abhi2011anyone else getting errors related to some undefined sqlite3 symbols ?
22:01.16starseekerabhi2011: have you updated to the very latest trunk?
22:01.23CIA-48BRL-CAD: 03brlcad * r47206 10/brlcad/trunk/doc/docbook/create-xml-catalogs.pl: create the directory if it doesn't yet exist (which it never does for an out-of-dir build)
22:02.20CIA-48BRL-CAD: 03brlcad * r47207 10/brlcad/trunk/ (configure.ac doc/docbook/DBPATH.pm.in): no need to define and substitute new variables here, just use the default abs_top_srcdir which lets us keep the path logic where it belongs too (in DBPATH.pm).
22:03.33abhi2011ah ok, i ll update again
22:03.36CIA-48BRL-CAD: 03brlcad * r47208 10/brlcad/trunk/doc/docbook/Makefile.am: this seems to get things working for an out-of-dir build. needed to tell perl where the perl module resided and not assume the generated catalog generator file is in the source dir.
22:07.06brlcadarf, very unhappy parallel cmake build
22:07.42brlcadmake -j20 .. failed four times before making it through to the end
22:10.01CIA-48BRL-CAD: 03brlcad * r47209 10/brlcad/trunk/TODO: only two show-stopper items holding up the release. need to make sure rtcheck works and testing multipe blank lines in mged.
22:51.32CIA-48BRL-CAD: 03n_reed * r47210 10/brlcad/trunk/configure.ac: disable STEP build
22:51.47brlcadstarseeker: done a distcheck in a while?  looking like hv3 and sqlite3 aren't getting added
22:52.02brlcadplus a bunch of the doc files for some reasons
23:05.56CIA-48BRL-CAD: 03n_reed * r47211 10/brlcad/trunk/src/other/step/src/express/Makefile.am: remove reference to non-existant file
23:18.19CIA-48BRL-CAD: 03starseeker * r47212 10/brlcad/trunk/doc/ecosystem.dot: Graphviz generated layout detailing relationships between 3rd party libraries and BRL-CAD components. High level overview.
23:20.17starseekerbrlcad: not recently...
23:38.58*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:45.56abhi2011starseeker: I just updated to the latest build a few minutes ago, the cmake build shows some errors : http://bin.cakephp.org/view/417920177
23:47.06starseekerabhi2011: did you clear out your old CMakeCache.txt file?
23:47.35abhi2011oh , I didnt, a make clean should do that I guess
23:47.54starseekerit's like the config.cache file from autotools
23:48.11starseekerit stays around until you specifically nuke it (either from the GUI or manually)
23:49.08abhi2011ok
IRC log for #brlcad on 20111013

IRC log for #brlcad on 20111013

00:49.19CIA-48BRL-CAD: 03starseeker * r47213 10/brlcad/trunk/src/tclscripts/ (CMakeLists.txt Makefile.am hv3_man_browser_test.tcl): first baby steps, but this demonstrates the fundamental possibility of customizing the hv3 browser to serve as a man page help browser. Just a checkpoint.
01:01.35CIA-48BRL-CAD: 03starseeker * r47214 10/brlcad/trunk/ (5 files in 5 dirs): Add some files to the CMake logic. For the moment, just ignore sqlite3 and hv3 - functionality using those repositories isn't quite ready yet.
01:12.43CIA-48BRL-CAD: 03abhi2011 * r47215 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Wrote some initial code to generate contact pairs out of overlaps detected while shooting rays down the x axis
01:15.09CIA-48BRL-CAD: 03starseeker * r47216 10/brlcad/trunk/doc/docbook/books/ (CMakeLists.txt it/ ru/): Remove empty dirs until they have contents
01:34.37starseekerok, fwiw, cmake distcheck passed
02:33.10*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:41.53brlcadstarseeker: great, thx
03:48.31CIA-48BRL-CAD: 03starseeker * r47217 10/brlcad/trunk/src/archer/archer: Er, don't want to complain if we've just launched via symlink (e.g. the /usr/brlcad/bin -> /usr/brlcad/rel-x.x.x/bin situation) so resolve the argv0 file up front.
04:15.50CIA-48BRL-CAD: 03starseeker * r47218 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: use bu_brlcad_data. Still just a trivial example thus far.
04:41.34``Erikstarseeker: rhel complains about dlopen/dlsym/etc in src/other/sqlite3 (not getting -ldl), fbsd complains about header paths on incrTk (have /usr/local/include/X11/Xlib.h and /usr/X11R6/include/X11/Xlib.h, header not being found at preprocessor)
04:42.20starseeker``Erik: in the rhel case, did you try clearing out the CMakeCache.txt file and rebuilding?
04:44.11CIA-48BRL-CAD: 03starseeker * r47219 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Still need a scrollbar, but coming along nicely - can now pull up manual pages.
04:44.41starseeker``Erik: I'll give freebsd a try tomorrow
06:24.03*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
06:41.03cvds_I am starting on the first "irregular" shape that contains many curves. Is there a "best" way to do this or does it come down to "be creative"?
06:44.45cvds_it sorta looks like a banana with a flat bottom -_-
08:00.40*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
08:46.41*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:03.54CIA-48BRL-CAD: 03abhi2011 * r47220 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c simutils.c simutils.h): Corrected some indentations in the code
11:43.50CIA-48BRL-CAD: 03abhi2011 * r47221 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Rayshot results structure corrected to be initialized for every manifold now, instead of for every ray
11:44.06*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
11:50.39CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3181 10/wiki/User:Abhijit: /* Log */
12:03.24*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:35.57brlcadcvds_: there are some best practices but coming up with a good CSG recipe for a given shape can take some thought
12:37.45brlcadit's generally best to capture most of the shape with just one or a couple primitives unioned together that exceeds the volume, then perform subtractions to scuplt a perfect match
12:38.38brlcadanother method involves following contours and walking a pattern around prescribed axes, then intersecting them together
12:40.19brlcadfor a banana, I'd probably approach it as a union of base shapes matching the exterior curves, then subtract the interior curves
12:57.00cvds_brlcad: that is what I was planning, I think I can do it with 4 recs
13:22.59CIA-48BRL-CAD: 03starseeker * r47222 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Add the search option for pages back in.
13:25.42CIA-48BRL-CAD: 03starseeker * r47223 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: key bindings too.
13:30.42*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:37.00brlcado.O ... Re-run cmake file: CMakeFiles/cmake.check_cache older than: ../src/archer/archer
13:37.12brlcadcmake rebuild dependent on a tcl script getting updated??
13:37.49brlcadcmake -j10 distcheck failure .. retrying with verbose (died in tcl)
13:38.32starseekerbrlcad: it probably depends on how I have src/archer/archer called out
13:40.20brlcadundoubtedly, but on the surface doesn't seem right :)
13:40.25brlcadit's a script :)
13:41.23brlcadthat's along with docs are some of the few/only things in the package that can be updated independent of cmake detection logic
13:41.37brlcadhits road
13:46.37starseekerIIRC, that's one of the ones I'm copying into bin (so ./bin/archer works from the build directory)
13:46.56starseekershould probably be doing a symlink...
14:02.55CIA-48BRL-CAD: 03starseeker * r47224 10/brlcad/trunk/src/archer/CMakeLists.txt: Try a symlink when possible for archer
14:11.20CIA-48BRL-CAD: 03starseeker * r47225 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: getting close. Have scrollbar now, get the search bindings working even if the focus is in the tree.
14:51.06brlcadstarseeker: it looks like the distcheck failure is in the docs processing
14:51.49brlcadcopying into bin sounds fine .. it's where the dep is coming from
14:52.32brlcadthe distcheck error seems to be:
14:52.34brlcadruntime error
14:52.34brlcadxsltApplyStylesheet: saving to /n/uf1/e/vld/other/morrison/brlcad/.cmake/_brlcad-7.20.3-build/share/brlcad/7.20.3/html/mann/en/all_sf.html may not be possible
14:53.05brlcadmake[6]: *** [share/brlcad/7.20.3/html/mann/en/all_sf.html] Error 9
14:53.05brlcadmake[5]: *** [doc/docbook/system/mann/en/CMakeFiles/all_sf_mann_html.dir/all] Error 2
14:53.52brlcadunrelated, but tcl also seems to have an rpath oddity:
14:54.44brlcadall of the linker lines have -Wl,-rpath,:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
14:57.19CIA-48BRL-CAD: 03starseeker * r47226 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Use paned view. This may do it, except for the itcl/itk integration issues in Archer...
14:58.15starseekerbrlcad: that's an xsltproc problem.  I've seen that before
14:59.11starseekerhttp://mail.gnome.org/archives/xslt/2009-December/msg00011.html
15:00.40brlcadah, so then we can work around it by making sure the output directory is already created
15:01.22brlcaddoes cmake have an equivalent to mkdir -p?
15:01.30starseekerI believe so
15:01.37starseekerone sec...
15:06.15CIA-48BRL-CAD: 03starseeker * r47227 10/brlcad/trunk/doc/docbook/CMakeLists.txt: Try to make soure our target directory is present before running xsltproc, to avoid multiple instances arguing - see http://mail.gnome.org/archives/xslt/2009-December/msg00011.html
15:06.21starseekersee if that helps
15:06.41brlcadk
15:26.05CIA-48BRL-CAD: 03starseeker * r47228 10/brlcad/trunk/src/other/ (CMakeLists.txt Makefile.am hv3.dist sqlite3/): Shaping up somewhat - looks like we will want hv3 but don't (yet) need sqlite, at least for the functionality we're currently interested in.
15:29.22starseekerhits road
16:55.47brlcadstarseeker: that seems to have helped, now it's choking on some scl generated output
16:55.51brlcadcd /n/uf1/e/vld/other/morrison/brlcad/.cmake/brlcad-7.20.3/src/other/step/src/express && /bin/mv expparse.out /n/uf1/e/vld/other/morrison/brlcad/.cmake/_brlcad-7.20.3-build/src/other/step/src/exp
16:55.55brlcadress/expparse.out
16:55.57brlcadDependee "/n/uf1/e/vld/other/morrison/brlcad/.cmake/_brlcad-7.20.3-build/src/other/step/src/express/expparse.c" is newer than depender "src/other/step/src/express/CMakeFiles/express.dir/expparse.
16:56.01brlcadc.o".
16:56.04brlcad/bin/mv: cannot stat `expparse.out': No such file or directory
16:56.11brlcad(ignore Dependee line.. lots of those)
16:56.50brlcadpresumably it's trying to move a file before it was generated, I'd guess implying that some ordering dependency isn't being described
16:57.55brlcadfix could be as simple as copying the file instead of trying to move it
17:09.08*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
18:33.14CIA-48BRL-CAD: 03starseeker * r47229 10/brlcad/trunk/misc/CMake/FindLEMON.cmake:
18:33.14CIA-48BRL-CAD: Sean had a good idea - rather than fight to get all of lemon's outputs out of
18:33.15CIA-48BRL-CAD: the src dir, just copy the input file into the build dir and run lemon there.
18:33.15CIA-48BRL-CAD: Cleaner from a 'don't write in the src tree' standpoint AND simplifies the
18:33.15CIA-48BRL-CAD: logic. Nice.
18:54.42CIA-48BRL-CAD: 03starseeker * r47230 10/brlcad/trunk/src/other/ (20 files in 5 dirs): Hmm, spoke too soon (or more precisely, did the test incorrectly.) hv3 still needs sqlite3. Put it back, with proper dist file and fixing dl test.
19:09.57CIA-48BRL-CAD: 03starseeker * r47231 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Accept a value from the command line, althought this is probably not the final mechanism we'll want to use.
19:26.28CIA-48BRL-CAD: 03erikgreenwald * r47232 10/brlcad/trunk/src/libgcv/bottess.c: Pass opposite face normal to splitter (for in place classification). De-macro, simplifiy, clean up. Add line checking via bn.
19:48.25CIA-48BRL-CAD: 03starseeker * r47233 10/brlcad/trunk/src/other/hv3/ (hv3_form.tcl hv3_http.tcl): Couple of catches to prevent error messages.
19:54.22CIA-48BRL-CAD: 03starseeker * r47234 10/brlcad/trunk/src/other/tkhtml/src/htmlimage.c: Don't toss out this warning every time.
19:58.57CIA-48BRL-CAD: 03starseeker * r47235 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Add tkpng to the mix, even though we aren't likely to need it for man pages.
20:26.47CIA-48BRL-CAD: 03starseeker * r47236 10/brlcad/trunk/src/other/ (CMakeLists.txt incrTcl/itk/CMakeLists.txt): In the case of Itk, do as Tk does for X11 includes
20:31.17starseekerhah, cool:  http://www.cnn.com/2011/10/13/tech/innovation/pavegen-kinetic-pavements/index.html
21:13.46CIA-48BRL-CAD: 03starseeker * r47237 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Fix hiding and re-enabling the extra parts of the gui.
21:30.24CIA-48BRL-CAD: 03starseeker * r47238 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Start working towards being able to do the hv3 browser in Itcl/Itk, or rather, discovering whether that is technically workable.
21:44.50CIA-48BRL-CAD: 03n_reed * r47239 10/brlcad/trunk/src/other/step/include/exppp/exppp.h: added missing header guard
22:30.52brlcadstarseeker: looks like distcheck passes!
22:31.21brlcadcmake, that is .. now to validate auto
22:40.29CIA-48BRL-CAD: 03brlcad * r47240 10/brlcad/trunk/regress/repository.sh: looks like failures were accidentally committed as non-fatal so failures were being reported but not halting. make them halt so the problems get noticed/fixed.
22:58.50CIA-48BRL-CAD: 03brlcad * r47241 10/brlcad/trunk/regress/repository.sh: actually, the problem was that we don't increment the FOUND count for this particular subtest. make the CPPFLAGS test not-so-strict, though, recognizing and ignoring lines that have a comment (e.g., our libpng)
23:28.31CIA-48BRL-CAD: 03brlcad * r47242 10/brlcad/trunk/sh/ (CMakeLists.txt Makefile.am cmp.sh):
23:28.31CIA-48BRL-CAD: add the initial comparison script that was used to evaluate, validate, and
23:28.31CIA-48BRL-CAD: compare geometry representations for implicit, nurbs, and polygonal mesh
23:28.31CIA-48BRL-CAD: geometry. the script makes a variety of assumptions (various tools must be in
23:28.31CIA-48BRL-CAD: PATH), but is relatively useful for comparing how similar/different two geometry
23:28.31CIA-48BRL-CAD: objects are.
23:54.39CIA-48BRL-CAD: 03n_reed * r47243 10/brlcad/trunk/src/other/step/ (45 files in 3 dirs): Removed toggled declarations/definitions in headers. Headers include only declarations, and explicit definitions found in appropriate sources.
IRC log for #brlcad on 20111014

IRC log for #brlcad on 20111014

00:30.25CIA-48BRL-CAD: 03n_reed * r47244 10/brlcad/trunk/src/other/step/include/ (CMakeLists.txt express/Makefile.am): remove references to non-existent headers
00:31.14*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
06:47.20*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
09:41.18*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
11:54.34*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:20.13brlcadyawns
13:56.22CIA-48BRL-CAD: 03brlcad * r47245 10/brlcad/trunk/src/other/Makefile.am: we cannot traverse into 'step' even as a DIST_SUBDIR because the build logic in there will attempt (and fail) to generate files to be included in the dist. just include the whole directory as an EXTRA_DIST item.
14:06.02CIA-48BRL-CAD: 03bob1961 * r47246 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Using separate variables for keeping track of the zclip values for the front/near and back/far zclip values.
14:11.25CIA-48BRL-CAD: 03brlcad * r47247 10/brlcad/trunk/src/external/Makefile.am: there is no CMakeLists.txt file defined for src/external, cannot yet build proe or ug plugins with new build system.
14:13.36CIA-48BRL-CAD: 03brlcad * r47248 10/brlcad/branches/STABLE/ (4 files in 4 dirs): mergeinfo
14:44.39CIA-48BRL-CAD: 03brlcad * r47249 10/brlcad/trunk/misc/Makefile.am: CMake/svncheck.cmake.in no longer exists
14:48.57CIA-48BRL-CAD: 03erikgreenwald * r47250 10/brlcad/trunk/src/libgcv/bottess.c: Fixes to face split logic. Remove classifier, as face classification will be done at split time instead of trying to guess later (NMG) or caching (unnbolean).
14:50.47brlcadstarseeker: what does it do with the symlink when you later install?
15:18.54*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:20.53CIA-48BRL-CAD: 03brlcad * r47251 10/brlcad/trunk/misc/Makefile.am: slew of other cmake files missing from the dist, sort list
15:23.43CIA-48BRL-CAD: 03brlcad * r47252 10/brlcad/trunk/doc/Makefile.am: got to keep both in sync, just a couple more releases. add ecosystem.dot
15:48.55CIA-48BRL-CAD: 03brlcad * r47253 10/brlcad/trunk/TODO: add a section specifically for cmake items still pending
15:51.20CIA-48BRL-CAD: 03brlcad * r47254 10/brlcad/trunk/doc/docbook/books/en/Makefile.am: add missing image files to dist
16:15.33CIA-48BRL-CAD: 03brlcad * r47255 10/brlcad/trunk/TODO: specify some of the material traits we may be interested in, scalar values
16:50.21CIA-48BRL-CAD: 03bob1961 * r47256 10/brlcad/trunk/src/libdm/dm_obj.c:
16:50.21CIA-48BRL-CAD: The relatively new call to fb_close_existing() in dmo_closeFb() frees the
16:50.21CIA-48BRL-CAD: framebuffer's memory. The older code in dmo_closeFb() that frees this same
16:50.21CIA-48BRL-CAD: memory has been removed. This fixes a double free problem encountered when using
16:50.21CIA-48BRL-CAD: the old CAD widgets.
16:53.55CIA-48BRL-CAD: 03n_reed * r47257 10/brlcad/trunk/src/other/step/src/express/express.c: yylval is YYSTYPE, not int
18:14.45CIA-48BRL-CAD: 03starseeker * r47258 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Probably not the way to approach hv3 - remove extra stuff.
18:41.25*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
18:56.43CIA-48BRL-CAD: 03n_reed * r47259 10/brlcad/trunk/src/other/step/src/express/ (expparse.y express.c): Doing state init via func call since lemon isn't running start-symbol action as soon as bison was.
19:33.12CIA-48BRL-CAD: 03erikgreenwald * r47260 10/brlcad/trunk/src/libgcv/bottess.c: begin "point in face" handling
21:54.41CIA-48BRL-CAD: 03n_reed * r47261 10/brlcad/trunk/src/other/step/src/express/expparse.y: typo in action was causing segfault
22:18.04brlcadstarseeker: now that you have the docs building in cmake, is perl still being used?
23:08.54*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:17.30*** join/#brlcad DarkCalf (DC@173.231.40.98)
23:24.17*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
23:27.36starseekerbrlcad: not for CMake, but it is for autotools...
23:27.48starseeker'course, I don't have the validation stuff running with CMake yet
IRC log for #brlcad on 20111015

IRC log for #brlcad on 20111015

01:02.47*** join/#brlcad sydneysider (792c923d@gateway/web/freenode/ip.121.44.146.61)
01:02.56*** part/#brlcad sydneysider (792c923d@gateway/web/freenode/ip.121.44.146.61)
01:26.57*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
02:27.24CIA-48BRL-CAD: 03abhi2011 * r47262 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c simrt.h simulate.h simutils.h): Added logic to generate contact pairs, need to still find a way to properly generalize it to all cases
02:38.12starseekerbrlcad: symlink... you mean my check in archer?
02:39.05starseekerit seems to be resolving the directory paths, but not switching the path to the final location - i.e. the behavior I would have hoped for, although I wasn't sure I would get it until I actually tried it
02:47.07CIA-48BRL-CAD: 03starseeker * r47263 10/brlcad/trunk/src/tclscripts/hv3_man_browser_test.tcl: Shouldn't hurt anything and may make testing easier, go ahead and commit - the shell stuff...
02:55.34starseekeri.e. if the file itself is a symlink, it normalizes the path to that symlink but doesn't follow the symlink itself
02:57.06starseekerso if /usr/brlcad is a symlink to /usr/brlcad/rel-7.20.2, /usr/brlcad/bin/archer resolves to /usr/brlcad/rel-7.20.2/bin/archer
02:57.17*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
02:58.04starseekerbut if I symlink (say) /tmp/archer to /usr/brlcad/rel-7.20.2/bin/archer, tcl will normalize /tmp/archer to /tmp/archer and not follow the file symlink to /usr/brlcad/rel...
02:59.06starseekerat least, that's the behavior I'm observing here
03:13.23CIA-48BRL-CAD: 03starseeker * r47264 10/brlcad/trunk/src/ (other/CMakeLists.txt tclscripts/hv3/hv3.tcl):
03:13.23CIA-48BRL-CAD: Until the more powerful help browser has been worked out, let's go with a
03:13.23CIA-48BRL-CAD: solution that at least avoids printing the error messages - there doesn't seem
03:13.23CIA-48BRL-CAD: to be any actual regression in functionality due to *not* reading the css (not
03:13.23CIA-48BRL-CAD: too surprising since it wasn't originally there at all) so turn off the full hv3
03:13.24CIA-48BRL-CAD: and quell the warning message in our local hv3 subset. Should let things
03:13.25CIA-48BRL-CAD: proceed until the full-powered system gets sorted out.
03:15.03starseekerprobably what I should have done in the first place...
08:35.08*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:06.31*** join/#brlcad kaushikG (Kaushik@122.178.17.110)
11:06.47kaushikGHello
11:08.14kaushikGI'm interested in developing for BRL-CAD as my undergraduate final year project. Who would help me in this regard?
16:16.37brlcadleft too quick!
16:19.47brlcadstarseeker: so if perl isn't being used by cmake, it'd be great to not introduce it into the mix
16:20.29brlcadeven if the cpan module is small, which I suspect it's not, it's pretty complicated for anything more than a one-shot processing (which WOULD be fine)
16:25.29brlcadbut then like I mentioned, I think the best long-term goal is to get the docs for each command colocated with the commands so they can more easily stay in sync .. specifically with usage coming from the source code itself since it has to be there already
16:47.13*** join/#brlcad yiyus (~124271242@je.je.je)
17:05.38abhi2011yes, could have gotten some one to work on the GUI for the simulation stuff :P
17:42.23abhi2011is there a standard way to temporarily quell unused function variables
17:42.50abhi2011i currently simply print there values so that they get used somewhere
18:05.16starseekerbrlcad: that sounds like a step toward literate programming :-)
18:05.52starseekerone issue I see is if we put the "short help" statements in the code, there will be a tendency to just update those and not review the man page for that command (which may also need to be updated)
18:06.30starseekerthat was my thought with the usage being extracted from the docbook - if we go that route, it *doesn't* have to be in the source code
18:07.55starseekerthen 1) update the source 2) update the help statements in the code 3) review and update the docbook man page becomes just 1) update the source 2) review and update the docbook man page
18:08.31starseekerI didn't want (and don't want) to use perl to extract bits from the xml - my hope was xsl + xsltproc alone would be sufficient
18:08.44starseekernot convinced it isn't, for that matter
18:52.13brlcadabhi2011: you can wrap them in UNUSED() though printing them is good too since it's a reminder that you still need to use or lose them
18:53.06brlcadstarseeker: the case of extended docs not getting update will always be an issue -- moving the synopsis to the code ensures that at least the usage is always correct
18:54.38brlcad1 and 2 (updating sort and help statements) are effectively one in the same -- to add a new option means adding new code, which self-documents
18:54.59brlcadthere would be no extended documentation for any new option, but then we could script that into a regression test
18:55.18brlcadchecking the usage is much harder though
18:55.32brlcadnot something that can be reliably tested for given the variety of synposes
18:59.18starseekerbrlcad: but moving usage to the code doesn't really ensure it's always correct - it puts the usage "closer" to the coding action, but that doesn't necessarily mean anything
18:59.54starseekerand I sometimes wonder how useful the usage statements are without the full man page - they often don't help me much in isolation
19:06.51starseekerif we can script a check on the extended documentation in Docbook based on the command, couldn't we also do the same thing for a usage statement defined in docbook, once extracted to a txt file?
19:40.56*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
20:05.42CIA-48BRL-CAD: 03abhi2011 * r47265 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c): Generated the manifold, trying to inject them correctly into the bullet collision pipeline
20:27.59CIA-48BRL-CAD: 03abhi2011 * r47266 10/brlcad/trunk/src/libged/simulate/simrt.c: Floating point issues, had to increase the limit of a loop by TOLerance to ensure rays are shot from edge to edge in overlap volume, strangely NEAR_EQUAL() doesnt seem to work
20:57.27brlcadstarseeker: I wasn't talking about "moving" usage to the code -- that usage is actually derived from the code
20:58.44brlcadpart of a bu_opt interface, supporting long and short options and their dependencies, working with bu_getopt() but also having a helper routine(s) to auto-generate usage statements
20:58.55brlcador output xml or whatever really at that point
20:59.07starseekeroh, I see
20:59.26brlcadstarted getting into it with the libged zoom template, is a clear need
20:59.39brlcadso that's actually what I've been working on next
21:00.07brlcadjust a little stalled by the nurbs and  release review taking so long
21:41.18CIA-48BRL-CAD: 03abhi2011 * r47267 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simphysics.cpp simrt.c simulate.c): Bullet seems to be deleting the contact pairs, added some more callbacks to investigate
21:46.48CIA-48BRL-CAD: 03abhi2011 * r47268 10/brlcad/trunk/src/libged/simulate/simulate.c: Manfold generation cant happen before the physics is run, otherwise the list of manifolds are cleared, it has to happen later
22:49.46abhi2011i was wondering how bu_free knows how many bytes to free as there is size paramter to it :  bu_free(current_manifold, "simulate : current_manifold");
22:51.15abhi2011*there is no size
22:52.46abhi2011probably the C runtime keeps track of allocated chunks
22:54.03brlcadabhi2011: same way free() knows how to release memory from malloc()
22:54.08brlcadkeeps track of the pointer
22:54.20abhi2011yes, ok
IRC log for #brlcad on 20111016

IRC log for #brlcad on 20111016

00:01.29brlcadabhi2011: NEAR_EQUAL() probably didn't work because it compares against the open set
00:02.12brlcadi.e., the values between val-tol to val+tol, but not including those values
00:02.12abhi2011brlcad: open set ?
00:02.21abhi2011ok
00:03.00abhi2011a simple == may work
00:03.29brlcadno, that's the point of the macros
00:03.38brlcadyou cannot rely on == with floating point, it is not reliable
00:03.45abhi2011hmm yes
00:04.14abhi2011so there are no macros which include the boundary values ?
00:04.28brlcadthat's part why NEAR_EQUAL() uses the open set, you cannot reliably compare if a value <= some other value
00:04.41brlcadyou can only compare if it's < or <
00:04.43brlcader >
00:04.48abhi2011ok
00:05.16brlcadso to get the looping effect you were attempting, you were basically just off-by-one due to the tolerance
00:05.45abhi2011yes i wanted it to go upto 1.0000, but it stopped at 0.96
00:05.52brlcadchanging to what you did is fine, val < (max+tol)
00:06.00abhi2011ok
00:07.16brlcadthough that should have been effectively equiv to  !NEAR_EQUAL(val, max, tol)
00:08.03brlcader, I mean !NEAR_EQUAL(val, max+tol, tol)
01:29.26abhi2011yes right :)
06:14.27*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
09:11.33cvds_why is delete used as a "quit terminal" >_>
09:52.35cvds_I wonder what the easiest way would be to get a prism with a 10degree slope
10:02.54CIA-48BRL-CAD: 03tbrowder2 * r47269 10/brlcad/trunk/doc/docbook/ (ElNode.pm read-db-xml.pl): add two tools to read DB xml and extract data for archer
11:09.12*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
12:17.38brlcadcvds_: delete used as a quit terminal?  in what?
12:19.01cvds_brlcad: in mged console mode
12:19.10cvds_if I hit delete on an empty command line mged closes
12:19.32cvds_not a problem unless it happens the first time, I went o_O
12:29.50brlcadeek, that doesn't sound like a quit terminal, that sounds like it's crashing!
12:29.57brlcadhave you ever run gdb before?
12:30.12brlcadgdb --args path/to/mged
12:30.14brlcadrun
12:30.36brlcaduse it, hit delete, see if it returns you to a gdb prompt
12:30.41brlcadthen "bt"
12:42.15cvds_will do
12:43.54cvds_I need to install that ghdb first tho
12:46.20cvds_gdb*
12:58.11cvds_also should I worry if rendering with 'E' gives me a wall of text ?
13:05.53cvds_brlcad: http://pastebin.com/rrtTqJpC however I dont have a version including debug symbols, so not sure i  useful
13:05.59cvds_if its*
13:06.55*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:09.35brlcadcvds_: typing delete inserted that "exit" command?
13:10.11brlcadthat's not a crash, that's a normal exit .. but it's certainly not expected
13:10.32brlcadE giving a wall of text is normal - it's the output from tessellating the geometry into a polygonal mesh
13:13.12cvds_including: ERROR: first hit on bodyCOuter.s (surfno = 12) is an exit at (-6.42262 13 11) ray start = (-4.451251276587e+00 1.300000000000e+01 1.100000000000e+01), ray dir = (1.000000000000e+00 0.000000000000e+00 -1.366428338000e-16)
13:13.37cvds_and technically its not "typing" delete but pressing the delete key :)
13:14.30cvds_but its indeed curious why its linked to exit, ctrl-d works as well btw, but that I do find expectid behavior
13:14.39cvds_expected*
13:20.09*** join/#brlcad yiyus (1242712427@je.je.je)
13:33.46cvds_another thing I noticed that after using red the comb_color will have reset
13:50.47brlcadwhich version are you using?
14:02.54cvds_brlcad: http://pastebin.com/3VmSQiZt
14:19.16brlcadcvds_: for future reference, pastebin.com not only sucks but is inaccessible to most in the channel some of the time due to network blocks -- suggest pastebin.ca or paste.debian.org or just about any other ;)
14:19.34brlcadyeah, I'll verify, but I'm pretty sure that red bug was fixed in 7.20
14:23.26cvds_brlcad: okies, will divert to the debian one for further posts
14:23.51cvds_first component is nearing the done stage... took a long time
14:26.13cvds_well the first version... no doubt that after printing I will be making adjustments
14:41.35starseekercusses Windows and Tcl/Tk both
14:42.11starseekerjust when I thought I finally had this licked, I can't get wish going on Win32 with 8.6
14:49.02brlcadheh
14:49.19brlcadcvds_: would love to see pics of your work (before and after printing)
15:10.57cvds_brlcad: Maybe I can post some renders on flickr later today
15:12.28cvds_last couple of primitives to add
16:01.08cvds_brlcad: http://flic.kr/s/aHsjwoVYoK
16:07.48starseekergrowses... what's the poing of a HAVE_ZLIB flag if you're going to guarantee you always have zlib...
16:17.38*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
16:57.14brlcadcvds_: that's pretty awesome!
16:57.26brlcadso you're going to have that geometry printed?
16:57.56brlcadeither way, pretty cool .. nice level of detail
16:57.59brlcadwhat is it? :)
16:58.02cvds_brlcad: yes, but have to build the printer first :)
16:58.31cvds_its a finger switch with 5 directions, N E S W and down
16:59.36cvds_and I would not be amazed that I need to adjust some of it to make it printer compitable
16:59.46cvds_comaptible*
17:02.02cvds_hmm here is to hoping I can fit the 2 missing optocoupler space
17:02.03cvds_s
17:15.13*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
17:59.12cvds_and thanks for the compliment
18:01.50cvds_hmm a raytrace from a sliced version takes way longer
18:23.47*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
19:16.04cvds_brlcad: more renders: http://flic.kr/s/aHsjwoVYoK
20:11.25CIA-48BRL-CAD: 03abhi2011 * r47270 10/brlcad/trunk/src/libged/simulate/ (7 files): Separated the list of manifolds generated by bullet and that generated by rt, as they are required at different times during the simulation iterations
20:24.51CIA-48BRL-CAD: 03abhi2011 * r47271 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.h): Corrected some errors in setting up the linked list
20:56.25CIA-48BRL-CAD: 03abhi2011 * r47272 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c): Corrected some code for generating the normals and depth values correctly
23:27.01CIA-48BRL-CAD: 03abhi2011 * r47273 10/brlcad/trunk/src/libged/simulate/simcollisionalgo.cpp: The manifold points were not getting inserted correctly, fixed it to some extent, still cant keep objects steady on top of each other, hunting for what I am missing out
23:55.05starseekercvds_: the -k option to rt is helpful when you're doing sliced views
23:55.24starseeker(think it's -k - the cutting plane)
IRC log for #brlcad on 20111017

IRC log for #brlcad on 20111017

00:17.28CIA-48BRL-CAD: 03abhi2011 * r47274 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c):
00:17.28CIA-48BRL-CAD: More changes to help in debugging, disabled rayshooting for now, generating
00:17.28CIA-48BRL-CAD: points only from the overlap region as I am debugging the case of a small box
00:17.28CIA-48BRL-CAD: lying on a thin but larger box, so the overlap region can be used to generate
00:17.28CIA-48BRL-CAD: correct contact pairs. Apparently the contact pairs are getting inserted but are
00:17.29CIA-48BRL-CAD: not making it till the dynamics component of Bullet
01:15.28brlcadabhi2011: BU_STR_EQUAL() is your friend
01:18.51abhi2011brlcad: ah yes, I forgot that macro
01:58.54brlcadexists specifically to avoid that common logic bug and to improve readability
07:23.54CIA-48BRL-CAD: 03d_rossberg * r47275 10/brlcad/trunk/src/archer/CMakeLists.txt: the DESTINATION of FILE(COPY ~) is a directory
08:28.00*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:22.08*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:00.05cvds_starseeker: thanks
13:00.26cvds_for the -k tip, will need to try that for the next render batch
14:20.12brlcad-k should be a good bit faster than manually creating a cut view yourself (if it's not, file a report!) :)
14:28.21CIA-48BRL-CAD: 03erikgreenwald * r47276 10/brlcad/trunk/src/libgcv/bottess.c: Bump up memory pool grow size. Add face splitting for vert/line case. Step back indices on split to make sure all splits are computed.
14:57.44CIA-48BRL-CAD: 03erikgreenwald * r47277 10/brlcad/trunk/src/libgcv/bottess.c: collapse switch down to math and ternaries
16:56.27*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
17:35.43CIA-48BRL-CAD: 03erikgreenwald * r47278 10/brlcad/trunk/src/libgcv/bottess.c: Woops, triangles should be CCW, not CW
17:53.12CIA-48BRL-CAD: 03erikgreenwald * r47279 10/brlcad/trunk/src/libgcv/bottess.c: cheesy hardcoded stl output to avoid the nmg mess for now
19:56.36*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:56.54cvds_brlcad: it would also clutter the database less ;)
20:29.03CIA-48BRL-CAD: 03erikgreenwald * r47280 10/brlcad/trunk/src/libgcv/bottess.c: add in/out classifier to vert/line splitter
23:43.01CIA-48BRL-CAD: 03abhi2011 * r47281 10/brlcad/trunk/src/libged/simulate/simcollisionalgo.cpp: Debugging continues, apparently the points in rigid body A which is calculated from the point for B and the normal pointing from A to B, is not getting calculated
IRC log for #brlcad on 20111018

IRC log for #brlcad on 20111018

00:55.39*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
00:55.39*** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net)
00:55.39*** join/#brlcad piksi (piksi@pi-xi.net)
00:55.39*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
00:55.39*** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
04:34.59CIA-48BRL-CAD: 03abhi2011 * r47282 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c): Some corrections to normals and contact pair generation
05:25.52abhi2011hmm, I need to call the rt related C functions from the c++ code of Bullet's physics pipeline
05:26.22abhi2011however when I try to call them from within the C++ code, I see to run into undefined reference errors
05:26.40abhi2011even though  I have declared the functions by including the header
05:27.20abhi2011is it possible to directly call C functions from within C++
05:29.49abhi2011hmm there seems to be some compiler mangling of C functions going on,  need to smooth the linkage
05:31.02abhi2011this is turning out to be really loopy....from C code of libged >>>> C++ Code of Bullet >>> C code of RT to get the contact pairs >>>> C++ code of bullet for dynamics >>>> back to C code of libged to finish off
05:38.38abhi2011ok some useful info here : http://developers.sun.com/solaris/articles/external_linkage.html
05:49.03abhi2011hmm got around the linkage issue, seems raytracing code has to be inserted right into the bullet nearphase callback to ensure contact pairs are generated at the right place
06:35.27*** join/#brlcad tofu (~sean@BZ.BZFLAG.BZ)
08:29.15*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:12.36*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
14:27.58CIA-48BRL-CAD: 03erikgreenwald * r47283 10/brlcad/trunk/src/libgcv/bottess.c: Finish up split cases. Fix bug in composer that didn't throw away faces. Combine both triangle sets in composer.
14:33.04*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
14:43.21CIA-48BRL-CAD: 03erikgreenwald * r47284 10/brlcad/trunk/src/libgcv/bottess.c: collapse switch into ternary/math
14:46.50*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:00.42*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
15:18.00CIA-48BRL-CAD: 03abhi2011 * r47285 10/brlcad/trunk/src/libged/simulate/ (7 files): Moving towards tighter integration of raytracing with the Bullet pipeline to ensure the contact pairs are injected at the right point during the simulation, added some extern C linkage code to allow this integration
15:29.33abhi2011cant seem to find a way to get rid of this warning : http://bin.cakephp.org/view/975048800
17:16.07tofuabhi2011: that's not your problem .. it's a valid warning when compiling that C struct within the context of a C++ file
17:17.18abhi2011tofu: ok
18:34.05tofubasically, there's a C function (ged_view()) and a struct named ged_view ..
18:34.57tofustruct is == class when compiling in C++, so when it creates the default constructor (ged_view()) it ends up shadowing the existing function
19:26.51CIA-48BRL-CAD: 03brlcad * r47286 10/brlcad/trunk/ (Makefile.am configure.ac):
19:26.51CIA-48BRL-CAD: add the tar-ustar option to AM_INIT_AUTOMAKE so that we're not limited to paths
19:26.51CIA-48BRL-CAD: 99 chars or less. ustar increases the limit to 256 chars (tar-pax would
19:26.51CIA-48BRL-CAD: increase it to unlimited, but requires 1.9). this effectively drops
19:26.51CIA-48BRL-CAD: out-of-the-box build support on Mac OS X 10.4 but it's an old system and
19:26.52CIA-48BRL-CAD: autotools is almost out the door so allow the bump in order to get a valid
19:26.53CIA-48BRL-CAD: release tarball.
19:45.59CIA-48BRL-CAD: 03abhi2011 * r47287 10/brlcad/trunk/src/libged/simulate/ (7 files): Removed 2 linked lists and replaced with static allocation, dynamic memory is more of a hassle than its worth
20:46.20CIA-48BRL-CAD: 03brlcad * r47288 10/brlcad/trunk/src/tclscripts/mged/reid.tcl: accept reid patch from carl moore that reorganizes the arg checking logic and reports a statement when the assembly is not a combination.
20:54.47CIA-48BRL-CAD: 03brlcad * r47289 10/brlcad/trunk/src/tclscripts/mged/reid.tcl: dry principle, put usage in only one place to reduce logic
20:57.23CIA-48BRL-CAD: 03brlcad * r47290 10/brlcad/trunk/AUTHORS: credit carl moore from ARL for tclscript patches (reid/remat/relos)
20:59.33CIA-48BRL-CAD: 03brlcad * r47291 10/brlcad/trunk/src/tclscripts/mged/remat.tcl: another change from carl moore, making remat similarly report 'Not a combination.' if the assembly isn't a comb.
21:02.29CIA-48BRL-CAD: 03brlcad * r47292 10/brlcad/trunk/src/tclscripts/mged/relos.tcl: add a new 'relos' command, similar to reid and remat, contributed from carl moore of ARL.
21:02.52CIA-48BRL-CAD: 03brlcad * r47293 10/brlcad/trunk/src/tclscripts/mged/ (CMakeLists.txt Makefile.am): add the new relos.tcl file to the build/install/dist
21:03.27CIA-48BRL-CAD: 03brlcad * r47294 10/brlcad/trunk/src/tclscripts/mged/relos.tcl: fix header
21:04.56CIA-48BRL-CAD: 03brlcad * r47295 10/brlcad/trunk/src/tclscripts/mged/help.tcl: apply final patch from carl moore, updating documentation to reflect the new relos command
21:05.54CIA-48BRL-CAD: 03abhi2011 * r47296 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simutils.c): Corrected some indexing errors which arose while removing the linked lists
21:08.09CIA-48BRL-CAD: 03brlcad * r47297 10/brlcad/trunk/NEWS: credit carl moore with his last-minute contribution of a new 'relos' command to mged. similar to remat, assigns the specified los to all regions under a given assembly.
22:38.19*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:10.52CIA-48BRL-CAD: 03abhi2011 * r47298 10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp simrt.c): Corrected manifold point generation again to report the deepest points as those belonging to body B
IRC log for #brlcad on 20111019

IRC log for #brlcad on 20111019

01:23.21*** join/#brlcad Otto_ (~Otto@cpe-24-210-25-11.columbus.res.rr.com)
01:26.38*** part/#brlcad Otto_ (~Otto@cpe-24-210-25-11.columbus.res.rr.com)
02:16.29CIA-48BRL-CAD: 03brlcad * r47299 10/brlcad/trunk/ (configure.ac src/other/Makefile.am): turn off our libpng subbuild entirely by default, even for enable-all, just so we're closer to a clean autotool distcheck for release
02:40.07CIA-48BRL-CAD: 03brlcad * r47300 10/brlcad/trunk/doc/docbook/Makefile.am: typo, should be CatalogManager.properties
07:26.20*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
12:09.45*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
14:56.06CIA-48BRL-CAD: 03brlcad * r47301 10/brlcad/trunk/doc/docbook/Makefile.am: this looks like the last problem remaining with the autotools distcheck. there are two files being generated in resources/brlcad that do not belong in the dist that were causing a problem. have to itemize.
15:01.07CIA-48BRL-CAD: 03brlcad * r47302 10/brlcad/trunk/doc/docbook/Makefile.am: uncomment, was just for debugging
15:01.45brlcadabhi2011: how's it going?  been a while since checked in on progress
15:01.52brlcadbeen watching the commits
15:03.26abhi2011well brl-cad I am just putting up some pictures in  web log explaining my work so far :)
15:03.39brlcadexcellent :)
15:03.51abhi2011so basically I have inserted a custom algorithm for collision detection between 2 boxes
15:04.09abhi2011and this algorithm inserts manifold points
15:04.13CIA-48BRL-CAD: 03erikgreenwald * r47303 10/brlcad/trunk/src/libgcv/bottess.c: fix bad comparison in 5 face split
15:04.24abhi2011generated by raytracing in the overlap region(aabb overlap region)
15:04.51abhi2011however when I do this I am not able to make a smaller box lie still on a thinner but bigger one
15:05.31abhi2011so I am trying to figure out why bullet is not keeping the smaller box stable, even though I insert manifold points exactly as bullet does
15:06.03abhi2011it involves investigating the dynamics part of bullet
15:06.18abhi2011which is not the easiest thing I have done so far :P
15:06.37abhi2011so I have posted the issue in the bullet forums
15:06.40brlcadlie still?
15:06.45abhi2011yes
15:06.56abhi2011if a box is lying on a plane
15:07.04abhi2011it will stay as it is
15:07.21abhi2011that is what I meant by lying still...stationery
15:07.22brlcadbecause the bb's don't overlap
15:07.44abhi2011well, actually they overlap very slightly
15:07.51abhi2011about 0.00001 m
15:07.53brlcadk
15:08.06abhi2011thats allowed for smooth physics
15:08.15brlcadso that creates a contact interface, presumably
15:08.16abhi2011some interpenetration is necesssary
15:08.34abhi2011yes correct
15:08.59brlcadso can you explain the general algorithm to me? or is it written down somewhere?
15:09.08brlcadgiven two arbitrary bb's
15:09.11abhi2011yes sure, its quite simple
15:09.12abhi2011yes
15:09.56abhi2011so given 2 bounding boxes I calculate where they overlap
15:10.06abhi2011that will also be a cuboidal volume
15:10.10brlcadgiving some smaller intersection box
15:10.20brlcadsmaller or equal, rather
15:10.55abhi2011yes thats right
15:11.25abhi2011the volume where  the 2 aabbs intersect will of course be smaller than the 2 aabbs we are intersecting
15:11.34abhi2011or equal of they exactly overlap
15:11.43abhi2011*if they
15:11.47brlcadnods
15:12.30abhi2011so there is a function called get_overlap() in simrt.c which does this
15:12.55abhi2011so once i have the overlap volume
15:13.07abhi2011then I shoot rays along the x axis
15:13.32abhi2011specifically from the minimum X towards the maximum X
15:13.47abhi2011so if the overlap box is from -1,-1,-1 to 1,1,1
15:13.58abhi2011then I shoot rays from -1 to 1 parallel to x axis
15:14.13abhi2011the rays will be perpendicular to the yz plane
15:14.17brlcadthat will likely be insufficient (but can be fixed later)
15:14.25brlcadshooting down just one axis
15:14.37abhi2011yes I intend to shoot along the y and z too
15:14.53abhi2011but for the simple case that I am testing with
15:15.00abhi2011its sufficient
15:15.07brlcadokay, though .. so you shoot a grid of rays (presumably with one_hit turned off?)
15:15.20abhi2011so Iyes
15:15.22abhi2011*yes
15:15.36brlcadso then you have partitions
15:15.38abhi2011so the rays shoot though the overlap region
15:15.40abhi2011yes
15:15.41brlcadsegments
15:15.46abhi2011I have a overlap callback
15:15.59abhi2011which records the overlap partitions in a structure
15:16.29abhi2011and I later analyze them to see the maximum X, min X etc when the ray is passing through a overlap region
15:16.51abhi2011all goed so far :)
15:17.51abhi2011so the place where say a  ray enters a overlap region is a single point in 3D space
15:17.59abhi2011so i make this one of the contact points
15:19.41brlcadwhat does bullet want?
15:19.53abhi2011the contact points and the penetration depth
15:20.07abhi2011so if a body A is penetrating body B
15:20.08brlcaddo you just provide contact points, or points and vectors based on thickness of overlap?
15:20.13brlcador a surface?
15:20.40abhi2011I provide only the contact points for body B , the depth upto which body B has penetrated into body A and the normal from body B to A
15:20.44abhi2011so 3 things
15:21.00abhi2011so if we have a box lying on a ground plane
15:21.12abhi2011and say the box is body A and the ground is B
15:21.20abhi2011then A will slight penetrate B
15:22.15abhi2011then I generate contact points for  B, which will be slightly inside it
15:22.25abhi2011the extent of penetration is the depth
15:22.44abhi2011and the normal will simple be 0,0,1 (positive Z axis)
15:23.02brlcadabhi2011: hold up, gotta run out for a second .. very interesting, to be continued... :)
15:23.14abhi2011yeah sure, will get some pics up meanwhile :)
15:23.22brlcadthis is getting into meat and I'm sure I'll have more questions :)
15:23.33abhi2011hehe
15:30.30abhi2011right so since geometry is involves it will be easier to be on the same page (so to speak :P) : https://docs.google.com/drawings/d/1FVUPyeoq6YWHKPzlDadrZch8qOw0jBjeFgJ3FHtL1SE/edit?hl=en_GB
15:52.58*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:58.13*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
16:00.19*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
16:39.19abhi2011more discussion here : http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=7517&p=25901#p25901
16:39.33abhi2011no replies however :(
17:07.29brlcadabhi2011: your message was trimmed :)
17:07.52abhi2011in the forum ?
17:07.55brlcadyeah
17:07.56abhi2011I am still updating it
17:08.08abhi2011too much text to put in
17:08.09brlcadaha! i see
17:08.24abhi2011the basic thing i want to convey is
17:08.33abhi2011if i look at the bullet points
17:08.43abhi2011i see A penetrate B initially
17:08.53abhi2011but its gradually pushed out after iteration 12
17:09.00abhi2011and by 20 its quite stable
17:09.09abhi2011however for me it justs keeps on sinking
17:09.40brlcadyou mean some example that bullet provides?
17:09.42abhi2011so the constraint solver is not constraining the contact points , which would have held the box foxed in 3d space
17:10.04abhi2011no the example that I am discussing in that thread
17:10.06brlcador just allowing the regular collision detection to work
17:10.21abhi2011regular collision detection
17:10.32brlcadyou're discussing a LOT of points in that thread
17:10.45abhi2011if i allow regular collision detection to work then it holds the box stable on the plane
17:11.16brlcadmight be part why there's no response .. there are lots of questions and they all probably warrant a fair bit of discussion :)
17:11.37brlcadyou mean it's stable after 20 iterations
17:11.51abhi2011hmm yeah, yet I am focussing on 1 very simple case, just that there is a lot to it
17:12.07abhi2011injecting custom contact points takes some changes to the code
17:12.21abhi2011yes its stable after 20 iterations
17:12.32abhi2011using regular collision detection
17:13.02abhi2011however if I start to inject my own contact points, then its not stable , the box passes right through the plane
17:13.07abhi2011as gravity is acting
17:13.43brlcadso there's something happening with the default collision detection that you're not doing
17:14.45abhi2011exactly
17:14.54abhi2011i have been seaching for that
17:15.14abhi2011the only interface is the addcontactpoints()  function
17:16.32brlcadhave you looked at the code for the default?
17:16.46brlcador do they have an example that calls addcontactpoints()
17:17.18abhi2011yes they have code that calls addcontactpoints() in their default box-box collider
17:17.57abhi2011I dont see anything else being set, but its possible that some global member of derived member gets set in the 800 lines+ of code
17:18.05abhi2011*or derived
17:18.05brlcadI'm thinking that you may have to not only provide the contact points and normals, but also invoke some callback to apply the forces
17:18.29abhi2011yes that will happen automatically after the points are put in
17:18.37abhi2011its all in 1 flow
17:18.48abhi2011i just inject the points at the right point in the flow
17:18.53brlcadi'm saying maybe it's not automatic
17:19.09brlcadunless you set something that says "do it automatically"
17:19.18abhi2011hmm, but the forces do act as otherwise the top box wouldnt move
17:19.19brlcadthat would explain it
17:19.33brlcadthere's still a global gravity force
17:19.44abhi2011yes
17:19.51brlcadit's not applying the new force from the collision interaction
17:20.05abhi2011yep, its pretty certain I am not doing something like that
17:20.20brlcadbut then you've defined a cusom collision handler, so I could easily see them adding a callback or state value that lets you override/ignore/modify the force too
17:20.40brlcadthe *collision/interaction* force
17:20.49brlcadforce(s)
17:21.16abhi2011yes, the thing is there is no callbacks in the force-application part of the pipeline
17:21.40abhi2011only in the collision point generation part there is some callbacks and the possiblity to inject points
17:21.53abhi2011so I ll go ahead with gdb
17:22.16abhi2011and step through the force-application part and see whats happemning
17:22.18brlcaddoesn't have to be a callback, could just be a bullet function that gets called (recalculateForcesBasedOnNewContactPoints())
17:22.41abhi2011yes
17:22.46brlcador, like I said, some global environment set up that happens earlier
17:23.20abhi2011yes
17:23.49abhi2011but apart from that the algorithm is as shown in that google doc
17:24.36abhi2011the rays are shot and the entry points can be converted to contact points ...and some extra logic of course for the depth and normals(VCROSS the points)
17:25.31brlcadnods (though I can't get to google docs until later)
17:25.58abhi2011ok, yeah its the same picture as the one on the thread, the white colored background
17:30.10abhi2011the last post summarizes it all
17:36.42abhi2011wish there was a irc for Bullet too :)
17:37.49brlcadyou mean like #bulletphysics?
17:38.37abhi2011hehe clicked on it and got hopeful for a second :P
17:38.52brlcadhm?
17:39.21abhi2011#bulletphysics is not an actual channel , I hoped it was
17:39.31brlcadit is
17:39.39abhi2011oh wait the question mark came
17:39.42abhi2011:P
17:39.46abhi2011i ll try again
17:39.57brlcadjust type /join #bulletphyics
17:40.01abhi2011ah
17:40.03abhi2011yes
17:40.05abhi2011am in
17:40.13abhi2011thanks :P
17:41.25brlcadabhi2011: have you read http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=5365&p=19270&hilit=+contact+pair+#p19270 ?
17:41.59abhi2011no not yet, will have a look
17:43.18brlcadmight not be related, but speaks some about contact pairs with a couple responses
17:43.42abhi2011hmm it seems to add points over multiple iterations, I however add them in 1 shot as every iteration is a cold start
17:43.58abhi2011that is from the beginning with world setup an everthing
17:44.27brlcadyou using a btGImpactMeshShape ?
17:44.34abhi2011no
17:44.36abhi2011only boxes
17:44.40abhi2011btBoxShape
17:44.45brlcadk
17:45.24abhi2011for all BRL-CAD shapes (the actual shapes are of course resolved based on rt etc etc as dicussed before)
17:46.07brlcadhm, http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=7498&hilit=custom+collision implies there is a callback for adding contacts
17:46.19brlcadso perhaps the default is simply "do nothing" when you override
17:46.35brlcador setCollisionFlags() needs some magic
17:48.09brlcadinteresting snippet that uses ray casting for collision detection (car demo)
17:48.09brlcadhttp://code.google.com/p/game-ws/source/browse/branches/cardemo/src/raycast_car.cpp
17:48.32abhi2011oh awesome
17:48.34abhi2011:)
17:52.30brlcadcalculateCombinedRestitution() looks somewhat important
17:53.09brlcadalong with the CF_CUSTOM_MATERIAL_CALLBACK collision flag
17:53.28abhi2011yes, I think those will be called anyway as those parts are unchanged
17:53.48brlcadthe example I was looking at called them directly
17:53.54abhi2011hmm will verify that though
17:54.00abhi2011yes
18:07.36*** join/#brlcad piksi (piksi@pi-xi.net)
18:13.23CIA-48BRL-CAD: 03n_reed * r47304 10/brlcad/trunk/src/other/step/src/express/express.c: add token printing debug routine
18:17.18CIA-48BRL-CAD: 03brlcad * r47305 10/brlcad/trunk/doc/docbook/Makefile.am: DO need the catalogs to be listed as BUILT_SOURCES so that they're properly cleaned up for distclean. hopefully the last dist issue.
18:18.27abhi2011hmm  I think I see a way out of this mess :p
18:18.56abhi2011so there are basically 2 approaches possible for supporting arbitrary shapes inside Bullet
18:19.53brlcadyes?
18:19.57abhi20111. The more 'low level' one , where , whenever a body touches another body , I let them penetrate a bit so I can detect the overlap using rays and generate contact points
18:20.29abhi2011these contact points are injected into the bullet physics pipeline and are kept fixed in space by the constraint solver
18:20.37abhi2011thus fixing the body they belong to, also in space
18:20.49abhi20112. The more higher level approach
18:21.00abhi2011which the raycast vehicle appears to use
18:21.10abhi2011detect overlap using raycast as usual
18:21.18abhi2011however apply the force yourself
18:21.28abhi2011at the contact point
18:21.46abhi2011instead of hoping-against-hope that bullet will do it for you :P
18:22.02abhi2011which it wont :)
18:22.35abhi2011so I think this should work for convex shapes too and any arbitrary shape
18:23.29abhi2011except that the force at the contact point has to applied in the right direction : normal to the surface, and also on both bodies
18:23.42abhi2011but then there is the question of how much force to apply
18:24.29abhi2011that has to be calculated using restitution etc and then there is friction, so basically doing a lot of the stuff that bullet should do
18:26.16abhi2011hmm guess I ll take the second approach for now since it seems to offer some control over the restitution etc too
18:30.37abhi2011for calculating the magnitude of force to be applied at the point of contact,  I would need to acceleration of the body in the previous frame
18:32.20abhi2011concave objects can have multiple overlap regions(eg wine goblet lying on its side on the floor), but that can be dealt with later
18:50.19brlcadabhi2011: whichever path you plough down, handling the concave case is going to be critical
18:50.52brlcadit won't be usable for anything except very simple demos if it only supports convex shapes
18:51.18brlcadfun and neat, but not practical
18:57.10CIA-48BRL-CAD: 03brlcad * r47306 10/brlcad/trunk/TODO: rtcheck within mged seems to be working just fine
19:00.55CIA-48BRL-CAD: 03brlcad * r47307 10/brlcad/trunk/TODO: couldn't get red to crash with multiple/any blanks lines, so shoould be good to go for release. did notice that the mac input bug seems to be back, though.
19:03.56``Erikhm, tesla lost the libel case against top gear
19:04.03CIA-48BRL-CAD: 03brlcad * r47308 10/brlcad/trunk/doc/docbook/Makefile.am: define a creation rule for FOP_XML_CATALOG too since it's also a dep on all
19:28.29CIA-48BRL-CAD: 03bob1961 * r47309 10/brlcad/trunk/src/tclscripts/lib/Accordian.tcl: This is an implementation in Itcl/Itk of an Accordian widget. Internally it uses ttk widgets.
19:29.25CIA-48BRL-CAD: 03bob1961 * r47310 10/brlcad/trunk/src/tclscripts/lib/CMakeLists.txt: Added an entry for Accordian.tcl
19:49.21abhi2011brlcad: yes i think concave objects will generally cause forces acting at various distances from the body's center leading to torques
19:49.39abhi2011if these torques cancel each other out, the body will be stable
19:51.06abhi2011like if we take the case of a marble dropping inside a cup
19:51.56abhi2011then the forces acting on the bottom points of the marble as it makes contact with the base of the cup will stop its fall
19:52.17abhi2011but contact with inside edges of the cup will cause it to roll about for some time
19:57.33abhi2011i have 1 question though
19:58.02abhi2011wlll the rays report the normals to the surfaces of objects
19:58.42abhi2011even if the rays themsleves are entering the targetted object at an angle to the surface
20:08.54brlcadyou can get the surface normals for all hit points
20:09.20brlcadRT_GET_NORMAL() as well as other means
20:12.36CIA-48BRL-CAD: 03bob1961 * r47311 10/brlcad/trunk/src/tclscripts/lib/Accordian.tcl: Added the togglePanel method to cadwidgets::Accordian
23:36.47*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20111020

IRC log for #brlcad on 20111020

00:27.57abhi2011brlcad: ok :)
05:02.16*** join/#brlcad piksi (piksi@pi-xi.net)
06:43.04*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
12:58.52*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
15:09.42*** join/#brlcad ibot (~ibot@rikers.org)
15:09.43*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
16:28.52*** join/#brlcad ibot (~ibot@rikers.org)
16:28.52*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
18:36.57*** join/#brlcad saltan (~lieven@d51530284.static.telenet.be)
18:37.18*** part/#brlcad saltan (~lieven@d51530284.static.telenet.be)
22:52.41*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20111021

IRC log for #brlcad on 20111021

02:54.58brlcadarrives in cali, stickers look awesome :)
06:36.33*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:27.43starseekerawesome!
08:27.50starseekerheads out
09:05.29``Erikpics or it didn't happen
11:38.55*** join/#brlcad mattS_ (792c03a7@gateway/web/freenode/ip.121.44.3.167)
11:40.00mattS_Hiya!
11:40.30mattS_I'm trying to find the source code for rcc (presumably rcc.c?)
11:40.52mattS_Can't sem to find it in SVN
14:05.31*** join/#brlcad merzo (~merzo@53-130-132-95.pool.ukrtel.net)
14:27.05CIA-48BRL-CAD: 03bob1961 * r47312 10/brlcad/trunk/src/librt/primitives/bot/bot.c: Modified rt_bot_split_func() and rt_bot_sync_func() to NOT be recursive. Still a brute-force approach however (more to follow in this regard).
14:38.54brlcadhowdy mattS_
14:39.38brlcadmattS_: src/librt/primitives/rcc
14:41.28brlcadclosely related to the general case in src/librt/primitives/tgc (truncated general cone)
14:57.07*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:50.48*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
15:55.52CIA-48BRL-CAD: 03bob1961 * r47313 10/brlcad/trunk/src/librt/primitives/bot/bot.c: Using size_t for indices into stacks for rt_bot_split_func() and rt_bot_sync_func(). Note - struct rt_bot_internal should be using "size_t *" instead of "int *" for the faces and face_normals members.
16:57.56CIA-48BRL-CAD: 03n_reed * r47314 10/brlcad/trunk/src/other/step/ (6 files in 3 dirs): Developing routine to print parser return object, useful for inferring parser behavior.
16:58.46CIA-48BRL-CAD: 03abhi2011 * r47315 10/brlcad/trunk/src/libged/simulate/ (6 files):
16:58.46CIA-48BRL-CAD: Added tick callbacks to apply forces, the current plan is to balance objects
16:58.46CIA-48BRL-CAD: correctly by applying an appropriate force on them when they collide. The force
16:58.46CIA-48BRL-CAD: will be applied through the center of the contact volume. Friction forces have
16:58.46CIA-48BRL-CAD: to calculated explicitly but we will cross that bridge once objects can be kept
16:58.46CIA-48BRL-CAD: stable upon each other.
17:11.29CIA-48BRL-CAD: 03abhi2011 * r47316 10/brlcad/trunk/src/libged/simulate/ (8 files): Indentations corrected in simulate files
17:18.37CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3182 10/wiki/User:Abhijit: /* Log */
20:27.12mattS_brlcad: Yeah, that's where I thought it would have been too.  But alas...
22:00.34*** join/#brlcad mattS_ (792c03a7@gateway/web/freenode/ip.121.44.3.167)
22:11.21*** join/#brlcad kanzure (~kanzure@131.252.130.248)
22:35.32CIA-48BRL-CAD: 03n_reed * r47317 10/brlcad/trunk/src/other/step/src/express/expprint.c: making progress; learning about the Express object structure as I go
22:36.35*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20111022

IRC log for #brlcad on 20111022

01:37.51brlcadmattS_: what do you mean ... alas, you found it?
01:39.34brlcadoh right, sorry mattS_ -- rcc is *just* a specialization of tgc, so the source link I mentioned for tgc is the one you want
03:30.13mattS_Hence why I could not find the rcc.c code :-)  Thanks, this has helped.  Revolve coming along nicely, just slowly.  Full time job and all that sort of stuff getting in the way of fun!
05:19.35brlcadmattS_: as soon as you have anything that works better, you're welcome to submit a patch so someone can review and integrate it
05:20.56brlcadas long as it compiles and is an improvement, it's worth making a patch for it -- "svn diff > mychanges.patch" will make the patch for you if you have an svn checkout
05:22.09brlcadalso, the smaller the patch, the easier it is to review and integrate, so emphasis that the feature doesn't have to be "complete" .. if you get something working, make a patch, upload it to sourceforge, and that'll also give other devs a chance to review and comment on it
05:35.26mattS_That is my basic plan, but my programming skills are really quite poor.  So, I've sketched out how to "complete" the tool, and am ironing all the (mathematical) kinks out.  I will require a fair bit of input to get the code working, though...
05:42.38mattS_Probably require, that is.
07:03.22*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
09:47.53cvds_ted and red grow on you when you are used to them. Just wondering why ted must be called from inside sed mode
10:37.57*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:29.05*** join/#brlcad merzo (~merzo@181-75-133-95.pool.ukrtel.net)
15:26.01CIA-48BRL-CAD: 03AbbyStokes 07http://brlcad.org * r3183 10/wiki/Overview:
15:28.28CIA-48BRL-CAD: 03AbbyStokes 07http://brlcad.org * r3184 10/wiki/Building_from_SVN: /* Obtain the sources */
15:29.24cvds_new renders of a simplified design: http://flic.kr/s/aHsjwsSZmT
15:55.41CIA-48BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:AbbyStokes]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
15:56.01CIA-48BRL-CAD: 03Sean 07http://brlcad.org * r3185 10/wiki/Overview: Reverted edits by [[Special:Contributions/AbbyStokes|AbbyStokes]] ([[User talk:AbbyStokes|Talk]]); changed back to last version by [[User:Sean|Sean]]
15:56.25CIA-48BRL-CAD: 03Sean 07http://brlcad.org * r3186 10/wiki/Building_from_SVN: Reverted edits by [[Special:Contributions/AbbyStokes|AbbyStokes]] ([[User talk:AbbyStokes|Talk]]); changed back to last version by [[User:Willdye|Willdye]]
16:09.37*** join/#brlcad ibidem (~idunham@scfib1G217.snowcrest.net)
16:10.19ibidemtrying to build brlcad on debian squeeze
16:11.12ibidemhave the dependencies installed, ./configure works
16:12.30ibidembut when I compile, it errors out in librt
16:17.06ibidemapparently search.c has several static declarations while search.h has nonstatic declarations
16:19.11*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
16:25.06ibidemi'd guessed that it might be from using the wrong yacc version
16:26.15ibidembut it looks like search.{c,h} aren't generated by yacc
16:55.28ibidemwell, I got librt to compile
16:55.58ibidems/^int/static int/
16:56.25ibidemon search.h
16:56.55ibidemwas that a bad idea?
17:08.17brlcadibidem: no, that should be fine
17:21.11ibidemok, just got it installed--no more problems
17:45.33ibidemone more thing-apparently archer needs tools.png installed before it will run
17:46.24ibidemcopy that over and archer runs fine on squeeze
19:25.12CIA-48BRL-CAD: 03brlcad * r47318 10/brlcad/trunk/src/librt/ (search.c search.h): ibidem (via irc) noted a declaration mismatch between search.h and search.c; eliminate the unnecessary forward declarations save for the few c_* callbacks used in the options array.
19:26.13brlcadibidem: ah, that would probably be mismatch between the autotools build and our new cmake build
19:28.18CIA-48BRL-CAD: 03brlcad * r47319 10/brlcad/trunk/src/tclscripts/archer/images/Makefile.am: tools.png missing from dist/install, thx to ibidem (via irc) for reporting issue.
19:29.12brlcadwe're in the process of migrating to a new cmake-based build system, so the autotools infrastructure will be removed in a few months
19:29.55brlcadcvds_: that's a relic from mged's original heavy-modal heritage (ala vim)
19:30.16brlcadslowly migrating towards becomging completely modeless
19:31.46brlcadcvds_: you may like running rtwizard or manually running rtedge in overlay mode to emphasize the edges in your renderings ;)
19:35.40CIA-48BRL-CAD: 03brlcad * r47320 10/brlcad/trunk/TODO: so sayeth bob, struct rt_bot_internal should be using size_t * instead of int * for the faces and face_normals members
IRC log for #brlcad on 20111023

IRC log for #brlcad on 20111023

01:52.13*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
06:32.05cvds_hmm more low level command, must try those
IRC log for #brlcad on 20111024

IRC log for #brlcad on 20111024

15:35.27*** join/#brlcad ibot (~ibot@rikers.org)
15:35.27*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
15:49.54CIA-48BRL-CAD: 03n_reed * r47321 10/brlcad/trunk/src/other/step/src/express/express.c: pass null to parser at eof
16:14.35*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
20:31.59CIA-48BRL-CAD: 03n_reed * r47322 10/brlcad/trunk/src/other/step/src/express/expparse.y: Added missing rule assignment. Lemon parser now gives same (error) output as bison parser for all but ap239.
22:46.54*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20111025

IRC log for #brlcad on 20111025

00:30.34starseekergets back and prepares for round two
04:57.39abhi2011hmm, so I am trying to figure out how to calculate the amount of force to be applied while simulating their fall from a height.
04:57.50abhi2011here is the plan at the moment : https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit?hl=en_GB
04:58.07abhi2011so I plan to shoot rays in the overlap region
04:58.39abhi2011and apply forces along the normals
04:59.21abhi2011so for the box in the above figure, all the forces acting on it along the x-axis will cancel each other out
04:59.39abhi2011and only the Z force will remain , pushing it up,
05:00.25abhi2011this would be the case in the real world, with the reaction from the collision acting on the box to make it bounce on the GP(ground plane)
05:02.31abhi2011however if I start summing the normals(encountered while shooting rays) for the box  I end up with something like  4.9999 , 3.9999, 6.00002
05:02.57abhi2011which is not pointing along +ve z as one would expect
05:03.47abhi2011So I will probably, ignore a direction which I have encountered before
05:12.19abhi2011that will I will need to store normals and check every new normal generated , with the previous ones
05:47.37abhi2011instead of investigating the surface of a primitive using rays and shooting rays in a direction opposite to surface normals, I can also apply forces in a direction opposite to the velocity, but that will probably not work in all cases
06:28.42CIA-48BRL-CAD: 03abhi2011 * r47323 10/brlcad/trunk/src/libged/simulate/ (6 files): Formatting corrections
06:46.01*** join/#brlcad sashha (~saschi@77-22-42-58-dynip.superkabel.de)
06:46.06sashhahello
09:57.20*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
11:01.04*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
12:44.34*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
13:32.40*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
15:09.42*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
16:50.27*** join/#brlcad ibot (~ibot@rikers.org)
16:50.27*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
18:11.39*** join/#brlcad ibot (~ibot@rikers.org)
18:11.39*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
18:22.01brlcadhellos sashha
19:01.41*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
19:03.35brlcadabhi2011: no // c++-style comments in .c file ...
19:03.52brlcadbreaks the compilation for others
19:15.16abhi2011oh shoot, I forgot to check that again, sorry about that
20:20.53CIA-48BRL-CAD: 03n_reed * r47324 10/brlcad/trunk/src/other/step/src/express/resolve.c: remove dead code
20:37.24*** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862)
IRC log for #brlcad on 20111026

IRC log for #brlcad on 20111026

00:02.40*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
03:34.37*** join/#brlcad DarkCalf (DC@173.231.40.98)
04:02.33CIA-48BRL-CAD: 03brlcad * r47325 10/brlcad/trunk/ (NEWS src/nirt/interact.c):
04:02.33CIA-48BRL-CAD: add support for carriage returns in addition to newlines since nirt is doing
04:02.33CIA-48BRL-CAD: it's own parsing thing. untested, but should just make windows-style text files
04:02.33CIA-48BRL-CAD: act like they have double newlines (and should make ancient mac-style text files
04:02.33CIA-48BRL-CAD: not look like a long single line). prompted by sf support request #3426854 from
04:02.34CIA-48BRL-CAD: Fred W (NIRT scriptfile) where he assumedly ran into this issue.
04:29.02CIA-48BRL-CAD: 03brlcad * r47326 10/brlcad/trunk/src/tclscripts/lib/Makefile.am: add new Accordian.tcl file to dist
04:30.22CIA-48BRL-CAD: 03brlcad * r47327 10/brlcad/trunk/src/tclscripts/lib/Accordian.tcl: awesome to see this widget get implemented, but it started in 2011. add footer too.
04:44.47brlcadgood luck starseeker  :)
04:52.18*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565147.dsl.bell.ca)
15:49.36*** join/#brlcad ibot (~ibot@rikers.org)
15:49.36*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
15:53.32*** join/#brlcad ibot (~ibot@rikers.org)
15:53.32*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
16:42.31*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
18:40.23*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
21:55.27*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
22:45.56CIA-48BRL-CAD: 03brlcad * r47334 10/brlcad/trunk/NEWS:
22:45.56CIA-48BRL-CAD: bob added radio buttom options to archer for selecting among various lighting
22:45.56CIA-48BRL-CAD: model styles particularly relevant for visualization of BoT models. the modes
22:45.56CIA-48BRL-CAD: allow a user to specify double-sided polygon lighting so that even (incorrect)
22:45.56CIA-48BRL-CAD: back-facing polygons will be visible.
22:52.24brlcadabhi2011: what was that google docs link?
22:53.30abhi2011brlcad: https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit
22:55.53brlcadthx
22:56.00brlcadabhi2011: presume you've read http://www.bulletphysics.org/mediawiki-1.5.8/index.php?title=Collision_Callbacks_and_Triggers yes?
22:57.30abhi2011brlcad: yes I am aware of the callbacks and I use them to calculate the force at the right point, before the simulation step
22:57.52abhi2011they do not however explain what to do , so as to insert contact points correctly in the pipeline
22:57.59brlcadabhi2011: the approach sounds good -- the only part I'm concerned about is whether manually calculating and applying forces yourself is necessary
22:58.14abhi2011it probably is not
22:58.38abhi2011however as a first shot we can try that
22:58.49brlcadapplying forces won't take care of torque or friction .. and definitely no dynamic body behaviors
22:58.59abhi2011meanwhile i havent removed any of the code pertaining to contact points
22:59.11abhi2011yes , torque will be taken care of
22:59.22abhi2011I have to only apply the force at a distance
22:59.32abhi2011there is a API for that which I will use
22:59.48abhi2011applyforce(vector)
23:00.10abhi2011the dynamics part which actually calculates the position of the body is not touched
23:00.27abhi2011that will come into action, after I apply the forces correctly
23:00.33abhi2011so it will still work
23:00.39abhi2011friction is just another force
23:01.07abhi2011I can apply friction by calculating the tangent to the surface which is touching
23:01.27brlcadthat's my point -- YOU have to do all that work
23:01.36brlcadso it'll only be as good as all of the various forces you desribe
23:01.44brlcadthat's not at all optimal...
23:02.49brlcadnot that it's not doable -- it's that it's basically a potential subset of "real" behavior or even a subset of what bullet already calculates when left to it's own computations
23:02.58abhi2011yes
23:03.21brlcadreally sounds like we need to figure out what's up with the callbacks
23:03.36brlcadyou call setCollisionFlags() ?
23:03.40abhi2011yes
23:03.55abhi2011the callbacks allow me to examine the contact points
23:03.59abhi2011but not insert them
23:04.53brlcadI don't see any reference to CF_CUSTOM_MATERIAL_CALLBACK in existing code
23:05.07brlcadthat seemed critical to several examples
23:05.59brlcadhm, I don't see setCollisionFlags() either for that matter..
23:06.05abhi2011yes, as when I last checked that, it was to set a custom friction specific to the material
23:06.06brlcadwhere is it being called?
23:06.27abhi2011yes I had tried that, it is used in run_physics()
23:06.35abhi2011*it was used there
23:07.12abhi2011I used to set the collision flags, such that objects dont collide with each other at all
23:07.22abhi2011and then apply forces
23:07.35brlcadthe behavior you described earlier where you generated the contact manifolds, but they simply didn't cause a contact response really sounds related to the collision flags
23:08.01brlcadas that looks to be how bullet controls which callbacks are even called, which are used, and how updates are performed
23:08.07abhi2011well collision flags are to filter out collisions between objects
23:08.16abhi2011so if I want 2 objects to not collide
23:08.24abhi2011then I will set differnt flags for themm
23:08.36abhi2011thats what the examples do
23:08.57abhi2011yes, during collision detection the flags are ANDed
23:09.23abhi2011and if the result is false then for those 2 objectcs, there is no collision detection carried out
23:09.29abhi2011that is what the collision flags are for
23:09.45abhi2011they do not directly control the contact points
23:09.46brlcadANDed?  that'll zero it out unless it was already set
23:10.05brlcadORd would be for setting a flag
23:10.14abhi2011no by default bullet sets them all to one for all objects
23:10.27abhi2011so all objects collide with each other
23:10.40brlcadblinks
23:11.03brlcadthe "flags" represent more than just whether two objects collide
23:11.06brlcadthat's just one of the flags
23:11.37``Erik'!' != '~'
23:11.43brlcadbitwise
23:11.51brlcad| .. not &
23:12.11brlcadif you were using &, that would explain a lot
23:12.45brlcadthe wiki docs have several examples where the flags are or'd
23:12.56brlcadrefers to http://www.bulletphysics.org/mediawiki-1.5.8/index.php?title=Collision_Callbacks_and_Triggers
23:13.45``Eriksimpsons do mad men: http://www.youtube.com/watch?v=KcmM7Jh2Y3k
23:14.46abhi2011yes but I do get use the contact callbacks, and they do get called when points are added or processed
23:15.25abhi2011I get those callbacks even if I do not set mBody->setCollisionFlags(mBody->getCollisionFlags() |    btCollisionObject::CF_CUSTOM_MATERIAL_CALLBACK);
23:16.08abhi2011whenever 2 boxes overlap for example and I insert points using my own algorithm, then the contact added/contact processed callbacks etc are called
23:16.30abhi2011thse callbacks are not the places where the contact points themselves are inserted
23:16.46brlcadabhi2011: sure, but if the right flags aren't set/unset, then the values might not get used (at all or correctly)
23:17.04abhi2011thats is true
23:17.05brlcadwhat you described is that you added a bunch of contact points but they weren't getting used, right?
23:17.11abhi2011yes
23:17.24brlcadthat points almost directly at a statefulness problem
23:17.35brlcadwhich would be those silly flags
23:18.03brlcadyou could try printing out the flags for the example code that works and the flags for your code, see how they differ
23:18.07abhi2011thats is of course possible and I will try with that, however if that were the case, then bullet would not send me a contacts processed callback with the points that I inserted,
23:18.36abhi2011yes I will try with the flags once more
23:18.51brlcadright, but one of the flags seemed to be a flag that toggled whether it needed to do anything
23:19.13brlcadif that flag was unset, it'd still make all the callbacks but not perform any collision response
23:19.23abhi2011yes that is possible
23:19.32brlcadshould hunt down the documentation on what all the flags are and what they do
23:19.51abhi2011ok, yes I will have a more careful look at the flags
23:21.47brlcadcool
23:23.59``Erikbrlcad: any experience with apache mod_proxy ?
23:24.37``Erik(I wanna futz with your server, but want second eyes before pulling the trigger)
23:26.23brlcad``Erik: nope
23:27.16``Erik'k, I'll RCS up files before mods, I guess
23:27.34``Erik(can all those bazillion *~ files in the httpd conf dir be shot?)
23:29.39CIA-48BRL-CAD: 03abhi2011 * r47335 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simrt.c simulate.c): Putting up the code which uses only forces to stabilize objects, so I can refer to this later
23:32.15brlcadthose ~ files are backup reference
23:34.16``Erikdang emacs shenanigans O.o git init && git add -a . && git commit -m 'init'
23:36.02brlcadmeh
23:36.45brlcadmy method requires zero-effort and has been sufficient for decades :P
23:40.25``Erikprovided only emacs users admin it and only one level of mistake is made... :D
23:46.25*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
IRC log for #brlcad on 20111027

IRC log for #brlcad on 20111027

00:18.24*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
01:22.10*** join/#brlcad yottabit (~heath@unaffiliated/ybit)
01:22.14*** part/#brlcad yottabit (~heath@unaffiliated/ybit)
01:35.55brlcadlike I said, zero-effort and has sufficient for decades :)
04:06.18brlcadgets through most of the trackers for the night
07:05.54*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
09:29.51*** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
09:33.35*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
10:34.08jordisayolbrlcad: I mistakenly closed "mged crash on startup - ID: 3341960" report. If you can reopen it please? sorry for that
11:07.24brlcadsure, np
11:33.49*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
12:58.54d_rossbergis there any template for writing a function to copy a nmg model?
13:25.07*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:27.42*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
14:41.48brlcadd_rossberg: there is nmg_dup_shell() in src/librt/primitives/nmg/nmg_misc.c
14:43.05brlcadit's not used anywhere so you may want to verify that it actually/still works, but it could be moved to an nmg_dup.c file and made into new public api if you need something like that
14:44.08brlcadotherwise, you could do what the 'clone' command does calling export on the nmg to create a copy
14:46.18brlcadi.e., rt_get_internal()+db_lookup() -> rt_put_internal() to an in-mem should do the trick
14:46.38brlcadnmg_dup_shell() is probably a better way, though :)
15:23.39d_rossbergthanks, as far as i can see nmg_dup_shell() is used in nmg_hollow_shell() (nmg_extrude.c) but it seems to be a good reference
15:47.40CIA-48BRL-CAD: 03n_reed * r47336 10/brlcad/trunk/src/other/step/src/express/expparse.y: have lemon print message on stack overflow
15:48.45CIA-48BRL-CAD: 03n_reed * r47337 10/brlcad/trunk/src/other/step/src/express/lexact.c: set dangling pointers to null
16:07.27*** join/#brlcad ibot (~ibot@rikers.org)
16:07.27*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
16:42.30CIA-48BRL-CAD: 03n_reed * r47338 10/brlcad/trunk/src/other/step/src/express/error.c: s/malloc/calloc
16:55.48CIA-48BRL-CAD: 03bob1961 * r47339 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Modified libtclcad/tclcad_obj.c/go_draw() to use ged_mike_persp_mat. This works better when drawing things in shaded mode.
17:42.24*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
20:14.27starseekergrowls - alright, why is archer suddenly not showing raytracing?
20:14.57starseekerfriggin external projectors... messed with my graphical setup good, apparently
20:23.08brlcadstarseeker: another nice metric from today..  got a clean build on a 20-proc debian box
20:23.29brlcadnot tried a debian build in several months, so good to see that's still working out of the box
20:24.00brlcadbut more cool, the cmake  build took about 1min 20sec vs about 3min for autotools :)
20:24.48starseekerhah - sweet!
20:25.43starseeker(that's a big Debian machine)
20:25.48brlcadof course, I'm assuming the builds were near parity, but neat nonetheless
20:26.36starseekernods - should be pretty close now... is the step stuff still turned on in autotools?
20:27.44starseekerbrlcad: is archer's raytracing working for you?  (I think it's me, but a second datapoint would be nice)
20:39.04brlcadstarseeker: works fine for me
20:39.17starseekercool
20:39.20starseeker(phew)
20:39.21brlcadother than an hv3 error
20:39.22brlcadError in -requestcmd home://blank/css/brlcad.css: wrong # args: should be "::hv3::request::inst1 m ..."
20:39.27brlcadduring startup
20:39.38starseekerblinks - that should be gone in the latest trunk
20:59.53brlcadwas a latest trunk build
21:16.58*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:29.58*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
IRC log for #brlcad on 20111028

IRC log for #brlcad on 20111028

01:19.21starseekergrr
01:19.28starseekernot seeing that here
03:01.33CIA-48BRL-CAD: 03brlcad * r47340 10/brlcad/trunk/NEWS:
03:01.34CIA-48BRL-CAD: (reword) erik added a new 'ringworld' procedural geometry generator tool that
03:01.34CIA-48BRL-CAD: creates the Ringworld described in the 1970's novel by Larry Niven. next
03:01.34CIA-48BRL-CAD: release is expected to be a minor bump with the various major features.
03:04.21CIA-48BRL-CAD: 03brlcad * r47341 10/brlcad/trunk/ (NEWS include/conf/PATCH include/rt/): finally beginning final release steps for release 7.20.4, only three releases late. bump patch to release rev.
03:15.16CIA-48BRL-CAD: 03brlcad * r47342 10/brlcad/trunk/ChangeLog: update changelog for 7.20.4 release with entries since the previous release.
03:43.16*** join/#brlcad ibot (~ibot@rikers.org)
03:43.17*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
03:54.13*** join/#brlcad ibot (~ibot@rikers.org)
03:54.13*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
04:16.35*** join/#brlcad ibot (~ibot@rikers.org)
04:16.35*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
04:22.32*** join/#brlcad ibot (~ibot@rikers.org)
04:22.32*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
04:46.48*** join/#brlcad ibot (~ibot@rikers.org)
04:46.48*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
04:47.17*** join/#brlcad ibot (~ibot@rikers.org)
04:47.17*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
04:47.49*** join/#brlcad ibot (~ibot@rikers.org)
04:47.49*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
04:48.39*** join/#brlcad ibot (~ibot@rikers.org)
04:48.39*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
04:49.02*** join/#brlcad ibot (~ibot@rikers.org)
04:49.02*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
04:49.36*** join/#brlcad ibot (~ibot@rikers.org)
04:49.36*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
04:50.10*** join/#brlcad ibot (~ibot@rikers.org)
04:50.10*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
04:50.28*** join/#brlcad ibot (~ibot@rikers.org)
04:50.28*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
04:51.31*** join/#brlcad ibot (~ibot@rikers.org)
04:51.31*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
04:57.58*** join/#brlcad ibot (~ibot@rikers.org)
04:57.58*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
05:28.04*** join/#brlcad ibot (~ibot@rikers.org)
05:28.04*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
05:29.45*** join/#brlcad ibot (~ibot@rikers.org)
05:29.45*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
05:54.52*** join/#brlcad ibot (~ibot@rikers.org)
05:54.52*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
06:01.46*** join/#brlcad ibot (~ibot@rikers.org)
06:01.46*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
06:06.20*** join/#brlcad ibot (~ibot@rikers.org)
06:06.20*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
06:12.34*** join/#brlcad ibot (~ibot@rikers.org)
06:12.34*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
06:14.23*** join/#brlcad ibot (~ibot@rikers.org)
06:14.23*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
06:21.45*** join/#brlcad ibot (~ibot@rikers.org)
06:21.45*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
06:29.41*** join/#brlcad ibot (~ibot@rikers.org)
06:29.41*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
06:43.59*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:00.30CIA-48BRL-CAD: 03Phentermine 07http://brlcad.org * r3187 10/wiki/Main_Page:
08:14.56CIA-48BRL-CAD: 03Sean 07http://brlcad.org * r3188 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Phentermine|Phentermine]] ([[User talk:Phentermine|Talk]]); changed back to last version by [[User:Starseeker|Starseeker]]
08:15.15CIA-48BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Phentermine]] with an expiry time of infinite (account creation disabled, e-mail blocked): Inserting nonsense/gibberish into pages
08:19.35CIA-48BRL-CAD: 03brlcad * r47343 10/brlcad/branches/STABLE/ (12433 files in 654 dirs): merging trunk to STABLE from r45378 to HEAD r47342 for release 7.20.4
08:49.25CIA-48BRL-CAD: 03brlcad * r47344 10/brlcad/branches/STABLE/ (README src/libged/erase.c): changes from trunk slipped through merging somehow. sync.
09:12.51CIA-48BRL-CAD: 03brlcad * r47345 10/brlcad/tags/rel-7-20-4/: finally tagging release 7.20.4
09:20.12CIA-48BRL-CAD: 03brlcad * r47346 10/brlcad/trunk/ (NEWS README include/conf/MINOR include/conf/PATCH): bump to 7.21.0 after tagging the 7.20.4 release in anticipation of a big upcoming 7.22.0 release
09:20.32brlcadtagged and bumped, but not posted .. will do that in a bit later, must take a lil break
09:47.15*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
12:31.11``Erikcool, does server migration fit in after?
13:48.27*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:01.40starseekerhmm - this looks interesting
15:01.43starseekerhttps://github.com/antirez/linenoise
15:03.36starseekeror actually probably would want the jimtcl version, per tcl channel:
15:03.40starseekerhttps://github.com/msteveb/jimtcl/blob/master/linenoise.c
15:03.54starseekerhttps://github.com/msteveb/jimtcl/blob/master/linenoise.h
15:06.04brlcadah, another one saying "I can do that in fewer lines of code"
15:06.23brlcadat which point they are fewer lines by eliminating various features they don't care about :)
15:17.02starseekerheh - true
15:17.18starseekercan be handy though if they're also features we don't care about
15:18.01starseekerwonders if the new coroutines in 8.6 might be of interest for our gui stuff...
15:22.49starseekerwonders if we're using tkcon or something else for our terminals...
15:24.24starseekeralways the problem with attending conferences - I get a whole lot of hairbrained ideas I'd like to go try out...
15:26.10CIA-48BRL-CAD: 03brlcad * r47347 10/brlcad/trunk/src/libbu/test_htond.c: remove commented out bulk conversion line
16:09.32brlcadstarseeker: that's not a problem, that's one of the main points!
17:16.02``Erikstarseeker: are you back from the tcl conf?
17:27.22CIA-48BRL-CAD: 03n_reed * r47348 10/brlcad/trunk/src/other/step/src/express/express.c: add declarations for lemon functions
18:37.20CIA-48BRL-CAD: 03n_reed * r47349 10/brlcad/trunk/src/other/step/src/express/expparse.y: s/int/YYSTYPE for yylval. Incorrect type was causing memory corruption.
18:57.23*** join/#brlcad abhi2011 (~chatzilla@117.200.81.138)
22:50.54*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:14.42brlcaddarn, tagged cmake build failed, autotools succeeded
23:15.03brlcad[ 11%] Building C object src/other/tk/CMakeFiles/tk.dir/unix/tkUnixRFont.c.o
23:15.04brlcadIn file included from /Users/morrison/brlcad-7.20.4/src/other/tk/unix/tkUnixRFont.c:16:
23:15.06brlcad/usr/include/X11/Xft/Xft.h:41:35: error: fontconfig/fontconfig.h: No such file or directory
23:15.09brlcadIn file included from /usr/include/X11/Xft/Xft.h:51, from /Users/morrison/brlcad-7.20.4/src/other/tk/unix/tkUnixRFont.c:16:
23:15.12brlcad/usr/include/X11/Xft/XftCompat.h:31: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?XftChar8?
23:15.15brlcad...
IRC log for #brlcad on 20111029

IRC log for #brlcad on 20111029

02:38.43starseekerO.o
02:38.49starseekerwhat platform?
02:39.03starseekeris assuming mac with that path structure...
02:39.26starseekerdo you have fontconfig.h anywhere?
02:40.01starseeker``Erik: technically back, will be in Monday
02:48.37starseekerwishes in some ways Archer had gone with snit instead of incrTcl... oh well
02:52.49starseekercurrently has the urge to rewrite Archer using the tktreectrl widget, snit and tkconv + whatever parts of tcl3d work reliably cross platform, but will recover by Monday :-P
02:53.12starseekers/tkconv/tkcon
02:57.00starseekeraaaand my OSX build of trunk just succeeded
02:57.03starseeker(crud)
06:55.20*** join/#brlcad abhi2011 (75c854c8@gateway/web/freenode/ip.117.200.84.200)
09:29.10*** join/#brlcad abhi2011 (75c85104@gateway/web/freenode/ip.117.200.81.4)
10:38.29*** join/#brlcad abhi2011 (~chatzilla@117.200.89.171)
11:02.27*** join/#brlcad abhi2011 (~chatzilla@117.200.80.242)
11:03.52abhi2011yet I know that SSL does work , as I am able to access sites like gmail etc
11:13.41*** join/#brlcad abhi2011 (~chatzilla@117.200.92.212)
11:32.07CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3189 10/wiki/User:Abhijit: /* Log */
11:57.42*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
12:07.07*** join/#brlcad abhi2011 (~chatzilla@117.200.84.101)
13:21.28brlcadstarseeker: yes mac, and fontconfig.h is in /usr/X11/include/fontconfig/fontconfig.h
13:22.06brlcadmy trunk build succeeded, this was a checkout of the tagged 7.20.4
13:23.54brlcadpossible that something somewhere didn't merge due to a variety of custom non-merge edits that went into the STABLE branch
14:41.21*** join/#brlcad abhi2011 (~chatzilla@117.200.80.102)
16:33.44abhi2011ok finally got a reply from Erwin
16:34.26abhi2011he says the contact depths have to be negative to show that an object is penetrating another, which I have tried already of course
16:34.50abhi2011I ll try with a simpler case of sphere-sphere collision and see what happens
16:55.29brlcadhuh, freshmeat just changed their name to freecode
17:26.58CIA-48BRL-CAD: 03brlcad * r47350 10/brlcad/trunk/src/libged/edit.c: quell mac strict compilation warnings, not liking the excessive constness casting. update ws/indent too.
17:29.06CIA-48BRL-CAD: 03brlcad * r47351 10/brlcad/tags/rel-7-20-4/src/libged/edit.c: apply strict compilation warning fix that slipped through testing since tarball hasn't yet been posted.
18:36.21brlcaddid a comparison of the flags used by autotools and the flags being used by cmake for the tk build and it's impressive that it works given all of the differences... slew of differences on the comand line declarations being used
18:37.44brlcadone of which being the cause of the compile failure, different sets of include paths being used, it's missing /usr/X11/include
18:44.19brlcadhttp://brlcad.org/tmp/cmake_fail.patch
18:44.43brlcadthat's the diff of the same file being compiled by autotools and cmake
18:45.22brlcadadds a slew, omits a few, changes a few others, and same with includes
18:50.35brlcadshould attempt to minimize/elimiate most of those differences .. each one is potentially an obscure bug that can cause differences and problems down the road (like now)
19:19.54brlcadthis is very annoying.. i've removed all references to X11R6 from all our cmake files, yet it keeps finding and using it
19:23.10brlcad(and yes, cache files and such all deleted
19:56.30brlcadstarseeker: you're going to have to teach me what I'm doing wrong sometime next week, because I've been fighting cmake all day now trying to add a basic cppflag and it's still not working...
19:57.37brlcadfinally got it working by forcibly setting CMAKE_C_FLAGS, but there has to be a better way
20:38.35CIA-48BRL-CAD: 03brlcad * r47352 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt Makefile.am): ElNode.pm and read-db-xml.pl are missing from dist, add them
20:43.27CIA-48BRL-CAD: 03brlcad * r47353 10/brlcad/tags/rel-7-20-4/: too many problems slipped through distcheck, including files missing from dist and a default cmake fail on mac 10.6. need to resync to STABLE and retag.
20:45.15CIA-48BRL-CAD: 03brlcad * r47354 10/brlcad/trunk/NEWS: need to retag, update release date
21:00.30CIA-48BRL-CAD: 03brlcad * r47355 10/brlcad/trunk/misc/CMake/FindX11.cmake:
21:00.30CIA-48BRL-CAD: assuming the X11 include and lib search paths are in some sort of reverse
21:00.30CIA-48BRL-CAD: priority order, sort them to help ensure system dirs take precedence over legacy
21:00.30CIA-48BRL-CAD: package system dirs (except for /usr/local). make sure /usr/X11 comes 'before'
21:00.30CIA-48BRL-CAD: (i.e., after due to reverse priority order?) the previous /usr/X11R6 convention.
21:00.31CIA-48BRL-CAD: eliminate trailing ws waste too.
21:10.06CIA-48BRL-CAD: 03brlcad * r47356 10/brlcad/trunk/misc/CMake/FindX11.cmake: having trouble believing the paths are really searched in reverse order, so reverse/revert the ordering. give 64-bit precedence.
21:11.13CIA-48BRL-CAD: 03brlcad * r47357 10/brlcad/trunk/misc/CMake/FindGL.cmake: more X11 hard-coded path craziness. reorder and eliminate unnecessary trailing ws.
21:15.20CIA-48BRL-CAD: 03brlcad * r47358 10/brlcad/trunk/src/other/ (6 files in 6 dirs): update the cmake copies (might make sense to make them use an svn:external so there is only one copy)
21:33.43CIA-48BRL-CAD: 03brlcad * r47359 10/brlcad/trunk/src/other/step/include/: ignore scl_cf.h.in since autoheader will create it during autogen.sh
22:19.07CIA-48BRL-CAD: 03brlcad * r47360 10/brlcad/trunk/src/util/pixclump.c: gcc 4.3.2 is curiously reporting that cte is exceeding the array bounds, but seems fine if we avoid the unsigned char pointer. possibly a bug or possibly valid detection of same bad pointer juju. either way, quelled.
23:55.50*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
IRC log for #brlcad on 20111030

IRC log for #brlcad on 20111030

01:25.22*** join/#brlcad abhi2011 (~chatzilla@117.200.81.140)
01:40.48brlcadapparently cmake has some parallel build race condition bug too... ended up compiling one file to a 0-length .o file, linking it in and naturally then resulting in undefined symbols
01:50.03CIA-48BRL-CAD: 03brlcad * r47361 10/brlcad/trunk/src/conv/g-vrml.c: remove dead code, #if 0
01:50.59CIA-48BRL-CAD: 03brlcad * r47362 10/brlcad/trunk/src/conv/g-x3d.c: restructure bu exception handling into try/catch form, make 'reg' also be static in order to avoid gcc longjmp clobbering
02:01.47CIA-48BRL-CAD: 03brlcad * r47363 10/brlcad/trunk/src/conv/intaval/regtab.h: quell warning about being unable to inline this constructor. move the init of desc over with the others.
02:02.59CIA-48BRL-CAD: 03brlcad * r47364 10/brlcad/trunk/src/conv/ (36 files in 10 dirs): ws
03:15.10starseekerO.o
03:15.17starseekerhas never encountered that...
04:04.35*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
04:07.59*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
04:54.53*** join/#brlcad abhi2011 (~chatzilla@117.200.84.208)
06:16.33abhi2011hmm , the contact point approach works with the simple case of sphere-sphere collision
06:16.42abhi2011forces are getting applied now
06:16.55abhi2011lets see whats the issue with box shapes then
07:08.17CIA-48BRL-CAD: 03Abhi2011 07http://brlcad.org * r3190 10/wiki/User:Abhijit: /* Log */
08:07.39*** join/#brlcad forth (~10497E4F9@92.242.118.253)
09:55.16*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
11:37.11*** join/#brlcad CIA-109 (~CIA@cia.atheme.org)
12:22.44*** join/#brlcad abhi2011 (~chatzilla@117.200.80.21)
12:46.07*** join/#brlcad abhi2011 (~chatzilla@117.200.83.165)
14:01.10CIA-109BRL-CAD: 03brlcad * r47365 10/brlcad/trunk/include/rt/defines.h: not yet used, but add the start of a common definitions file for librt just so this directory isn't empty
14:02.38abhi2011ok now the box-box collision also works
14:02.46abhi2011with contact pairs
14:02.54abhi2011will try to roll a sphere on a plane
14:03.33CIA-109BRL-CAD: 03brlcad * r47366 10/brlcad/trunk/include/ (CMakeLists.txt Makefile.am): add the new rt/defines.h header for install/dist
14:07.48brlcadabhi2011: so have you figured out what the problem was?
14:08.10brlcadtoo many contact points?
14:08.18brlcadwrong vector direction?
14:08.21abhi2011yes, the problem seems to lie on the direction of the normals
14:08.35brlcadthat'd 'splain it ;)
14:08.37abhi2011which have to point from what ever object that bullet considers as object B
14:08.46abhi2011to whichever points towards object A
14:09.27abhi2011yes, I think I can try to roll a sphere now and see if I can generate contact points when its touching the ground
14:09.47brlcadawesome
14:09.55abhi2011I have to use the curvature information of the sphere though, to ensure I dont generate more than 1 contact point
14:10.16abhi2011as more than 1 point separated by a non zero distance would prevent its roll
14:10.18abhi2011:)
14:10.34abhi2011so some logic has to figured out there to work on all cases
14:11.08brlcadafter that, a great test case for the ray casting would be to roll an ellipsoid down a bit bowl
14:11.21abhi2011a bit bowl ?
14:11.24abhi2011what does the bit mean
14:11.44brlcada *big* bowl
14:11.53abhi2011ah ok
14:11.55abhi2011:P
14:11.58brlcadyeah :)
14:12.03abhi2011yes
14:12.11brlcada big concave dish
14:12.17abhi2011yes, the thing that I have to think about though is
14:12.33abhi2011that i can only generate contact points when objects interpenetrate
14:13.05abhi2011which can cause the motion to be bumpy as an ellipsoid rolls along a bowl surface for example
14:13.34brlcadsure, maybe
14:13.52brlcadbut if that can be reduced with more sampling points, that might just work fine
14:14.08abhi2011maybe i can reduce the bumpiness to un-noticeable  extents
14:14.13brlcadright
14:14.16abhi2011ok
14:14.58brlcadby the way, there are lots of folks really excited about your work :)
14:15.18brlcadyour quick youtube demo made the rounds amongst many of the expert modelers
14:15.40brlcadthey loved it! .. of course wanting to try it right away
14:15.48brlcadtold them they'll have to wait a bit still :)
14:17.26abhi2011hehe, yes I am on it for sure, should have something by tomorrow hopefully :)
14:17.54brlcadwell, I told them at least a month, so no worries :)
14:18.03abhi2011and dont worry I ll keep working on it inspite of socis completing
14:18.10abhi2011as i had promised :)
14:18.27brlcadthat's great news ;)
14:18.33brlcadthis is really going to be big
14:19.42abhi2011cool, I am actually plannning to add this to Bullet also , so that it supports irregular objects, since the raytracing is done within the small overlap region and can be parallelized, it may be near real time
14:31.08brlcadthat'd probably make a huge impact in their flexibility
14:31.46brlcadeven for polygonal shapes, our ray engine can shoot a mesh prety darn fast
14:32.33brlcadstarseeker: CPack Error: Cannot create symlink: .cmake/share/brlcad/7.20.3/html/presentations/en/images/tk-based-gui-for-mged.png--> /home/sean/brlcad/doc/docbook/presentations/en/images/tk-based-gui-for-mged.png
14:56.50*** join/#brlcad abhi2011 (~chatzilla@117.200.83.165)
15:25.44*** join/#brlcad abhi2011 (~chatzilla@117.200.87.86)
15:27.14CIA-109BRL-CAD: 03brlcad * r47367 10/brlcad/trunk/NEWS: getting much closer, should be today if this last pass succeeds
15:31.45CIA-109BRL-CAD: 03brlcad * r47368 10/brlcad/branches/STABLE/ (57 files in 26 dirs): again merging trunk to STABLE from r47343 to HEAD r47367, in prep for retagging release 7.20.4
15:51.00CIA-109BRL-CAD: 03brlcad * r47369 10/brlcad/trunk/doc/docbook/Makefile.am: update CatalogManager.properties file for autotools dist, in builddir, not srcdir
16:02.20CIA-109BRL-CAD: 03brlcad * r47370 10/brlcad/branches/STABLE/doc/docbook/Makefile.am: merging trunk to STABLE from r47367 to HEAD r47369
18:00.51*** join/#brlcad abhi2011 (~chatzilla@117.200.80.50)
19:29.54brlcadfinishes implementing support for our whitespace indentation standard into astyle
19:30.23brlcadcrappy indentation of continuations, though .. wonder if there's a way to fix that
19:47.06brlcadfinishes what is hopefully the last distcheck for retag
21:17.11starseekererm... is that CPack error consistent?
21:17.53starseekerastyle... cool!
21:18.27starseekerhopes he will accept the patch
21:20.30starseekerwonders why he does not see these CMake errors...
21:45.12cvds_!seen rkoeppl_printing
21:45.23cvds_sorry wrong windos
23:54.12*** join/#brlcad bhinesley (~bhinesley@adsl-99-52-241-103.dsl.bkfd14.sbcglobal.net)
IRC log for #brlcad on 20111031

IRC log for #brlcad on 20111031

02:09.21brlcadstarseeker: if you always do a build the exact same way every time, nothing is likely going to ever change
02:09.27brlcads/change/fail/
02:09.45brlcadbut then that's not very flexible either, akin to coding with blinders on
02:51.16*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
03:07.47starseekerwill be curious what you did differently...
03:08.22jordisayolhello
03:09.13starseekerhowdy
03:09.25jordisayolwhen will be the 7.20.4 release out?
03:09.45starseekerwithin a couple days would be my guess
03:10.01jordisayolaha, thanks!
03:22.58brlcadstarseeker: I've long since moved on with all of the other release testing
03:23.02brlcadjordisayol: within a couple hours
03:23.15brlcadlast round of distchecking now
03:23.30jordisayolgood!
03:23.34starseekerbrlcad: ah - was figuring there was busted CMake stuff I would have to look at...
03:23.48brlcadstarseeker: fyi, I seem to consistently run into that fontconfig failure on 10.6
03:24.11brlcadsomething wrong with the X11 search logic
03:24.28starseekerk.
03:24.42starseekerwill see if a test machine is available
03:25.11brlcadit ends up not searching in /usr/X11/include where fontconfig/fontconfig.h lives, no -I/usr/X11/include on the compile line either
03:25.21starseekergrowls
03:25.31starseekerwhy did trunk succeed and stable fail?
03:25.50starseekeror was that a separate issue?
03:26.02brlcadcuriously, through all my mods of misc/CMake/FindX11.cmake, it didn't even seem to be using that macro/file
03:26.19starseekernods - it probably was using one of the src/other copies
03:26.22brlcadseparate issue I think
03:26.27brlcadI updated all the src/other copies too
03:26.42brlcad(can see in the commit history)
03:26.46starseekerthat's one of the drawbacks of doing src/other configures before ours - we get their Find*.cmake files running first
03:26.53starseekerk
03:27.42starseekerall the more reason to try and get maintainership of the ones we care about in CMake
03:27.44brlcadin fact, curiously -- it's finding /usr/X11R6 during cmake .. and I removed ALL of our cmake file references to /usr/X11R6 and it still found/used it
03:27.53starseekerO.o
03:28.24starseekerdarn Mac anyway...
03:29.13starseekerneeds to make another try at Aqua support... heck with X11 on Mac...
03:29.17brlcadthe mac X11 dirs are actually set up very sane on 10.6
03:29.46brlcadautotools passes no problem, something is wrong in the logic
03:29.55starseekernods
03:29.59starseekerI believe it
03:30.12starseekerI'll try to take a look tomorrow
03:31.31brlcadas it's the last remaining release issue, I'm going to tag the release with that issue unresolved so some users might get bitten
03:31.53starseekernods - yeah, CMake isn't "official" yet so I'd say go
03:32.27starseekerdoes X11R6 *exist* on your Mac?
03:32.50brlcadyes, it is a symlink to X11
03:33.09starseekerhmm
03:33.38starseekerand yet -I/usr/X11R6/include doesn't work for fontconfig.h?
03:33.58brlcadsure that'd work, but it's not on the compile line
03:34.08starseekerconfound it
03:34.32starseekeralright, I'll have to debug it
03:34.55brlcadthat's why I started trying to just debug the find macro, but couldn't seem to get it to do anything useful
03:35.04brlcadspent a day working on various angles
03:35.12starseekerwinces - sorry about that
03:35.18brlcadnot you, cmake just was not cooperating
03:35.20starseekerwas rather fried after the last week
03:35.59starseekerhas done various surgeries on the FindX11.cmake file to try and account for one issue or another, may have really messed it up somehow
03:36.33brlcaduncovered a rather extensive bit of scary differences on the tk command line...
03:36.46starseekersnorts - not surprised, actually
03:37.02starseekerI was trying to get it working, not shooting for command line parity
03:37.07brlcadi'm almost surprised that tk even works...
03:37.11brlcadhttp://brlcad.org/tmp/cmake_fail.patch
03:37.32brlcaddon't show the tk guys that :)
03:38.06starseekeroh, I doubt they'll care either way - when I talked to Andreas, he didn't sound especially interested in changing the existing system
03:38.23starseeker(unfortunately, he was making Tcl/Tk usb drives and didn't see my talk :-(
03:39.15brlcadpackage name isn't right, features off that should be on, features on that should be off, worrisome threading settings, incorrect symbol import/export settings, .. :)
03:40.21brlcadsubtleties for sure, but definitely enough "cause for concern" if/when tk ever crashes or has odd behavior
03:40.55brlcadfirst thing I'd want to do if we ran into a serious bug is try again with stock tk
03:41.06brlcad(or get closer to parity)
03:41.07starseekernods - I pretty much reached burn-out trying to unwind their existing build settings
03:41.45starseekerthat stupid thing they have to do with putting all their settings on the command line instead of a config.h file made it tough
03:42.05brlcadI would have thought that makes things easier
03:42.49brlcadalways have the command line, and then "sometimes" compile_line+some_unknown_number_of_files_with_magical_#defines
03:43.03brlcadthat just eliminates the latter, one list to worry about matching
03:43.10starseekerprefers diffing the resulting config.h files between old and new builds
03:43.28brlcadbut then even the compile flags don't match
03:44.31brlcadI *think* they're all benign, but not sure
03:44.37brlcadespecially about __attribute__\(\(__visibility__\(\"hidden\"\)\)\)
03:44.48starseekerdidn't know what to make of that one
03:45.23starseekerit was bad enough trying to figure out all the tests for the stuff I *knew* I needed - pretty much if it wasn't clearly essential it got ignored
03:45.47starseekerremember the original effort was a side issue, a distraction from BRL-CAD itself
03:46.21brlcada distraction to you perhaps :)
03:46.30brlcadto me, it's all part of the effort
03:46.43starseeker<snort> I was worried about being called to the carpet as it was
03:46.43brlcadif it's worth doing at all ...
03:46.49brlcadknows
03:47.11brlcadit's fine, it obviously works fairly well enough as it is
03:48.01starseekeroh, I agree it's worth doing right - maybe it's a side-effect of the conference, but I do think Tcl/Tk is a nice combination of features, license and small size compared to it's feature-set
03:48.12brlcadthere are just so many rough edges that there are going to be numerous long-term maintenance and debugging costs, obscure errors down the road that take forever to dig into
03:48.36starseekerunfortunately, my compiling foo is relatively weak compared to the complexities of the build
03:49.30starseekerhalf the time I didn't know if a particular flag was a hold-over from ancient history I could ignore
03:49.52starseekeror a flag I would need on some platform other than the current one
03:50.51starseekerthat __attribute__ flag being one case in point
03:51.07brlcadthat's gcc linker hinting
03:52.38brlcada quick google search would have answered that one :P
03:52.45brlcadmost of them, really
03:53.27brlcadhttp://gcc.gnu.org/wiki/Visibility
03:53.28starseekermaybe *what* they were, but not whether they actually mattered for thing things we care about
03:53.55brlcadbasically, it's gcc's way to hide a symbol that needs to be extern but you don't want to be public api
03:54.09brlcadvery similar to dll_import/dll_export in msvc
03:54.16starseekerretches
03:54.28starseekerthat has caused more grief...
03:55.15brlcadto whom?  pretty straightforward linking concepts (and not unique to msvc)
03:55.38brlcadmost compilers have the notion, some are through much more archane methods like explicit lists of symbols in text files
03:56.04brlcadgcc was actually a bit late to the game, but most commercial compilers have that feature
03:58.23starseekernods - OK, looking over this article I can see why it might be useful in some situations...
03:58.27brlcadit lets you write a function "secret_special_sauce()" used by public API in several places, say rt_brilliant() and rt_awesome(), but not actually have to expose that function in the library
03:59.10starseekerdo we use such a mechanism?  I don't recall seeing it in our own build logic...
03:59.41brlcadwe do not, it takes a little bit of API awareness and best practice to keep things clean
03:59.53brlcadlibged is a prime example, though ..
04:00.28brlcadlots of functions bob keeps adding that need to be reusable within the library .. but make for HORRIBLE public api functions, completely inconsistent with the rest of the ged api
04:01.09brlcadbeen resorting to simple naming conventions to at least remove the ged_ prefix, helps
04:01.39brlcadbut then they still need to be declared in ged's private header, not ged.h
04:01.46brlcadand that takes awareness, restraint, etc
04:02.01starseekernods
04:02.21brlcadyay, final builds completed
04:02.45starseekerif I ever feel like tinkering with our build system again, sit on me 'til the urge passes
04:02.50brlcadcept cmake of course,
04:03.43brlcaddoing something I probably shouldn't .. comparing the two distfiles from cmake and autotools
04:03.44starseekerwill look into that tomorrow if he can get access to a 10.6 system
04:04.10brlcadI can post any files you think might help
04:04.12starseekerI believe there is at least one step that autotools has that I haven't put in CMake
04:04.31starseekerbrlcad: I need to do some configure-time debugging, to check what is and isn't being set at various steps
04:04.44starseekerbasically a bunch if MESSAGE calls at various points in the file
04:04.50starseekers/if/of
04:05.13starseekerbrlcad: your CMakeCache.txt file might be informative
04:06.25brlcadhttp://brlcad.org/tmp/cmake_build_fail.txt and http://brlcad.org/tmp/CMakeCache.txt
04:06.26starseekeris disturbed that editing the FindX11.cmake files didn't do squat - did you erase your CMakeCache.txt file between each CMake run? (or at least clear out the X variables in it?)
04:06.48brlcadyep, started out just wiping out the cache
04:07.04brlcadthen was eventually blowing away the whole dir, trying to get some changes
04:08.00brlcadbuild dir out of src dir only, parallel
04:08.11starseekerhmm - is there a /usr/include/X11 dir?
04:09.35starseekeris wondering why there seems to be both a /usr/X11/include and a /usr/include/X11 - one one a symlink to the other?
04:09.43brlcadthere is a /usr/include/X11 symlink to /usr/X11/include/X11
04:10.03starseekerand fontconfig.h is where?
04:10.16brlcad/usr/X11/include/fontconfig/fontconfig.h
04:10.28starseekerthat may be what's happening
04:10.34starseeker/usr/include is getting checked first
04:10.35brlcad/usr/X11/include is the "proper" one-stop shop for X11
04:10.38starseekerright
04:10.50starseekerbut I'll bet the find routines are looking in /usr/include
04:10.57brlcadso #include <X11/Xlib.h> works, as well as #include <fontconfig/fontconfig.h>
04:11.18starseekeryour cache file reports:  X11_X11_INCLUDE_PATH:PATH=/usr/include
04:11.39starseekerand /usr/include/fontconfig doesn't exist
04:11.43brlcadwhich is true for that specific test
04:12.56starseekerlet me check... it's now looking like there needs to be a specific fontconfig_include_dir var set...
04:13.16brlcadfontconfig is one of a half-dozen entities in /usr/X11/include
04:13.29brlcadGL, cairo, freetype2, ...
04:14.02starseekeryeah, but unless we convince the FindX11 routines to not look in /usr/include (or at least, not until after /usr/X11/include) the X11 includes aren't going to get fontconfig
04:14.55brlcadthe problem isn't fontconfig -- the failure is 1) assuming that the dir containing X11 also contains those deps and 2) not checking /usr/X11/include first  .. and maybe 3) not having the equivalent of --with-x=/usr/X11 :)
04:15.47starseekerdid you try moving /usr/include below /usr/X11/include in the X11_INC_SEARCH_PATH variable in FindX11.cmake?
04:17.05brlcadso here's another mystery .. when I first started editing FindX11.cmake .. /usr/include was at the BOTTOM of the X11_INC_SEARCH_PATH list .. which is why my commit comments asserted that the list seemed to be processed in reverse order
04:17.26brlcadI had trouble believing that, even with the evidence, so I reverted and resorted back
04:17.52brlcadthat's what I meant about not getting that list to make one bit of difference
04:18.28starseekerwhat about reducing that list to *just* /usr/X11/include - does that work?
04:18.38starseeker(take the order out of it, for the moment)
04:19.06brlcadI'll give that a quick test
04:19.41brlcadmy earlier test was to remove X11R6 since that's what most of the X11-related tests actually detect/use
04:19.55brlcadand even after removing all instances of it, still would only detect/use X11R6
04:20.27brlcadlike maybe some system Find* was getting called first and our list was pointless
04:20.31starseekerthat's strange... it almost sounds like it's getting the system FindX11.cmake and not our local copies
04:20.34starseekerer, yeah :-)
04:21.24starseekeriirc, one of the src/other instances (tk, I think) ends up called first, the way our toplevel currently works
04:21.42starseeker(with all bundled libs on - otherwise of course it depends)
04:22.25starseekerI had that problem earlier.  But since you changed 'em all and cleared the cache, it can't be that
04:22.46brlcadwell, like I said, I thought of that too and diligently overwrote all FindX11.cmake on each edit attempt
04:22.56starseekerknows
04:22.58brlcadas well as FindGL.cmake since it has some X11 tests of it's own
04:23.31brlcadedit made, re-cmaking
04:23.51starseekeronly other thing I can think of (what I would be doing) is to put some MESSAGE statements into the FindX11.cmake files to see what is set when.
04:24.43brlcadso that reminds me of another bitching point .. what is up with ccmake not giving the "g"enerate files option most of the time?
04:24.50starseekersomething like MESSAGE("X11 include path with FindX11.cmake in ${CMAKE_CURRENT_SOURCE_DIR}: ${X11_X11_INCLUDE_PATH X11}")
04:25.27starseekeruh - if it's acting like the gui, you need to do the configure twice before generate is available...
04:25.45starseekerrecalls a complaint about that on the CMake list a while back...
04:26.50brlcadit annoyingly starts up with EMPTY CACHE in an empty/new build dir, I run 'c'onfigure, I wait... get list of options, make my edits, 'c'onfigure *again* .. and sometimes it'll give me the 'g'enerate option, but usually I have to exit and "cmake ." to generate the makefiles for that last config
04:27.11starseekerO.o
04:27.33starseekeras far as I know, it's supposed to give you the generate option once no new variables have been added to the var list
04:27.42starseekerwhich is typically after the second configure
04:28.04brlcadwell I have no list the first time, so presumably they all get added
04:28.08starseekerif your option edits prompt more variables to appear, you'll have to do it again
04:28.13starseekeryes
04:28.31starseekerin the gui, the first configure never allows the geerate button to activate
04:28.40brlcadthen the second time, I usually do BUNDLED on the all deps option, turn on debugging, turn on opt, 'c'onfigure
04:28.53starseekerthe second does, provided no new variables are added as a result of opition changes between the first and the second
04:29.16starseekerah - yeah, that'll add new options as it runs the src/other configures it didn't run the first time
04:29.34starseekera third configure (with no option changes) should get you the generate button
04:29.40starseeker(or 'g' option)
04:31.00brlcadblech
04:31.38starseekeronce the configure emulation script is done it should feel like autotools on the command line
04:31.46starseekerthen you won't have to mess with the guis
04:32.26brlcadyeah, I'm really not digging ccmake
04:33.07starseekerusually does the command line: cmake -DBRLCAD_BUNDLED_LIBS=Bundled
04:33.52brlcadthe options aren't usefully grouped/sorted, can't see the curses cursor without color, no description/help for options (which you'd think would be a prime benefit of having a fancy curses gui)
04:35.18starseekercmake-gui probably isn't much better then (I prefer it personally, but that's just me...)
04:35.28starseekerdrop-down options are kinda cool though
04:37.36brlcadof course, patches welcome ;)
04:37.54brlcadso yeah, no-go on the path change
04:38.16starseeker*bleep*
04:38.33brlcadremoved all except /usr/X11/include in all FindX11 and FindGL files, still detecting /usr/include for headers and /usr/X11R6/lib for libs
04:38.36starseekeris this a machine I can remotely access?
04:39.10brlcadi could probably set up access in a couple min
04:39.19starseekeris willing to give it a go...
04:53.00CIA-109BRL-CAD: 03brlcad * r47371 10/brlcad/tags/rel-7-20-4/: retagging release 7.20.4 now that most of the build and distcheck issues have been cleaned up. tested numerous configurations on debian and mac 10.6
04:55.36starseekerbrlcad: take a look at: cmake --help-command find_path
04:56.05starseeker#5 in the search list is a list of pre-defined paths for each Platform
04:56.28starseekerthat could be interfering
04:57.18brlcadmaybe, or the path being searched for isn't useful
04:57.32brlcadlooking for an X11 dir seems a bit of a weak test, for example
04:58.04brlcadyou generally look for X11/Xlib.h or some other primary header
05:00.50CIA-109BRL-CAD: 03brlcad * r47372 10/brlcad/trunk/src/librt/CMakeLists.txt: shouldn't be any reason to disable strict mode on librt. change the code, not the messenger.
05:02.34CIA-109BRL-CAD: 03brlcad * r47373 10/brlcad/trunk/CMakeLists.txt: match the original autotools logic, detect all the way back to 8-bit architectures so we might have a prayer's chance of working out of the box on an embedded platform.
05:26.50CIA-109BRL-CAD: 03starseeker * r47374 10/brlcad/trunk/ (6 files in 6 dirs): Tweak FindX11.cmake for Mac OSX 10.6
05:26.58starseekerbrlcad: give that a go
05:34.52brlcadhey, I believe you -- if you say it works :)
05:35.08starseekeris finishing the compile now - at 89%
05:35.09brlcadis there an option that says "try these first, THEN try system"?
05:35.21brlcadoh, it wouldn't have gotten that far
05:35.27brlcadfailed in tk early
05:35.47starseekernot to my knowledge - I could achieve that behavior, but only by doing so "manually"
05:36.08brlcadso if the list is now being walked in order, /usr/include should probably come last
05:37.18brlcadand any system dirs being searched by default should probably get added
05:37.57starseekerbets that's where the X11R6 stuff was coming from though - the Developer SDKs have multiple copies of usr/X11R6 dirs
05:37.59brlcadrather, dirs that WERE being searched by that default logic
05:38.04brlcadnods
05:38.16brlcadmakes sense, fits the symptoms
05:39.00starseekernods - we could play with it some - if you want to do that, we'd have to investigate where the platform specific dirs are listed and append those variables
05:39.18brlcadI suspected as much very early into the testing, but didn't know an fix and it took a while to isolate the problem
05:39.59starseekernods - I experimented with something like this once before, but didn't (quite) need to go all the way to the no cmake system path option
05:40.09starseekerthis time it's legit - we need it
05:40.27brlcadgiven how critical proper detection of X11 is to our ability to even compile in a useful manner on most platforms, it warrants making it as robust as possible
05:40.46starseekernods - probably will have to add FindGL to this mix, too
05:41.15starseekerthat is isn't technically as necessary as X11 at the moment, but I don't expect that to last much longer
05:41.24brlcadeven better would probably be to find what the autotools logic is, and *also* use that since it's more likely to be more exhaustive
05:41.54brlcadyeah, we're to the point of needing GL for anything serious .. we need to fix our gl problems
05:42.13brlcadif we can't even detect gl cleanly, we certainly can't dev reliably with it
05:42.30starseeker*ding* *ding* *ding* - build complete on your mac.  logging off now
05:42.36brlcadawesome, thanks
05:43.11starseekernp - thank you!  that would have been a toughie without the system itself to test on
05:43.40brlcadif you want to sync that to stable and branch, and regenerate the tarballs, go for it ;)
05:44.06brlcadotherwise, I'll go with the ones already tagged since they're also tested on linux and don't want to do that whole round of retesting again
05:44.39starseekervotes for leaving it - autotools will work for this round
06:43.41brlcadsource tarballs uploading now, release notes hopefully sometime tomorrow
07:38.02jordisayolbrlcad: congratulations for the new release!
07:39.15*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:39.34jordisayolbrlcad: I see that the package size is bigger than the previous ones. What's the cause of this size difference?
07:50.02CIA-109BRL-CAD: 03d_rossberg * r47375 10/rt^3/tags/rel-7-20-4/: tag the C++ core interface with the corresponding BRL-CAD version (i.e. 7.20.4)
12:44.16CIA-109BRL-CAD: 03indianlarry * r47376 10/brlcad/trunk/src/conv/iges/treecheck.c: Change Treecheck() return from void to int
13:42.29*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
14:05.46*** join/#brlcad abhi2011 (~chatzilla@117.200.81.53)
14:38.52starseekerjordisayol: which packages are you building?  RPM?
14:39.52jordisayolyes, RPM for Fedora/Centos, RPM for OpenSUSE and DEB for Debian/Ubuntu/LinuxMint/...
14:41.02starseekerjordisayol: we have more docbook stuff (more advanced html and pdf is being generated thanks to Tom Browder)
14:41.10starseekerawesome
14:41.49starseekertries to remember if this last release is the one that will have the upgraded Boost - that might have upped the size too
14:43.26jordisayolaha, but what is needed to compile brlcad with docbook?
14:44.13jordisayol...in linux (ubuntu)
14:51.06jordisayolI got this:
14:51.06jordisayolGenerate extra docs ...................: ON (man/html
14:51.38jordisayolwith "fop" installed
14:52.20jordisayolGenerate extra docs ...................: ON (man/html only)
14:54.41CIA-109BRL-CAD: 03erikgreenwald * r47377 10/brlcad/trunk/src/libgcv/bottess.c: change double ptrs to explicit point_t ptrs.
16:23.30jordisayolstarseeker: so, do you think that pdf files must be included in linux packages?
16:39.22jordisayolstarseeker: deb package w/o pdf (until now), 50 Mb. with pdf 80 Mb.
16:40.17jordisayolstarseeker: please tell me what do you think
16:41.10jordisayolyou too brlcad
16:41.29jordisayoli've to go
16:41.52jordisayolplease leave your opinion here
16:41.54jordisayolbye
16:55.15*** join/#brlcad abhi2011 (~chatzilla@117.200.85.105)
17:28.59starseekerjordisayol: no, pdf's shouldn't be included (IMO)
17:29.37starseekeryou have to explicitly turn on PDF building - it's another option
17:29.58starseeker(that option won't even appear unless fop is around)
17:30.44starseekerpdf building is expensive and (unlike the html output) isn't directly used by any of the editing environments
17:37.15brlcadjordisayol: since the pdf files are not yet in the final desired form (layout, images, structure), it's not necessary that they be included in binary distributions but not a problem if they're included either
17:37.45brlcadrequiring fop to build brl-cad is a huge requirement, so I wouldn't make it a .deb build dependency (pulls in all of fop+java)
17:38.51brlcadjordisayol: as for the size of the download, the size tends to increase with every release because the size of the code tends to increase every release (ohloh has graphs)
17:41.23jordisayolok, many thanks starseeker and brlcad. i'l keep as they are
17:41.26brlcadmost cad distros are 10x our binary size due to docs and metadata, so I won't really be concerned until we cross the max CD-size barrier (about 860MB)
17:42.17brlcadeven then, that'll just to a good audit point to make sure we're not being too wasteful and inefficient with 3rd party deps and data, real practical limit is dvd capacity
17:47.08jordisayolanother question. can i switch archer as default graphic app, or is i still in pre-alfa state?
17:47.15abhi2011I am trying to do a windows build and I read README.windows
17:47.35abhi2011but there is no brlcad.sln file in brlcad\misc\win32-msvc
17:48.09abhi2011is the cmake approachm the only approach at the moment ?
17:51.23brlcadjordisayol: it's still pre-alpha, I'm hoping we push out an alpha before the new year
17:51.55brlcadabhi2011: the readme is out of date, cmake is THE approach at the moment, install it on windows and the build should go pretty smoothly
17:52.06jordisayolbrlcad: ok, mani thanks. i'll keep everything as is
17:52.07abhi2011ok
18:01.20abhi2011so I have visual studio 2008 express edition installed but i get errors with cmake
18:01.30abhi2011I guess the best option then is to go with mingw
18:01.43brlcadwhat errors?
18:02.54abhi2011http://bin.cakephp.org/view/611912235
18:04.05abhi2011support for platforms, hmm
18:07.22abhi2011seems like a bug : http://social.msdn.microsoft.com/Forums/en-US/vssmartdevicesnative/thread/88685f18-11a0-469f-902d-08a00aa01554/
18:07.34abhi2011maybe i ll get vc express 2010 and try
18:10.38abhi2011hmm ok, I had chosen the win64 compiler
18:10.48abhi2011choosing the normal 32 bit build , works
18:14.28abhi2011though there are a large number of libs that were not found : http://bin.cakephp.org/view/1966265968
18:15.46abhi2011its probably looking for the DLLs in Windows/SysWOW64 and not finding them, maybe I should install them
18:17.00abhi2011oh wait , its going to compile them, so its probably ok
18:18.20abhi2011ok got the sln file
18:25.52brlcadabhi2011: yeah, no worries
18:26.04abhi2011:)
18:26.08brlcadthe lib detection is just to decide whether or not we need to use our bundled versions
18:26.33brlcadon windows, where pretty much nothing exists already, it's to be expected that most of the tests will result in using the bundled lib
18:28.14brlcadyou might still run into a compilation failure, windows doesn't get tested very often
18:31.04brlcadif you do, though, post it so someone can fix it .. or fix it yourself ;)
18:35.04abhi2011yes sure
18:35.30abhi2011i cant find the my simulate project under libged though :P
18:35.40abhi2011*simulate folder
18:36.32abhi2011probably removed from the files in the solution, due to bullet not being detected, by cmake
18:37.49abhi2011yeah , hav to move to windows for a few days, as I am unable to access the svn from linux suddenly, probably some isp issue
18:43.47starseekeris sorry, but will be a Good Thing if you can get things working on Windows as well
18:44.22starseekeryeah, if it can't find bullet it won't try building things needing it
18:46.11abhi2011starseeker: hehe , np, yeah will compile bullet  dynamic libs now :)
18:49.39starseekermakes a note to try out tileQt and check its license...
18:52.44abhi2011ok, the build completed smoothly, now its saying to run 'make install', I think that would need make to be installed, which is only in linux
18:53.32abhi2011hmm maybe i ll just run the INSTALL target
18:53.59abhi2011right that did it
19:09.49starseekergrins - tileQt already has a CMake build :-)
19:09.51starseekerawesome
19:30.04abhi2011strange, I have just pointed the system environment variables BULLET_DYNAMICS_LIBRARY BULLET_COLLISION_LIBRARY BULLET_MATH_LIBRARY BULLET_SOFTBODY_LIBRARY BULLET_INCLUDE_DIR
19:30.22abhi2011and set them to the proper paths where bullet .libs are installed
19:30.31abhi2011still I get the Bullet missing error
19:30.54abhi2011arent the variables supposed to be system variables ?
19:31.32starseekerabhi2011: try setting them in CMake
19:31.39abhi2011ah ok
19:33.47*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
19:43.44*** join/#brlcad abhi2011 (~chatzilla@117.200.80.3)
19:52.14abhi2011starseeker: that does not seem to work either
19:52.32starseekerwhat's the error?
19:52.54abhi2011i defined all 5 variables in cmake, but it says : Could NOT find Bullet (missing:  BULLET_DYNAMICS_LIBRARY BULLET_COLLISION_LIBRARY BULLET_MATH_LIBRARY BULLET_SOFTBODY_LIBRARY BULLET_INCLUDE_DIR)
19:53.05abhi2011then it removes them after configuring
19:53.18starseekerhmm.  Where did you define them?
19:53.49abhi2011by adding an entry with the add entry button in the cmake-gui
19:55.22starseekerOK.  you might try editing the CMakeCache.txt file...
19:55.33abhi2011ok
19:58.26abhi2011i guess the path should only mention the folder name, and not include the filename, as in : F:\Code\libraries\bullet-build\lib\Debug
20:00.52starseekerright
20:01.05starseekerfor the includes anyway
20:01.14starseekerthe libs will want the full name
20:02.23starseekerso the 5 variables you listed include 4 libs - those are full path with filename
20:02.37abhi2011ok
20:02.57starseekerBULLET_INCLUDE_DIR should be just the directory with the .h files, or possibly a parent directory depending on the includes
20:32.20abhi2011ok, now it found it
20:32.44abhi2011I think setting them as enviromment vars should now also work as long as the full files names are given where needed
21:06.05abhi2011Bullet running fine in windows now, linked against the static libs
21:06.25abhi2011starseeker: thanks!
21:09.37starseekerhah - awesome!
21:10.48starseekerabhi2011: I know you've posted links before, but I don't recall - where are you stashing the various videos of your progress?
21:15.10abhi2011starseeker: they are here : http://brlcad.org/wiki/User:Abhijit#Log
21:15.18abhi2011there is just 1 video currently
21:15.41abhi2011another requires the server as its a large scene with glass affects, so its not been done yet
21:16.06abhi2011*glass shaders
21:19.36abhi2011has anyone noticed that ws-indent and other scripts which format the code, format it for the older editors like emacs, the code appears misaligned in eclipse and visual studio
21:20.11abhi2011code aligned in eclipse and vs appears misaligned in emacs :P
IRC log for #brlcad on 20111101

IRC log for #brlcad on 20111101

01:31.51*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
04:11.16*** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
04:40.55*** join/#brlcad abhi2011 (~chatzilla@117.200.89.98)
05:31.21*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
06:43.57*** join/#brlcad abhi2011 (~chatzilla@117.200.80.54)
06:44.01CIA-109BRL-CAD: 0323.19.56.171 07http://brlcad.org * r3191 10/wiki/Talk:Main_Page:
06:50.53*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
07:10.23*** join/#brlcad abhi2011 (~chatzilla@117.200.89.69)
08:15.19*** join/#brlcad abhi2011_ (~chatzilla@117.200.86.172)
08:31.34*** join/#brlcad merzo (~merzo@109-45-133-95.pool.ukrtel.net)
11:07.28*** join/#brlcad abhi2011 (~chatzilla@117.200.89.50)
11:41.38*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:22.00*** join/#brlcad abhi2011 (~chatzilla@117.200.85.236)
12:40.08*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:46.32*** join/#brlcad merzo (~merzo@72-3-133-95.pool.ukrtel.net)
13:31.16*** join/#brlcad abhi2011 (~chatzilla@117.200.84.105)
13:54.23CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3192 10/wiki/Talk:Main_Page: Reverted edits by [[Special:Contributions/23.19.56.171|23.19.56.171]] ([[User talk:23.19.56.171|Talk]]); changed back to last version by [[User:X Tin Basher|X Tin Basher]]
13:54.36CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:23.19.56.171]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
14:15.35brlcadabhi2011: funny coincidence, someone on the bullet channel was bitching just yesterday about bullet's internal ray tracing sucking
14:16.00brlcadtold them about your efforts to integrate with librt, excitedness ;)
14:27.27*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
14:29.58*** join/#brlcad abhi2011 (~chatzilla@117.200.91.35)
14:30.07abhi2011brlcad: cool :)
14:30.19abhi2011so there is someone replying in that channel :P
14:31.00abhi2011I have been trying to figure out a algorithm that uses all the normal and curvature info to generate the points
14:31.22abhi2011guess I ll first go with the box-box case
14:31.50abhi2011a important thing to figure out is the direction in which an object is penetrating another object
14:32.08abhi2011as the normal has to point along that direction
14:33.36abhi2011currently I ll just check to see which ever dimension is the least in the overlapping volume , i.e. if the object is penetrating another along the  z axis, then the dimension of the overlap region along the z axis will be least
14:35.14abhi2011of course the best way would be to make the normal point  according to the curvature of the 2nd body
14:39.16abhi2011like so : https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit
14:40.23abhi2011but then rays hitting the curving surface would give many normals, so the proper normal has to be chosen, which can be got by vector summing I guess
14:45.59abhi2011funny warning about the IGNORE symbol being redefined : http://bin.cakephp.org/view/1298213576
14:46.24brlcadyeah, that channel is quite most of the time, but every now and then a discussion sparks up
14:47.39brlcadgood to know about the IGNORE redefinition
14:52.10brlcadabhi2011: we actually include measures to define our IGNORE macro without conflicting with the windows macro
14:52.23brlcadso somewhere a windows header is getting included without our usual protections
14:53.44*** join/#brlcad abhi2011_ (~chatzilla@117.200.84.102)
14:53.45brlcadabhi2011: AHA ... I think I found the problem -- you must include common.h before any/all *system* headers
14:54.01abhi2011_ok
14:54.25brlcadyou saw my other comments?
14:55.52brlcadirc problems?
15:03.30abhi2011brlcad: yes , yes I saw them till : good to know about the IGNORE redefinition and then AHA
15:03.47abhi2011yeah, disconnected in between
15:05.44abhi2011yep I ll move  up common.h
15:10.34abhi2011hmm ,warning is still there though
15:11.54abhi2011I think the issues is that a similar macro has been defined in both places
15:11.57abhi2011not the order
15:12.14abhi2011winbase.h & common.h
15:20.11CIA-109BRL-CAD: 03abhi2011 * r47378 10/brlcad/trunk/src/libged/simulate/ (9 files):
15:20.33abhi2011ok hope the commit went through fine, committing from windows with tortoise svn for the 1st time
15:35.38abhi2011so is there a function already, which lets me check if a solid is present in the tree of a comb
15:36.26abhi2011I can write one to recursively check the tree of a comb, and if it find the solid, then return true, but perhaps one already exists
15:37.03abhi2011I need it for checking which comb, a solid belongs to , when rt gives me a solid at the point where a ray exits
15:37.26abhi2011I then need to sum the normal only for that comb(rigid body)
15:38.46abhi2011dbfind is there I see
15:46.49abhi2011yep, ged_find, does exactly that , traversing in LNR order, will modify it a bit(in my own file) :P
16:42.13CIA-109BRL-CAD: 03abhi2011 * r47379 10/brlcad/trunk/src/libged/simulate/ (simutils.c simutils.h): Added a function to check if a solid is present in a comb, required for checking which rigid body(a comb), a particular solid belongs to , while raytracing.
18:04.29*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
18:52.50CIA-109BRL-CAD: 03abhi2011 * r47380 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.h):
18:54.23CIA-109BRL-CAD: 03abhi2011 * r47381 10/brlcad/trunk/src/libged/simulate/simrt.c: Added code for normals
19:10.11*** join/#brlcad Forth (~Forth@92.242.118.253)
19:11.55*** part/#brlcad Forth (~Forth@92.242.118.253)
19:16.19CIA-109BRL-CAD: 03abhi2011 * r47382 10/brlcad/trunk/src/libged/simulate/simrt.c: More supporting code to test if the normals are being recorded correctly during the ray trace
19:18.11brlcadabhi2011: of course the macro is defined in both places, but the places we include windows headers takes care of that
19:18.40brlcadso if that conflict is encountered, some assumption is failing or the header inclusion ordering is wrong or the wrong headers are being included
19:19.35brlcadwinbase.h shouldn't be directly included anywhere, so you have to look at the header includes to recursively see who includes winbase.h
19:19.36abhi2011ok
19:20.44brlcadabhi2011: what was r47378?
19:21.14brlcadcommit message got left off, not clear what changed since it was a fairly big commit .. wondering what it was
19:21.25abhi2011it was an update of the source code to use contact pairs again
19:21.33brlcadah, okay
19:21.39abhi2011new svn software :P
19:21.44abhi2011forgot to add message
19:21.46brlcadyep, realized that
19:22.01abhi2011so I have an awesome idea now about how to generate normals
19:22.22abhi2011basically summing the normals in the surface inside the overlap region
19:23.03brlcadsounds good :)
19:23.20abhi2011the vector sum of the normals on the outer surface of the body  gives the direction of the force that the body would apply on anything touching it
19:23.28abhi2011as is the case in the real world
19:23.54abhi2011once I have the normal, I ll shoot rays in that direction to get the depth of penetration
19:24.27abhi2011and then the contact points (which should be on the surface of the body always), are the points where these rays leave the object
19:24.33brlcadcould you use the velocity vector of the object in motion too?
19:24.49abhi2011yes I can vectgr sum that to the normal too
19:24.56abhi2011or just use the velocity vector
19:25.08abhi2011but the point is no matter what the velocity vectpr
19:25.19brlcadwhy wouldn't you just use the velocity vector, shoot rays in the direction of the velocity, calculate the depth of penetration?
19:25.20abhi2011the force will be based on the surface
19:25.41abhi2011well because it depeds on both
19:26.01abhi2011the angle of the surface and the velocity direction at which the object strikes
19:26.09abhi2011that surface
19:26.18brlcadokay
19:26.36abhi2011like a ray reflecting off a glass at an angle
19:26.43brlcadnods, makes sense
19:26.46brlcadmisunderstood
19:26.47abhi2011so hav to think about how to account for the velocity
19:26.52abhi2011ah
19:27.00abhi2011the angle between normal and velocity
19:27.13abhi2011law of reflection calculation maybe
19:27.45abhi2011but hmm, I think bullet will take care of that
19:27.56abhi2011the fnal velocity direction i mean
19:28.04abhi2011all I need to give it is the normal
19:28.12abhi2011at the point of contact
19:29.34abhi2011here are some sample cases : https://docs.google.com/drawings/d/1Fp44t9AcZZurbNufXti64u-23CRjC49Z3r0WSmim5tU/edit
19:30.49abhi2011so the lower left case, shows that the concave case should also be possible to calculate correctly
19:31.27abhi2011if this works out then I can check how to insert multiple manifolds, which I have read somewhere , is possible
19:52.51brlcadcan't get to gdocs at the moment, will have to take a look later
19:54.54CIA-109BRL-CAD: 03bob1961 * r47383 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: When opening a database also change the current working directory to the directory where the database lives.
20:02.17*** join/#brlcad abhi2011_ (~chatzilla@117.200.81.190)
20:15.49*** join/#brlcad abhi2011_ (~chatzilla@117.200.81.155)
20:46.01CIA-109BRL-CAD: 03starseeker * r47384 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-xml-catalog.xml.in: I don't think this variable needs to be specific to BRL-CAD in this case...
20:52.33CIA-109BRL-CAD: 03starseeker * r47385 10/geomcore/trunk/ (12 files in 5 dirs): Turn on docbook documentation for geomcore. Stub in a geometry protocol doc, but nothing much there at the moment.
20:56.01CIA-109BRL-CAD: 03abhi2011 * r47386 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simutils.c simutils.h): Now the entry and exit solids of a ray passing through an overlap region are checked to see if they belong to the comb of rigid body B
20:59.16brlcaddeadline is today -- feel free to fill out quick/easy tasks that could be completed in 1-3 days at http://brlcad.org/wiki/Contributor_Quickies
20:59.40brlcadI'm crafting together our proposal now
20:59.58brlcadideally we need 10 topics for each of the 8 categories
21:00.49``Erik'separate out libnmg' O.o I have vague recollection of libnmg not too long ago :)
21:00.55brlcadwell, 5-10 tasks per topic
21:01.37``Erikthink simd/sse vmath might be worth an entry?
21:03.02brlcadiirc, include/vector_*.h was (as anticipated) an attempt at that
21:03.04brlcadand it failed
21:03.53brlcadtest harness for vmath.h might be something though
21:04.28brlcadexample of gnome tasks  https://live.gnome.org/GoogleCodeIn/Tasks
21:04.55brlcadI'm inclined to direct all students to either IRC or the mailing list, thoughts on which?
21:05.12brlcadkeeping in mind that it might be a lot of students 24-7
21:05.13``Erikin looking at that a while back, the choice to go with typedef point_t fastf_t[3]; instead of typedef point_t struct { fastf_t f[3]; }; or something was ...  critical
21:06.16brlcadit wasn't a fail in terms of being a drop-in replacement -- that would have been the technical issue there
21:06.46brlcadit was a fail in that the simd version wasn't actually faster -- needed more data, not just one vector/matrix at a time
21:07.01starseekerfix tkhtml3 on Win64?
21:07.22starseekerfor large numbers of students, I'd vote mailing list
21:07.23``ErikI think irc will be quicker and more accepting of newbs
21:07.31starseekerhard to track conversations though
21:07.34brlcadstarseeker: can you explain the problem?
21:07.39``Erikbut irc would lack good record
21:07.45starseekerprobably not well enough for a student
21:07.46brlcadremember that these are *high school* students
21:08.08brlcadthe questions are going to be very much "hold my hand", what's next?
21:09.23brlcadbhinesley: jordisayol: louipc: kanzure: anyone else: interested in being a GCI mentor?
21:10.20starseekerbrlcad: what about bu_getopt_long or some such?
21:10.57starseekerjust getting it working + adding it to one command would be a good start
21:11.45brlcadI don't think bu_getopt_long is what we want really (at least there's little-to-no value in having a bu version of getopt_long())
21:12.09starseekeruh... rt with -- options seems worthwhile...
21:12.10brlcadwe need long options, but there's no reason it needs to be compatible with that extension
21:12.42starseekerdo they do it the wrong way?
21:12.43brlcadgetopt_long() is an overlay with getopt() .. the two work suckily together
21:13.04brlcadpretty much
21:13.28starseekerwe need something - what do you suggest?
21:14.09brlcadwriting an option interface for bu
21:14.20brlcadalready sketched out the basics a month or two ago
21:14.31starseekererm.  link?
21:14.45brlcadno link
21:14.46brlcadcode in a checkout
21:14.50starseekerah
21:15.02brlcadstill, too advanced for gci I think
21:15.08starseekerk.  pity
21:15.24brlcadif it's not something that'd take you less than a half a day from start to finish, it's probably too complex
21:15.59brlcad13 year olds ...
21:16.02starseekerwell, there's always fixing the bbox function for bots
21:16.29brlcadsure -- could put that one up, but i'd mark it hard :)
21:18.50abhi2011I think tcl and gui will be easier for high school students :)
21:19.04abhi2011maybe more of tcl and some libged related code
21:19.10brlcadfrom other project's reviews from prior years, the kids really do end up being a nearly full-time effort so we need to manage the complexity up front -- things we can explain and point trivially
21:19.19starseekerheh - I can't seem to come up with small projects from the gui side...
21:19.25brlcadabhi2011: you have some project ideas?
21:19.30abhi2011for example the idea about integrating some of the visualization tools into the gui
21:19.45abhi2011most of them have a fixed interface I guess
21:19.48brlcadremember that it's basically a contest -- they're looking for tasks that take hours or a day or two at most
21:20.00abhi2011oh ok
21:20.22brlcadwhich includes the time to download the software, become familiar with the problem, find their way around, run a tool, etc
21:21.05abhi2011hmm, then tcl and gui stuff would be tough
21:21.23brlcadcame up with what I think is a GREAT idea at the mentor summit... we can create a preconfigured disk image for the students that already has a source checkout and compiled install ready to go
21:22.14brlcadthat with a few simple instructions to download qemu, download disk image, create new image, run .. source is here, binaries are there, go!
21:24.46abhi2011yes, that can really get things going fast, did that for virtual box images once
21:25.21abhi2011so we are not expecting code from them I guess, they design something using the tools already present in brlcad ?
21:25.59brlcadyou seen the http://brlcad.org/wiki/Contributor_Quickies list?
21:26.03brlcadit can be a code project
21:26.12brlcador docs, or web or ... anything really
21:26.21brlcadsomething that'd take hours of time
21:28.19abhi2011ok
21:33.14abhi2011well I was thinking along the lines of making mged a bit easier to use : like when an object is selected and the primitive editor is opened,  then the selected object's name should already be there and it should be displaying the object name
21:33.48CIA-109BRL-CAD: 03128.63.32.62 07http://brlcad.org * r3193 10/wiki/Contributor_Quickies: /* Code */ add rt_bot_bbox item
21:34.03abhi2011or even simpler, ensuring that closing the command window closes the application
21:34.47abhi2011including the gfx window
21:35.04starseekerthat... might not be so simple, actually
21:35.13abhi2011oh :)
21:35.23starseekerseems to recall brlcad working with that once...
21:35.26abhi2011low level opengl callbacks ?
21:35.35starseekerdon't recall now
21:36.25starseekerbrlcad: is excising Tcl functions from libraries too hard? (guessing yes...)
21:37.02abhi2011also is there a script for moving the view along a specified path, it would be awesome to write a script or a simple c function that revolves the camera around the scene as objects are dropping
21:37.08abhi2011*moving the camera
21:37.18cvds_abhi2011: please dont, since I use that feature (closing thecommand window but keeping the gfx window)
21:37.29abhi2011hehe ok :)
21:37.53abhi2011so you run a script then close the command window I guess
21:38.27cvds_mged -c to attach a single window and then set mged_default(multi_pane) 1; gui; and close the mged command window ;)
21:38.54abhi2011ah ok
21:40.13cvds_and using yakuake as the input. Works like a charm
21:40.32starseekerbrlcad: http://directory.fsf.org/wiki/Popt
21:40.40starseekerhttp://rpm5.org/files/popt/popt-1.16.tar.gz
21:40.46starseekerwould that be of interest?
21:41.38starseekerlooks like MIT style license
21:48.02starseeker(not for GCI per say, but as an alternative to rolling our own option parsing?)
21:59.21brlcadabhi2011: having the closure of all of mged's windows actually close mged sounds like a great task -- can you add that to the wiki?
22:00.04brlcadstarseeker: not sure what you meant with the excising
22:00.34starseekerdoing whatever is needed to get the Tcl/Tk C api usage up to libtclcad (or steps in that direction)
22:00.35brlcadabhi2011: camera 360 script sounds like another great one, wiki?
22:01.20starseekerblinks - must have been thinking something else - I thought that "close all windows" issue was tied up with something else more complex
22:01.28brlcadcvds_: interested in being a mentor? :)
22:02.01abhi2011brlcad: sure and sure :)
22:02.22brlcadstarseeker: it's a bug, it used to close mged
22:02.37brlcadnow you can close those two windows and mged is still running
22:02.41brlcadabhi2011: awesome :)
22:08.42CIA-109BRL-CAD: 03starseeker * r47387 10/brlcad/trunk/src/ (3 files in 2 dirs): Shouldn't have moved this, used only internally in libbu and it's one file.
22:11.06brlcadstarseeker: Makefile.am
22:11.20starseekercoming now
22:11.39CIA-109BRL-CAD: 03starseeker * r47388 10/brlcad/trunk/src/ (5 files in 3 dirs): Clean up the rest of the uce stuff
22:11.41starseekerprods CIA
22:21.20CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3194 10/wiki/Contributor_Quickies: /* Code */
22:54.32CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3195 10/wiki/Contributor_Quickies: /* Code */
22:55.37brlcad~abhi2011++
22:55.41brlcadawesome
22:55.44CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3196 10/wiki/Contributor_Quickies: /* EASY: Camera 360: A Tcl script to capture images while rotating the view around a scene */
22:56.47abhi2011will try to come up with some more tomorrow :)
22:56.53brlcadwe need at least 3 more outreach and translation tasks, and at least 1 more research and UI task :)
22:57.01brlcadand QA
22:57.09brlcadneed at least 5 for each
22:57.58*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
22:59.16abhi2011how about starting the primitive editor with the currently selected object instead of having the user type it in each time
22:59.53brlcadyou mean sed?
22:59.58brlcadsure
23:00.16brlcadoh, in the gui
23:00.20abhi2011yes
23:00.30brlcadyeah, that'd be possible .. a bit complicated to explain, definitely a hard task
23:00.43brlcadyour camera task is probably medium or hard for that matter :)
23:00.47abhi2011yeah it requires familairity with mged
23:01.01abhi2011yeah :P
23:01.02brlcadeasy if you know mged and know scripting.. but that's a big IF for a 13 year old :)
23:12.14``Erikiff, even
23:12.38``Erik*ponder* logo on mged?
23:12.59brlcadperfect, add it
23:13.16brlcadgreat idea
23:13.37``Erikiirc, logo was a variant of scheme, soooo... yeah, let's ditch tcl for lisp!
23:14.11brlcadheh
23:14.23brlcadtook that to mean .. model the BRL-CAD logo in MGED :P
23:14.52``Erikif mged ate lisp, it'd be automatable...
23:15.00``Erik"just a couple lines"
23:17.38``Erikhas an old sorbel filter in C *ponder*
23:20.45``Erik(whuddya mean, making each pixel a colored arb8 ain't what ya meant?)
23:23.18brlcadmmhmm
23:23.33brlcadpix-g will do it now :)
23:25.33``Erikpix2g ya mean?
23:25.43brlcadright
23:25.55brlcaddidn't want it to look like a proper tool :)
23:26.07``Erikdoes not recall that puppy
23:26.30brlcadproc-db
23:26.35``Erikand I keep typing 'git log', starseeker has poisoned my brain
23:26.57``Erikit's old, even
23:27.12brlcadyeah, did that a long time ago
23:27.21brlcadfairly useless, but fun hack
23:27.39``Erikis it actually a planar arb8 set with colors?
23:28.01brlcadI started with arbs, but I think that last rev uses spheres
23:28.15brlcadtrivial to put it back
23:28.38``Erikpainter and smoother might replicate something acceptable... push it to nurbs and it's all good
23:29.31``Erik(curve fit on a nurb is a whole lot easier than attempting to replicate geometry in implicits, right?)
23:29.57``Eriksrry, on a nurbs
23:32.00brlcadyou going to add that logo task? that really is a great idea
23:32.55``ErikI'll let you... I actually meant the language "logo"
23:33.59``Erikif you want to give me credit for sparking the idea in you, that's cool, but that definitely isn't what I meant :)
23:36.26brlcadeven better if you'd write it, cause writing this proposal is going to have me right up against the submission deadline
23:36.54``Erikwhich logo?
23:37.18brlcadthe new logo
23:37.38brlcadpoint them to the news page on the main website
23:38.25``ErikI have a cat on my lap, and I'm not sure if he's actually alive anymore O.O
23:40.29``Erikabhi has no user page
23:42.32``ErikI d'no, doco or ux?
23:43.06``ErikI'll go ahead and call it ux
23:49.38``Erikffs, WoW is stomping my machine here O.o 20-30 seconds before a keypress registers in other apps :/
23:49.39brlcad<PROTECTED>
23:55.08CIA-109BRL-CAD: 03Erik 07http://brlcad.org * r3197 10/wiki/Contributor_Quickies: /* User Interface */ Add .g of logo task
23:55.53``Erikwordsmith your heart out, probably needs a time guess
23:56.00brlcadk
23:56.41brlcadideas on hold.. the deadline apparently isn't .. what I calculated it to be ..  (ffs.)
23:56.52brlcadjust went to submit (early) and .. it's not
23:59.34CIA-109BRL-CAD: 03128.63.32.74 07http://brlcad.org * r3198 10/wiki/Contributor_Quickies: move logo to outreach, needs two more
IRC log for #brlcad on 20111102

IRC log for #brlcad on 20111102

00:00.18``Erikooh, not logged in, and still at the office
00:00.42brlcadwonder who that is
00:01.16CIA-109BRL-CAD: 03Erik 07http://brlcad.org * r3199 10/wiki/Contributor_Quickies: /* EASY: Model new BRL-CAD Logo using BRL-CAD */ Add time guess
00:03.43CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3200 10/wiki/Contributor_Quickies: clarify docs
00:04.31CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3201 10/wiki/Contributor_Quickies: already had time estimate added, update
00:06.15``Erikwhups, assumed fime would be between body and references
00:09.06CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3202 10/wiki/Contributor_Quickies: /* Outreach */ idea on interviewing jordi
00:14.11CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3203 10/wiki/Contributor_Quickies: /* Outreach */ another on writing geometry cpp articles
00:26.48CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3204 10/wiki/Contributor_Quickies: /* Quality Assurance */ deep unit test, and find bugs in archer
00:32.44CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3205 10/wiki/Contributor_Quickies: /* Research */ update the spreadsheet
00:39.42*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
00:41.04CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3206 10/wiki/Contributor_Quickies: /* User Interface */ reorganize mged's menu
00:47.38CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3207 10/wiki/Contributor_Quickies: /* Translation */ translate our intro mged docs
00:55.12CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3208 10/wiki/Contributor_Quickies: /* Translation */ be specific on the desired languages
00:56.57CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3209 10/wiki/Contributor_Quickies: /* Translation */
01:01.55CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3210 10/wiki/Contributor_Quickies: /* Translation */ HACKING
01:04.40CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3211 10/wiki/Contributor_Quickies: /* Translation */ our portuguese contingent deserve props for all the attention they've given over the years
01:07.25*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:09.50starseekerhah cool, didn't know about this project:  http://www.helenos.org/
04:04.36*** join/#brlcad abhi2011 (~chatzilla@117.200.89.70)
04:09.09CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3212 10/wiki/Contributor_Quickies: /* EASY: Translate a chapter from the Introduction to MGED to Hindi */
04:09.21abhi2011:P
06:16.49*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
06:25.15abhi2011hmm getting a number of erros from a custom build rule in cmakelist.txt : http://bin.cakephp.org/view/1879910803
07:00.39CIA-109BRL-CAD: 03abhi2011 * r47389 10/brlcad/trunk/src/libged/simulate/simutils.c: Corrected a bug in the primitive lookup code for a comb
08:36.30cvds_tgc(thumbPlungerTop1.s):  A not perpendicular to B, f=-0.21693 <-- hmmm I did not know this was a requirement -_-
08:36.57cvds_in thumbPlungerTop1.s rec 0 0 0 0 0 3 0 7.5 0 22.5 -5 0 <-- this is what I more or less want
08:38.29cvds_(its combined with a in thumbPlungerTop2.s rpp 0 32.5 -7.5 7.5 0 3 thats why its not perpendicular)
08:53.55cvds_resolved it by orot the rec inside the combination then pushing it
10:03.53cvds_brlcad: I ordered a lot of thing for the printer so hopefully I can give you those pictures somewhere december (provided I can tune the printer well enough)
10:32.45*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
10:32.45*** join/#brlcad piksi (piksi@pi-xi.net)
10:32.45*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
10:32.45*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
10:33.21*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
10:34.09*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
10:34.18*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
10:34.50*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
10:51.43*** join/#brlcad bhinesley (~bhinesley@adsl-99-52-241-103.dsl.bkfd14.sbcglobal.net)
10:51.43*** join/#brlcad yiyus (1242712427@je.je.je)
10:51.43*** join/#brlcad ChanServ (ChanServ@services.)
10:51.43*** mode/#brlcad [+o ChanServ] by calvino.freenode.net
11:21.43CIA-109BRL-CAD: 03starseeker * r47390 10/brlcad/trunk/src/libbu/CMakeLists.txt: Whoops, ignoring wrong file
11:53.06*** join/#brlcad abhi2011 (~chatzilla@117.200.84.234)
12:02.05*** join/#brlcad abhi2011 (~chatzilla@117.200.88.30)
12:05.36*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:45.27*** join/#brlcad juanman (~quassel@201.216.198.121)
12:45.32*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:51.41brlcadcvds_: if you'd like to generalize the tgc even further, go for it ;)
12:52.02brlcadthe intersection calculations get even more hairy if they're not perpendicular
12:52.54brlcadyou can get non-perpendicular caps with a subtraction, so it's still an achievable shape -- just not with one tgc
12:53.32brlcadcan't wait to see the pics ;)
13:34.12CIA-109BRL-CAD: 03brlcad * r47391 10/brlcad/trunk/HACKING: freshmeat change their name to freecode
13:47.28*** join/#brlcad abhi2011 (~chatzilla@117.200.86.135)
14:53.45cvds_brlcad: I see, I sorted it with a normal rec, looks good enough for now
14:55.44cvds_http://flic.kr/p/aBer23 you can see the result here
14:57.59CIA-109BRL-CAD: 03brlcad * r47392 10/brlcad/trunk/HACKING:
14:57.59CIA-109BRL-CAD: add a regex one-liner awesomeness for automatically extracting the latest NEWS
14:57.59CIA-109BRL-CAD: section into a release notes README-#-#-#.txt file. also fix the release steps
14:57.59CIA-109BRL-CAD: so that binary platform maintainers are notified before public release
14:57.59CIA-109BRL-CAD: announcements are posted (so they can have a chance to get started on binary
14:57.59CIA-109BRL-CAD: builds)
15:07.14cvds_and for the live of me I dont get solid rotation
15:15.38cvds_rot takes into account current view angle ?
15:18.39cvds_hmm arot actually seem to do what I expect
15:30.33*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:36.47brlcadcvds_: primitives rotate around some primitive-specific keypoint, which might not be where you'd expect an origin to be
15:37.01brlcadfor a cylinder, for example, it's the center of the base ellipse
15:37.11brlcadfor an arb8, it's the first corner
15:37.50brlcadyou'd probably expect the object center for both, but to get that behaviour you'll either need to use one of the other rotation commands or set a keypoint explicitly
15:38.50cvds_brlcad: nope, with rot I was expecting a rotation over 1 primary vertex, but it rotated over more. with arot I specify the vertex explicitly and things are spiffy ;_
15:38.53cvds_:)
15:47.38CIA-109BRL-CAD: 03brlcad * r47393 10/brlcad/trunk/src/util/ (bw-png.c pix-png.c png-bw.c png-pix.c png_info.c): zlib.h needs to be included before png.h in case compression flags are used. also, they're system headers, so use brackets instead of quotes and pull them up into the right section.
15:50.07CIA-109BRL-CAD: 03brlcad * r47394 10/brlcad/trunk/src/libged/png.c: they're system headers, so use brackets instead of quotes and pull them up into the right section.
15:52.35CIA-109BRL-CAD: 03brlcad * r47395 10/brlcad/trunk/src/fb/ (fb-png.c png-fb.c): more header cleanup. png/zlib are system headers. use bin.h instead of directly including winsock.h
16:11.34*** join/#brlcad abhi2011 (~chatzilla@117.200.83.152)
16:31.16CIA-109BRL-CAD: 03abhi2011 * r47396 10/brlcad/trunk/src/libged/simulate/simrt.c: Shooting rays in y direction now and analyzing the normals generated.
16:40.11brlcad``Erik: you see the new gcc farm server?
16:40.25brlcad64-proc power7 .. frickin awesome :)
16:40.52brlcadrather, 64-core
16:47.08*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
17:04.46brlcadstarseeker: http://paste.debian.net/142105/
17:05.39brlcadthat was a default "cmake .." build
17:48.52cvds_http://flic.kr/p/aBfMH8 <-- fun making these shapes
17:56.59CIA-109BRL-CAD: 03abhi2011 * r47397 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Added code for shooting z rays and analyzing normals.
18:07.46brlcadcvds_: nice :)
18:07.59brlcadsome sort of switch?
18:08.08brlcadelectric contact switch ?
18:12.14*** join/#brlcad Forth (~Forth@92.242.118.253)
18:53.45CIA-109BRL-CAD: 03128.63.32.62 07http://brlcad.org * r3213 10/wiki/Early_Raytracing_History: Stub out page for organizing early raytracing historical reports
18:55.31starseekerbrlcad: are the opengl headers present?
18:56.01starseekerwhat platform?
18:58.29brlcadI don't see any opengl headers
18:58.36brlcadit's a linux
18:59.06brlcadlooks like it's Fedora 16
19:01.26starseekerhmm.  Yeah, that's not going to be a widely tested setup
19:01.30brlcadobviously I could probably disable opengl and get past this, but implies the cmake logic isn't right if the default case doesn't properly autodetect and disable
19:01.52brlcadfedora is basically a future RHEL
19:01.52starseekerit's supposed to turn off opengl if it's not there, but I'm not surprised it's not quite right
19:02.10starseekersans-opengl machines are a rarity these days
19:02.40brlcadthis is a brand new system, so not really -- just a different type of configuration
19:03.04brlcadbrand new ibm power series
19:03.08starseekercorrection - they *should* be a rarity these days, even if they aren't
19:03.17brlcadserver platform
19:03.21starseekerstill
19:03.25brlcadservers rarely have graphics cards :P
19:03.32starseekerpeople run opengl apps on servers
19:03.56brlcadnot necessarily on compute servers
19:05.36brlcadregardless, it's a bonefide build system bug so it should get fixed...
19:23.19*** join/#brlcad Forth (~Forth@92.242.118.253)
19:47.18CIA-109BRL-CAD: 03starseeker * r47398 10/brlcad/trunk/ (3 files in 3 dirs): Tweak the OpenGL find routines to care more if the headers are found.
20:00.17cvds_brlcad: thumb controlled switch. Magnetic / optical
20:01.45brlcad~starseeker++
20:01.52brlcadthat seems to have done the trick, trying the build now
20:02.31brlcadgiggles at make -j100
20:02.57cvds_-j100 ... thats many many cores
20:03.07cvds_I run -j9 *3
20:09.22brlcadit's a 64 core server
20:09.37brlcadso it actually should be able to juggle that many efficiently :)
20:10.03brlcadlesse how long this build takes.. :)
20:10.18starseekerwinces... that's some heavy duty parallelism
20:11.05starseekerhaven't actually tried a non-opengl build for months
20:22.25CIA-109BRL-CAD: 03abhi2011 * r47399 10/brlcad/trunk/src/libged/simulate/simrt.c:
20:22.25CIA-109BRL-CAD: Some bug fixes to ray shots, now the normals for rigid body B are summed
20:22.25CIA-109BRL-CAD: correctly when there are overlapping objects : rigid body A and rigid body B.
20:22.25CIA-109BRL-CAD: Next is shooting a bunch of rays in the direction opposite to this normal, to
20:22.25CIA-109BRL-CAD: measure the depth of penetration of B into A and finally calculate the bunch of
20:22.26CIA-109BRL-CAD: contact points on the surface of B which lies inside A(due to the penetration).
20:22.27CIA-109BRL-CAD: Then we have all the required info to inject into Bullet
20:22.33CIA-109BRL-CAD: 03starseeker * r47400 10/brlcad/trunk/src/other/CMakeLists.txt: If we turn off opengl, turn off togl too
20:32.11brlcadstarseeker: hehe, we have a new winner!
20:32.12brlcadElapsed compilation time: 41 seconds
20:32.13brlcadElapsed time since configuration: 1 minute 19 seconds
20:32.21starseekerO.O
20:32.37starseekerit succeeded?
20:32.38brlcadattempts autotools for comparison
20:32.39brlcadyep
20:32.53starseekerif you're doing autotools compare, make sure you turn off the static libs
20:33.01starseeker(unless you enabled them in CMake)
20:33.40brlcadthey're default enabled in cmake, so it's fair
20:33.50starseekeronly for release config
20:34.01starseekerunless something changed, I have them off in Debug mode
20:35.15brlcadhm, hm
20:35.40starseeker(cept for opennurbs - need to fix that)
20:36.34brlcadis the summary not written out anywhere?
20:36.43starseekeryou mean to a file?
20:36.51brlcadI see nothing in the CMakeOutput.log where I'd expect it..
20:37.02starseekerno - it's just on the console
20:37.22brlcadmm, that's nfg .. there's no way to see the summary ?
20:37.48brlcadseeing AUTO in the cache tells me nothing :)
20:37.59starseekerah
20:38.26starseekercan probably write it to a file easy enough
20:38.47brlcadideally the entire cmake output
20:39.34brlcadbut minimally the summary is super helpeful for debugging, can tell people to just send you the log file and see what they saw
20:39.57starseekerI don't know of any way offhand to capture just the on-screen output of CMake
20:39.58brlcaduse config.log that way all the time
20:40.14brlcadit doesn't have to be just the output
20:40.16starseekerI can teach my summary logic to make a CMakeSummary.log file
20:40.22brlcadconfig.log is a superset, for example
20:40.42brlcadbetter to write to the existing CMakeOutput.log
20:41.11brlcadif you need someone to send you a log, you really only want to have to explain how to find/send one file
20:44.53starseekerright - I should be able to append to that file
20:45.51brlcadthree times I've been bitten by the bundled/system/auto trio
20:46.29starseekerbitten how?
20:46.35brlcadmost of the vars are on/off/auto, but the dep build flags aren't
20:46.53CIA-109BRL-CAD: 03bob1961 * r47401 10/brlcad/trunk/src/tclscripts/mged/openw.tcl: Check the display manager type before setting the zbuffer state in "proc gui"
20:47.15brlcadI configure with BRLCAD_BUNDLED_LIBS as "ON" .. and don't get them all on, defaults back to auto because I didn't enter "BUNDLED" ;)
21:24.00CIA-109BRL-CAD: 03brlcad * r47402 10/brlcad/trunk/src/ (12 files in 6 dirs): gcc continues to get smarter. apply fixes for issues detected by gcc 2.6.1, vars set but unused, unsigned 'char' that need to be int, and other type corrections.
21:24.24starseeker2.6.1?
21:24.28starseekeryow
21:26.34*** join/#brlcad merzo (~merzo@205-134-133-95.pool.ukrtel.net)
21:27.41CIA-109BRL-CAD: 03abhi2011 * r47403 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simutils.c): Need to keep track of normals encountered so far, for a ray passing through rigid_body B, otherwise the same normals added twice will skew the resultant normal direction.
21:28.37brlcadwith static: Elapsed compilation time: 57 seconds
21:29.01brlcadthough not as controlled as the first build
21:29.22brlcadlibpng is provoking some ld bug that I had to work around
21:30.37CIA-109BRL-CAD: 03abhi2011 * r47404 10/brlcad/trunk/src/libged/simulate/simrt.c: Corrected the initialization of the number of normals.
21:31.16starseekerstill - pretty darn impressive
21:31.43starseeker(or possibly impressive - perhaps autotools will do as well)
21:33.36starseekerbrlcad: does that include docbook?
21:34.59brlcadif I had the summary in a log file, I could tell you ;)
21:35.10starseekerheh
21:35.30starseekergetting close
21:35.47brlcadautotools failed in the docbook section after 3min, so presuming it's compiling the same stuff, cmake is considerably faster
21:36.53brlcadthough that's really a comparison of recursive make to non-recursive make, it's still a huge gain
21:39.47CIA-109BRL-CAD: 03starseeker * r47405 10/brlcad/trunk/ (3 files in 2 dirs):
21:39.47CIA-109BRL-CAD: Try a cute trick - override the message command to enhance logging.
21:39.47CIA-109BRL-CAD: CMakeFiles/CMakeOutput.log should now have almost all messages from the cmake
21:39.47CIA-109BRL-CAD: configure process - possible exceptions are those written out without using the
21:39.47CIA-109BRL-CAD: MESSAGE command. Also make a stab at accepting ON and OFF for the
21:39.48CIA-109BRL-CAD: AUTO/BUNDLED/SYSTEM vars
21:39.48brlcadthere we go, so yeah .. about 3min20sec for autotools, enable-all, debug, with docs (no pdf)
21:40.03brlcadthat's my usual compilation benchmark
21:40.12starseekernifty :-)
21:40.33starseekerthat's configure + build?
21:40.54brlcadconfigure was faster than cmake.. :)
21:41.05starseekerhumph - figures
21:41.33brlcadand that's not even considering that I have to run cmake three times if run via ccmake to get an enable-all build
21:41.51starseekernods - command line cmake ftw
21:41.57brlcadthe system is using ccache, so I'll have to rerun to make sure there's not some object file caching going on too
21:43.25brlcadif I could get a list of our variables from cmake (e.g., cmake --help-variables) like configure, it'd be more feasible to run via command-line
21:43.36brlcaddon't have the vars memorized
21:43.48starseekernods - I need to finish the configure.cmake script
21:44.20starseekerI've got enable-all in there, but not the static libs flag
21:44.52brlcadin where?
21:45.01brlcadoooh, wrapper
21:45.05starseekeryeah
21:45.21brlcadbleh, that's cheating :)
21:45.27starseekerhave expected you to take that and finish it so you wouldn't have to worry about the CMake options anymore
21:45.33starseeker:-P
21:46.07brlcadonly after the core system is already near-optimal
21:46.16brlcadhacking on top of hacks is bad practice
21:46.57brlcadthat goes for absolutely any code, it's only closed API that you have to put up with that
21:47.14starseekerhopes to $deity that we don't have much further to go, but suppose he knows better...
21:47.28brlcadI give it about two years
21:52.38brlcaddoesn't persist an "off" setting, otherwise looks like it's closer
21:55.33brlcadthere, more controlled rebuild was 1min38sec
21:55.49brlcadcmake, enable all (cept png), debug, with docs
21:55.55brlcadnot too shabby
21:56.08brlcaddouble that time for the three config passes
21:57.23starseekerthe second and third config passes should be considerably shorter...
21:59.27cvds_about 50% according to the previous statement ?
22:00.51brlcadthere, about 3min30sec for a repeat autotools build
22:01.10brlcadso roughly cutting the time in half or a third
22:01.46cvds_heh... using combination and oed you can cut back on a lot of solids
22:04.47CIA-109BRL-CAD: 03starseeker * r47406 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake ThirdParty_TCL.cmake): Check for on and off in the optname, not the default
22:38.06*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20111103

IRC log for #brlcad on 20111103

00:34.10CIA-109BRL-CAD: 03starseeker * r47407 10/brlcad/trunk/src/libged/simulate/simrt.c: Need unused on these parameters for now to allow strict build to succeed
01:05.58*** join/#brlcad DarkCalf (DC@173.231.40.98)
01:14.52*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
01:50.39CIA-109BRL-CAD: 03Starseeker 07http://brlcad.org * r3214 10/wiki/Early_Raytracing_History: Flesh out intro, add list of MAGIC documents (most of the links not live yet)
02:01.27*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
02:02.26Technicusello . . . I have about no extensive practical CAD or significant knowledge and I am attempting to design a cabin for a motorhome.  I am undertaking the opportunity to learn what I can with this project.  Currently I would like to start desiging the framework, would BRL-CAD be an adaquat application for this task?
02:39.25*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
03:05.08CIA-109BRL-CAD: 03Starseeker 07http://brlcad.org * r3215 10/wiki/Early_Raytracing_History: Stub in some more categories and tables, smattering of links - GIFT and BRL-CAD will have much longer lists than MAGIC!
03:23.00CIA-109BRL-CAD: 03Starseeker 07http://brlcad.org * r3216 10/wiki/Early_Raytracing_History: Another comgeom model report
03:31.10CIA-109BRL-CAD: 03Starseeker 07http://brlcad.org * r3217 10/wiki/Early_Raytracing_History: com-geom debugger
03:32.20*** join/#brlcad abhi2011 (~chatzilla@117.200.81.173)
03:37.45CIA-109BRL-CAD: 03Starseeker 07http://brlcad.org * r3218 10/wiki/Early_Raytracing_History: /* GIFT */ add another GIFT/COMGEOM application report
05:27.39*** join/#brlcad abhi2011 (~chatzilla@117.200.81.254)
05:27.54CIA-109BRL-CAD: 03abhi2011 * r47408 10/brlcad/trunk/src/libged/simulate/ (simrt.c simutils.c simutils.h):
05:27.54CIA-109BRL-CAD: Normals already encountered, were not being added to the list of normals, fixed
05:27.54CIA-109BRL-CAD: that. There are situations where summing the normals in the overlapping surface
05:27.54CIA-109BRL-CAD: alone will not give the exact direction from which a body is hitting another
05:27.54CIA-109BRL-CAD: body. But simply using the velocity also does not work for all cases to find
05:27.54CIA-109BRL-CAD: this direction. Somewhere these 2 ways need to be merged or chosen from , based
05:27.55CIA-109BRL-CAD: upon criteria.
05:34.38CIA-109BRL-CAD: 03Starseeker 07http://brlcad.org * r3219 10/wiki/Early_Raytracing_History: tweaks
05:36.59CIA-109BRL-CAD: 03Starseeker 07http://brlcad.org * r3220 10/wiki/Early_Raytracing_History: /* MAGIC */ tweak
08:22.08*** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no)
09:39.04*** join/#brlcad abhi2011 (~chatzilla@117.200.89.195)
11:50.56brlcadTechnicus: it depends on your goals, but for the basic modeling for layout and visualization, sure
11:51.26brlcadif you're hoping for it to spit out blueprints or construction parts lists, then not so adaquate
11:58.31cvds_is it possible to get the actual dimensions of a primitive from within a combination ?
11:58.40cvds_(with all matrices in the tree applied)
12:05.14CIA-109BRL-CAD: 03Caddui 07http://brlcad.org * r3221 10/wiki/NURBS_TODO:
12:25.04CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3222 10/wiki/NURBS_TODO: Reverted edits by [[Special:Contributions/Caddui|Caddui]] ([[User talk:Caddui|Talk]]); changed back to last version by [[User:Sean|Sean]]
12:25.58CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Caddui]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
12:34.07cvds_aha, using l with the full path seems to provide just that
12:45.15Technicusbrlcad: Thanks . . . that might possibly be about enough to get me started.
13:12.27*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:27.28brlcadcvds_: yep, exactly that way ;)
13:27.54brlcadyou could also clone the object, xpush, then l the primtive
13:28.34brlcadyou can get dimensions on other non-primitive objects on a line-of-sight basis using the ruler tool, the ADC angle-distance-cursor, and/or nirt
13:31.30cvds_brlcad: I can not push, same sub-combination used in other bigger combinations but rotated and translated
13:32.17cvds_i will check those other tools later /me makes mental notes.
13:32.32cvds_Now to fix a clean way for these not critical overlaps ...
13:34.17cvds_I guess I just have to clip the corners of these parts
13:36.39brlcadcvds_: xpush is not the same as push :)
13:36.51brlcadxpush will split multiply referenced objects
13:37.51brlcadI'd recommend avoiding xpush/push regardless just because you lose a localized coordinate space on the primitives, but it can be useful if you repeatedly need their values in global position
13:38.52brlcadthat's also why I suggested clone first, since that will perform a deep copy that you can "destroy" with xpush, just to peek at the values in global position
13:40.23cvds_brlcad: ah with clone, that makes sense :)
13:40.45cvds_hrmz... this design tidbit is becoming a nightmare
13:50.41*** join/#brlcad abhi2011 (~chatzilla@117.200.87.121)
14:03.05cvds_phew made it fit
14:15.28*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
14:15.40pawleeqHello
14:16.52pawleeqI have written a short article introducing BRL-CAD to wider czech public: http://www.abclinuxu.cz/clanky/brl-cad-strucne-predstaveni
14:33.33cvds_hmm copymat on the quickref says that I can copy a matrix from one path to another path... but when I try this its complaining about arcs ?
14:35.46cvds_(I want to use it to move an object to the exact space of another object so that I can subtract it)
14:46.40cvds_and googling this only finds c files
14:48.22cvds_hmm  Ensure that each argument contains exactly one slash <-- hint located
15:06.30cvds_yup that worked
16:11.14``Eriknice http://article.gmane.org/gmane.comp.version-control.git/57918
16:14.53abhi2011I am trying to use rt_gen_circular_grid() to generate a circular grid of rays (its defined in mkbundle.c)
16:15.08abhi2011int rt_gen_circular_grid(struct xrays *rays, const struct xray *center_ray, fastf_t radius, const fastf_t *up_vector, fastf_t gridsize)
16:15.50abhi2011so here gridsize is the size of the edge of the square, which bounds the circle of radius  = radius
16:16.48abhi2011I think thats the case, but I would like to be certain of that
17:02.41``Erikiirc, that func does a funky polar fill, 'gridsize' comes out to some combination of layers and radians
17:02.51``Erikso the outer rings are less dense than the inner ones
17:03.31``Erikthere was a similar one that indianlarry bolted in a few months back due to different ray density requirements, I think
17:15.53CIA-109BRL-CAD: 03abhi2011 * r47409 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simrt.c simrt.h): Started shooting for getting the depth and points on surface of object B
17:27.45*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
17:36.05abhi2011Erik: ok I thought that rays would be generated in a square grid, with those rays that lie within the circle getting accepted in the structure returned to the caller
17:37.04brlcadpawleeq: ah, that was you! .. saw that a couple days ago
17:37.12brlcadawesome
17:37.30brlcadmy czech-to-english translator totally failed on it, though :)
17:38.00brlcadlooks like ia nice detailed discussion got started
18:08.08pawleeqbrlcad: czech is quite hard to learn and even impossible for automated translators
18:12.09pawleeqthe discussion is full of trolls flaming about CATIA and how BRL-CAS is unusable for construction design
18:13.10CIA-109BRL-CAD: 03Starseeker 07http://brlcad.org * r3223 10/wiki/Early_Raytracing_History: /* MAGIC */ Add links to MAGIC docs
18:17.43CIA-109BRL-CAD: 03Starseeker 07http://brlcad.org * r3224 10/wiki/Early_Raytracing_History: /* MAGIC */ tweaks
19:21.30*** join/#brlcad abhi2011 (~chatzilla@117.200.80.114)
19:33.50CIA-109BRL-CAD: 03starseeker * r47410 10/brlcad/trunk/doc/docbook/system/man1/en/coil.xml: fix coil man page
19:35.24CIA-109BRL-CAD: 03starseeker * r47411 10/geomcore/trunk/doc/docbook/CMakeLists.txt: remove debug blather
20:10.10CIA-109BRL-CAD: 03abhi2011 * r47412 10/brlcad/trunk/src/libged/simulate/simrt.c: Trying to fix a bug related to generating a circular grid of rays along a specific direction.
20:18.17CIA-109BRL-CAD: 03brlcad * r47413 10/brlcad/trunk/include/magic.h: match BU_CKMAG()
20:20.34CIA-109BRL-CAD: 03brlcad * r47414 10/brlcad/trunk/include/fb.h:
20:20.34CIA-109BRL-CAD: fix abort on 64-bit power7 (big endian) due to bad magic number checking. the
20:20.34CIA-109BRL-CAD: cast through intptr_t was causing a zero-value to result, failing the magic
20:20.34CIA-109BRL-CAD: number test. change the macro to just treat the ifp pointer as a pointer to a
20:20.34CIA-109BRL-CAD: uint32_t and we should get the number we were looking for.
20:23.35CIA-109BRL-CAD: 03brlcad * r47415 10/brlcad/trunk/include/fb.h: dumbass. else if.
21:21.22CIA-109BRL-CAD: 03brlcad * r47416 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: don't fake the alloc. sizes might be null and we'll just bomb.
21:27.56CIA-109BRL-CAD: 03brlcad * r47417 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: do what was done for v4, validate the dsp dimensinos are non-zero
21:41.53CIA-109BRL-CAD: 03brlcad * r47418 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: vls might be null, so don't try to get the address. allow 1x1 dsp without warning. fix y-axis warning.
21:47.35CIA-109BRL-CAD: 03brlcad * r47419 10/brlcad/trunk/include/rtgeom.h: add a TODO. dsp_name should probably be a pointer so we know when it's been initialized and so the dsp struct itself will consume less memory.
21:48.09CIA-109BRL-CAD: 03brlcad * r47420 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: still have to init the vls, otherwise we can't print it even if it's empty.
21:51.14*** part/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
22:12.38CIA-109BRL-CAD: 03starseeker * r47421 10/brlcad/trunk/src/other/ (7 files in 2 dirs): Add a vanilla check-in of clipper 4.6 - Bob needs to track some tweaks he is making to it. Extra dist it until it goes live.
22:28.12*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
22:48.20brlcadstarseeker: er, you changed it from -l to -L but then documented extra detail on -l ... ;)
22:49.37CIA-109BRL-CAD: 03brlcad * r47422 10/brlcad/trunk/NEWS: cliff expanded the manpage on how the -l/-L parameter works
22:51.00brlcadah, nevermind.. misread the patch .. cool
IRC log for #brlcad on 20111104

IRC log for #brlcad on 20111104

02:13.17*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
02:13.49*** part/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
10:32.55CIA-109BRL-CAD: 03Fywijydoze 07http://brlcad.org * r3225 10/wiki/Uk_essays: New page: All students obviously want to imppress their teachers but not always want to do their best. Better let anyone else do monkey job for them. Writing essays is boring and takes a lot of time...
11:57.31*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
12:21.41CIA-109BRL-CAD: 03bob1961 * r47423 10/brlcad/trunk/src/other/clipper/ (clipper.cpp clipper.hpp): Eliminate using == and != to compare doubles. Now using CLIPPER_NEAR_ZERO and CLIPPER_NEAR_EQUAL. Also fixed a few syntax errors.
12:53.22CIA-109BRL-CAD: 03bob1961 * r47424 10/brlcad/trunk/src/other/clipper/ (clipper.cpp clipper.hpp): Added methods to overload the AddPolygon and AddPolygons methods for adding ExPolygons.
13:29.05*** join/#brlcad abhi2011 (~chatzilla@117.200.85.105)
13:49.14CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Uk essays]]": a$$hole
13:49.29CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Fywijydoze]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
13:51.10*** join/#brlcad abhi2011 (~chatzilla@117.200.86.161)
13:54.52*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
16:30.35*** join/#brlcad abhi2011 (~chatzilla@117.200.87.255)
17:19.11CIA-109BRL-CAD: 03brlcad * r47425 10/brlcad/trunk/src/libbn/ (CMakeLists.txt Makefile.am README): add a basic readme for libbn so I can document the list of core functions heavily used during tessellation identified by richard.
17:37.39CIA-109BRL-CAD: 03brlcad * r47426 10/brlcad/trunk/ (6 files in 4 dirs): move and remove rt_dist_pt3_line3 from librt's nmg_misc.c to libbn's plane.c where it's in better/related company. minimally impacting change for the upcoming minor release.
17:48.48CIA-109BRL-CAD: 03brlcad * r47427 10/brlcad/trunk/src/libbn/README: renamed to bn_dist_pt3_line3
17:54.26starseekerbuild busted...
17:55.23starseekerah
17:55.37CIA-109BRL-CAD: 03starseeker * r47428 10/brlcad/trunk/include/bn.h: Should be BN_EXPORT here
18:00.26brlcadsorry about that -- I'd already fixed it locally but you beat me to the commit
18:00.46CIA-109BRL-CAD: 03brlcad * r47429 10/brlcad/trunk/ (7 files in 5 dirs): also migrate the remaining two API smells from librt to libbn: rt_dist_line3_line3 and rt_dist_line3_lseg3. minimally impacting.
18:04.52*** join/#brlcad abhi2011 (~chatzilla@117.200.82.44)
18:09.06starseekernp
18:12.31CIA-109BRL-CAD: 03starseeker * r47430 10/brlcad/trunk/include/bn.h: need semicolon here
18:15.47CIA-109BRL-CAD: 03starseeker * r47431 10/brlcad/trunk/src/libbn/plane.c: we're in libbn, so used the same debug triggers as other bn functions...
18:18.53starseekerthere we go :-)
18:56.15abhi2011hm I am getting linking errors in windows
18:57.01abhi2011http://bin.cakephp.org/view/1262657315
18:57.46abhi2011probably not linking to opengl in someway
19:05.23brlcadthat's exactly what's happening
19:06.08brlcadit's on the issttcltk binary, so it may simply be a lib missing from that build file
19:08.49brlcadabhi2011: try that
19:08.50CIA-109BRL-CAD: 03brlcad * r47432 10/brlcad/trunk/src/adrt/CMakeLists.txt: do the same hack that libfb uses, specify the .lib file for opengl explicitly, even though it should be added by the OPENGL_LIBRARIES var
19:31.32abhi2011brlcad: thanks ! that worked :)
19:39.04brlcadgreat
19:39.05CIA-109BRL-CAD: 03abhi2011 * r47433 10/brlcad/trunk/src/libged/simulate/simrt.c: Generating a circular bundle of rays to shoot in the direction of the resultant normal by calling rt_gen_circular_grid() through a BU_LIST
19:39.48brlcadmaybe starseeker can add the proper juju to test for and link opengl32.lib
19:40.36CIA-109BRL-CAD: 03abhi2011 * r47434 10/brlcad/trunk/src/libged/simulate/simrt.c: woops, must free the list too.
19:41.16abhi2011yes, cmake would return opengl32.lib correctly I think
19:42.34abhi2011the Bullet project seems to now have support for premake as well
19:43.11abhi2011some debates on about cmake vs premake :P
19:44.16abhi2011http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=7445
19:44.52abhi2011a more interesting one : http://altdevblogaday.com/2011/03/13/meta-build-systems/
20:19.17CIA-109BRL-CAD: 03abhi2011 * r47435 10/brlcad/trunk/src/libged/simulate/simrt.c: Circular bunch of rays are being generated correctly, time to shoot 'em.
20:24.07brlcad"Unfortunately, the main cmake developers don?t want to support distributable project file generation, and I felt they were very reluctant to discuss further changes to support distributable project files."  <-- very sad
20:48.04abhi2011yeah, but that may just be a bit overboard,  maybe they want to just stabilize the current code base :)
20:48.22abhi2011before adding features
21:39.24*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
21:42.26CIA-109BRL-CAD: 03n_reed * r47436 10/brlcad/trunk/src/other/re2c/ (CMake/FindLEMON.cmake parser.y.lemon): working on lemon input to replace re2c's yacc input
22:15.25*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
22:38.03starseekerabhi2011: no, I've had that conversation with the CMake list as well
22:38.26abhi2011oh ok
22:38.48abhi2011so I have a question regarding a warning I keep getting in the windows build
22:38.56starseekerthey're not going to re-engineer CMake to be able to work without CMake being present - they use the CMake executable itself as a cross-platform substitute for a lot of things
22:39.30starseekerhaving to use OS specific tools for that is a considerable complication, and I'm not surprised they want to avoid it
22:39.42starseekerwhat's the warning?
22:39.59abhi2011ok
22:40.03abhi2011<PROTECTED>
22:40.03starseekerexpects there are a few build flags floating around that MSVC doens't understand...
22:40.04abhi20114>        f:\code\socis\brlcad\include\common.h(252) : see previous definition of 'IGNORE'
22:40.16starseekeroh, that one
22:40.30abhi2011so I tried putting common.h on the top of all my files
22:40.36starseekernods - correct
22:40.37abhi2011but that doesnt seem to solve the issue
22:40.45starseekerreally...
22:41.16abhi2011I guess the macro will still be defined in both places, because the winbase.h files is included after again
22:41.48starseekeruh... why is it getting included again?
22:42.38abhi2011hmm, no its probably not
22:43.06abhi2011but somewhere both are conflicting
22:43.24abhi2011let me check common.h
22:48.19abhi2011hmm I can find winbase.h only in the binaries in the cmake build directory
22:48.36abhi2011so they must be getting included in some source file
22:53.45abhi2011hmm, an include is there in ./other/tcl/win/tclWinInit.c:#include <winbase.h>
23:00.55CIA-109BRL-CAD: 03abhi2011 * r47437 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Got the contact points, removed some unnecessary older code, now they need to inserted correctly in Bullet. Need to check if the area of the contact points need to be maximized.
23:01.46starseekerthe bullet headers aren't pulling it in anywhere?
23:05.28abhi2011they probably are :P
23:07.10starseekerwonders how to suggest to Microsoft that it add support to Visual Studio for CMake projects directly... AFAIK the license would all them to bundle the CMake engine under the hood and just eat the CMakeLists.txt projects directly...
23:08.00abhi2011yes
23:08.02starseekers/all/allow
23:08.54starseeker*really* doesn't want to see Bullet switch off of CMake - that just means we'd have to pick up maintaining it - growl
23:11.10starseekerhmm... I suppose we could spam this site... http://visualstudio.uservoice.com/forums/121579-visual-studio/category/35066-ide
23:12.21starseekerand tell them to make the clang compiler an option here... http://visualstudio.uservoice.com/forums/121579-visual-studio/category/30937-languages-c-
23:15.22abhi2011yep I ll put the word in there :)
23:15.39abhi2011I just get winbase.h in binary files though
23:15.58abhi2011seems like the compiler is putting it in the .pdb and .idb files
23:16.11abhi2011which I think are debugging symbol databases
23:17.02abhi2011hmm .obj files too
23:22.10brlcadabhi2011: the issue is where winbase.h is getting included
23:22.27brlcadyou have to put a wrapper around whatever is including it
23:22.48brlcadwe wrap all the places I know if in our headers where windows headers get included
23:23.02brlcadfind where it's getting included, then it can be fixed
23:23.23abhi2011yes, I searched the source directory of bullet and the build directory, same for brl-cad directories, didnt find it anywhere
23:23.35brlcadnot likely going to find it that way.. :)
23:23.48abhi2011grep :)
23:24.01abhi2011well I did grep through them
23:24.08brlcadgrep will only work if you're grepping the right header files
23:24.30abhi2011yeah I grepped at the top level source folder
23:24.36abhi2011and include folder too
23:24.39brlcadI suspect winbase.h is getting included indirectly by some *other* windows header, perhaps by even some other header still, then getting included in source
23:24.40abhi2011will try once more
23:24.47abhi2011yeah
23:24.50abhi2011maybe windows.h
23:24.59abhi2011in the visual c++ includes
23:25.01brlcadgrepping for winbase.h isn't useful, nor is guessing :)
23:25.10brlcadyour files are short, only include a few files
23:25.43brlcadput an #undef IGNORE before the last header, compile -- see if error goes away
23:25.55brlcadassuming it doesn't, move #undef up before the next-to-last header, repeat
23:26.04abhi2011ah ok
23:26.24brlcadrepeat until you find which one makes the error go away, if it's one of your headers, then repeat the whole process on the #includes within that header
23:26.28brlcadsame if it's one of ours
23:26.44brlcadif it's one of bullet's then you have your inclusion point
23:26.56abhi2011ok
23:27.01brlcadonce you find it, then you can wrap that header with protections like we use in include/bin.h
23:27.15brlcadit's about 5 or 6 lines
23:28.53abhi2011ok
23:29.04abhi2011yes I ll try that :)
IRC log for #brlcad on 20111105

IRC log for #brlcad on 20111105

02:05.38*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
02:16.51*** join/#brlcad abhi2011 (~chatzilla@117.200.84.170)
05:29.26CIA-109BRL-CAD: 03abhi2011 * r47438 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c simulate.h): Cleaned up some redundant code and completed contact point generation logic.
06:45.02*** join/#brlcad abhi2011 (~chatzilla@117.200.92.33)
07:44.22CIA-109BRL-CAD: 03abhi2011 * r47439 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c simulate.h): Fixing some bugs in the contact generation logic.
09:15.33CIA-109BRL-CAD: 03Johnjones 07http://brlcad.org * r3226 10/wiki/Main_Page: minor edit
09:17.38*** join/#brlcad abhi2011 (~chatzilla@2002:6ee3:d46a::6ee3:d46a)
12:56.34CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3227 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Johnjones|Johnjones]] ([[User talk:Johnjones|Talk]]); changed back to last version by [[User:Sean|Sean]]
12:56.37CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Johnjones]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
13:25.55*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:51.28*** join/#brlcad abhi2011 (~chatzilla@117.200.88.67)
14:00.23abhi2011finally, the box-box case seems to be working : http://imageshack.us/photo/my-images/407/force.png/
14:00.30abhi2011one box falling on another
14:01.02abhi2011this is using contact points, normals, and penetration depth only(all 3 got using raytracing)
14:01.31abhi2011except for the normal which is simply the velocity direction
14:02.05abhi2011of whichever body, Bulletr considers to be body B in a colliding pair
14:02.22abhi2011s/Bulletr/Bullet
14:04.38abhi2011will try dropping a sphere now and check if the manifold is generated at the correct point on its surface
14:13.07CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3228 10/wiki/User:Abhijit: /* Log : Nov 5th */
14:15.37brlcadabhi2011: that is totall awesome :)
14:16.04abhi2011woops, bad screen shoot :P
14:16.17abhi2011*shot
14:17.21CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3229 10/wiki/User:Abhijit: /* Log */
14:19.03abhi2011so the linear velocity approach you suggested , helps avoid a lot of raytracing and thus each iteration is much faster
14:19.57abhi2011a slowdown is evident only when a big box falls directly on an even larger box, in which cased the contact region is quite large and a large number of rays need to be shot
14:21.07abhi2011it can be optimized however by shooting rays inwards from the periphery of the overlap region and as soon as about 4 points are got, the density of the rays can be reduced (for shooting near the inner regions etc)
14:21.23abhi2011maybe it can be yet be optimized to real time :)
14:33.14brlcadshould be possible -- the biggest time is going to be prep setup
14:34.48brlcadwithout prep, you could shoot 100000 rays and still remain interactive on most models
14:35.54CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3230 10/wiki/User:Abhijit: /* Log */
14:36.28abhi2011so you mean, I should not prep ?
14:37.01abhi2011since the bounding box function will work without prep
14:37.09brlcadyou have to prep :)
14:37.17abhi2011oh hmm :P
14:37.25brlcadwell, you have to prep to shoot rays
14:37.33abhi2011yeah for rt , have to prep
14:37.40brlcadif the boxes don't even overlap, then definitely .. don't prep, don't shoot rays :)
14:37.51abhi2011yes
14:39.01abhi2011if the boxes move even by a millimeter, there is no way to update a tiny part of the model saved for raytracing, (after prep ) ?
14:39.33abhi2011so like, if anything moves, the raytracing process needs to be done all over again ?
14:41.07abhi2011I do that currently, but was wondering if its at all possible to modify a part of the model and then prep only that part (after the whole scene is prepped, but something has moved - in the next physics iteration, )which would be faster
14:43.20CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3231 10/wiki/User:Abhijit: /* Log Nov 5th, more info */
14:43.54brlcadyeah, we've talked about adding support for cache objects but it's a fairly complex subject
14:44.03abhi2011ok
14:44.28brlcadyou'd have to cache per object and have some way to quickly determine whether a cache is invalid and for even medium-sized objects, it's almost faster to just reprep
14:44.30abhi2011possible a warm start kind of thing, rather than a complete cold start from scratch each time
14:44.47abhi2011oh ok
14:45.04brlcadthe dominant time is setting up the spatial partitioning, which does have to change with every change to the scene
14:45.29abhi2011but will it change drastically for millimeter scale movements
14:45.42brlcadno way to know
14:45.50abhi2011ok
14:46.04brlcadif it pops into a different cell, it could be a drastic change to the spatial partitioning
14:46.14abhi2011yeah
14:46.31brlcadwould have to employ a completely different spatial partitioning algorithm, something more tuned for incremental updates
14:46.52abhi2011ok
14:47.03brlcadgenerally don't perform as well for static scenes, but they can be updated more quickly ...
14:47.07brlcadsomething maybe for down the road
14:47.25abhi2011yes :)
14:47.29brlcadbut I suspect cpus will be faster before that happens to the point that it won't matter or some other solution will present itself ;)
14:47.40abhi2011hehe yeah , true
14:48.05brlcadthat new power7 server I was playing with earlier in the week was impressive, giving about 512x512 at 30fps
14:48.22brlcad30fps raytraced :)
14:48.40abhi2011oh wow
14:49.00abhi201164 cores you said ?
14:49.11brlcadnot the fastest I've seen, and you can get a WHOLE lot faster with polygonal models, but for full shotline (solid) raytracing, that's pretty impressive
14:49.27abhi2011ok
14:49.36brlcadyeah, 64 cores
14:49.39abhi2011how many solid were there in the scene
14:50.30brlcadtechnically I believe it's 8 cpus with 2 cores per cpu and 4 asynchronous threads per core
14:50.59abhi2011ok
14:51.15brlcadso not much faster than the fastest workstation you can already buy today
14:52.14brlcadmaybe a dozen solids, it wasn't a huge model, but even a complex model with a few thousand regions (and thousands of prims) was >10fps iirc
14:52.42abhi2011oh , thats pretty cool :)
14:52.46abhi2011<PROTECTED>
14:52.50abhi2011caustic rt i think
14:53.07abhi2011on FPGAs
14:53.12brlcadyeah, there's a bunch of them
14:54.00brlcadthe stats become completely different when you only consider triangle mesh models, and even further still only consider making pretty pictures (i.e., first hit only)
14:54.26brlcadboth things that *substantially* make things faster, but aren't practical for analysis or solid ray tracing
15:57.37starseekerponders trying to get his hands on an IBM T221
17:17.37starseeker``Erik: know anything about how to hook up a T221 to a modern machine?
17:31.22cvds_is there an easy way to combine rpp with 2 arb6 in between ?
20:07.03*** join/#brlcad abhi2011 (~chatzilla@117.200.80.159)
20:51.00*** join/#brlcad abhi2011 (~chatzilla@117.200.80.107)
IRC log for #brlcad on 20111106

IRC log for #brlcad on 20111106

01:45.37*** join/#brlcad abhi2011 (~chatzilla@117.200.83.94)
07:20.18*** join/#brlcad abhi2011 (~chatzilla@117.200.83.219)
10:29.56cvds_just omitting the 2 arb6 and just use and arb8 as the center part makes it a lot easier
11:47.30*** join/#brlcad abhi2011 (~chatzilla@117.200.83.227)
11:56.43*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
12:34.58*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
12:55.05*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
13:24.07*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:39.45``Erikstarseeker: no... 3840x2400, impressive... wiki page says it's several dvi plugs striped together, the 221 has linux drivers, even... just make sure you have enough DVI out ports to drive it? *shrug*
13:42.49``Erik(204dpi, not bad at all... overkill, even... human discrepency is roughly 287 dpi at 1' distance, iphone4 is 324dpi, average monitor I believe is 72dpi...)
14:26.27starseekernods - I'm thinking at 204ppi, I'd never need another monitor until it died for some reason :-)
14:26.41starseeker(or I couldn't connect it to modern hardware, I suppose...)
14:27.21starseekerhad better not die, considering they don't make 'em anymore... grr
14:28.21starseekerbasically the monitor equalivent to my Model M keyboard :-)
14:29.16cvds_Model M that is a good keyboard
14:30.13starseekerstill has and uses an original - probably will have to switch to one of the newer ones I got a while back because they're discontinuing the old-style connectors and this sucker draws too much power for a USB plug
15:11.02*** join/#brlcad merzo (~merzo@42-90-132-95.pool.ukrtel.net)
17:05.54*** join/#brlcad abhi2011 (~chatzilla@117.200.80.176)
IRC log for #brlcad on 20111107

IRC log for #brlcad on 20111107

03:24.29*** join/#brlcad abhi2011 (~chatzilla@117.200.80.247)
05:00.19starseekerbhinesley: iirc, you had the translate functions fully working in edit?
05:00.35bhinesleystarseeker: correct
05:00.58starseekerhow much was remaining for the rotation part?
05:01.19bhinesleyI'd written the mock manual for it, but that's it
05:01.25starseekernods
05:02.10starseekerthat's a good start
05:02.51starseekerwould be curious to hook up edit under MGED's mouse-based translation
05:03.33starseekerwe have had bugs reported for a long time about the movement getting into a bizarre state under certain conditions, but not reproducibly
05:03.53starseekerwonder if using edit under the hood might avoid them
05:06.43bhinesleyblows off dust
05:06.57bhinesleyI should probably reevaluate this manual, now that translate is running
05:07.13bhinesley*rotate manual
05:08.03bhinesleyit's been a while, and rotate is pretty complex
05:13.21bhinesleybrlcad: Fall qtr ends in 3 weeks, and I'll have 6 weeks off before Winter. It would be a good time to consider any potential refactoring of edit.c, before I get going on rotate.
07:14.40*** join/#brlcad OvaleZ (~OvaleZ@213.5.25.68)
07:17.11OvaleZHello all! Help me please. I trying to compile latest release 7.20.4 of BRL-CAD on Windows 7 using mingw32 and cMake 2.8.6.  This is correct way to compile under windows? now i have some error...  What tools you are used to compile BRL-CAD for windows? Thx
07:35.31*** join/#brlcad abhi2011 (~chatzilla@117.200.94.164)
07:40.01*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:57.34*** join/#brlcad abhi2011 (~chatzilla@117.200.89.171)
10:53.30*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
16:34.31*** join/#brlcad ibot (~ibot@rikers.org)
16:34.31*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
18:13.06CIA-109BRL-CAD: 03starseeker * r47444 10/brlcad/trunk/src/other/ (5 files in 5 dirs): Keep all the FindX11.cmake files consistent.
18:34.53starseekerhah, cool:  http://www.scientificamerican.com/article.cfm?id=sticky-situation-gecko-toe-adhesive
19:16.57*** join/#brlcad merzo (~merzo@214-221-132-95.pool.ukrtel.net)
20:40.29CIA-109BRL-CAD: 03n_reed * r47445 10/brlcad/trunk/src/other/re2c/parser.y.lemon: finished bison to lemon syntax converion
22:05.53CIA-109BRL-CAD: 03n_reed * r47446 10/brlcad/trunk/src/other/re2c/parser.y.lemon: suppress errors by using precedence information to make default conflict resolution explicit
23:04.31*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20111108

IRC log for #brlcad on 20111108

03:14.20*** join/#brlcad abhi2011 (~chatzilla@117.200.85.212)
03:16.09abhi2011hmm getting a strange raytracing result : http://imageshack.us/photo/my-images/849/forceh.png/
03:16.30abhi2011overlaps being reported where objects do not appear to overlap at all
03:16.57abhi2011some mistake in loading the objects into the raytracing instance
04:12.09CIA-109BRL-CAD: 03abhi2011 * r47447 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simrt.c simrt.h simulate.c):
04:12.09CIA-109BRL-CAD: Changed the location of raytrace initialization to the main simulate file in an
04:12.09CIA-109BRL-CAD: attempt to eliminate as many function calls as possible and get to the bottom of
04:12.09CIA-109BRL-CAD: why objects appear to be in a different location in the rt_i as compared to the
04:12.09CIA-109BRL-CAD: one shown by mged.
04:39.58*** join/#brlcad abhi2011 (~chatzilla@117.200.85.212)
04:42.09abhi2011hmm shooting the saem ray with nirt in mged gives no overlap where there are no overlaps shown visually
05:35.28*** join/#brlcad abhi2011 (~chatzilla@117.200.91.67)
06:45.51*** join/#brlcad abhi2011 (~chatzilla@117.200.83.165)
07:19.22abhi2011hmm neither nirt in mged, or nirt running in the command line , on the same db file shows overlaps for a ray particular ray origination point and direction
07:20.14abhi2011yet when I rt_gettree() the same regions into a new rt_i  and shoot the same ray, an overlap gets reported
07:26.42*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
07:47.31*** join/#brlcad abhi2011 (~chatzilla@117.200.83.246)
07:52.47CIA-109BRL-CAD: 03d_rossberg * r47448 10/brlcad/trunk/ (4 files in 3 dirs):
08:23.24*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:24.14d_rossbergnmg_copy.c doesn't compile with gcc yet, i should be able to fix it today ...
09:05.06*** join/#brlcad abhi2011 (~chatzilla@117.200.93.18)
10:00.54*** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com)
10:07.44CIA-109BRL-CAD: 03d_rossberg * r47449 10/brlcad/trunk/src/librt/primitives/nmg/nmg_copy.c: quell gcc warnings/errors: 1st iteration
13:44.29*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
14:50.14*** join/#brlcad abhi2011 (~chatzilla@117.200.81.70)
15:50.32*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
15:51.10*** join/#brlcad abhi2011 (~chatzilla@117.200.88.16)
17:15.22*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
17:15.23*** join/#brlcad Technicus|2 (~Technicus@DSLPool-net208-2.wctc.net)
17:31.31*** join/#brlcad abhi2011 (~chatzilla@117.200.88.16)
18:36.26CIA-109BRL-CAD: 03indianlarry * r47450 10/brlcad/trunk/src/anim/anim_script.c: End condition for reading file buggered up, added count of needed fields for scanf() based on program options.
18:36.59*** join/#brlcad abhi2011 (~chatzilla@117.200.80.170)
18:42.14CIA-109BRL-CAD: 03indianlarry * r47451 10/brlcad/trunk/src/tclscripts/mged/anim.tcl: CAD object not used when processing "view" script so don't test existence in "view" case.
18:46.17*** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com)
21:24.44CIA-109BRL-CAD: 03n_reed * r47452 10/brlcad/trunk/src/other/re2c/parser.y.lemon: type corrections and casting; yyparse calls lemon parser
21:31.23*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20111109

IRC log for #brlcad on 20111109

01:16.58starseekerwoo hoo!  http://gitorious.org/boost/cmake/trees/cmake-1.47.0
01:17.04starseekerdoes happy dance
01:20.16starseekerbuilds successfully too
02:20.43starseekerIdea:  Could we put a CMakeified Boost into our svn repo and use svn:external to pull that as part of a checkout?  Then people using a system Boost could just do svn co --ignore-externals and not have to pull Boost at all
02:59.46*** join/#brlcad abhi2011 (~chatzilla@117.200.80.166)
03:03.28*** join/#brlcad abhi2011 (~chatzilla@117.200.80.166)
03:32.50*** join/#brlcad ibot (~ibot@rikers.org)
03:32.50*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
03:57.07abhi2011yippeee!!!, the sphere - sphere case also works :), wasnt unitizing the direction vector while shooting rays !
03:58.05abhi2011just cant seem to get out of the newbie group :P with rt
04:01.43CIA-109BRL-CAD: 03abhi2011 * r47453 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c): Committing the code used to debug errors in generating manifolds using rt, in case I need to get back to it again quickly later.
04:10.04CIA-109BRL-CAD: 03abhi2011 * r47454 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c): Now the proper working code with all debugging stuff removed.
04:12.02abhi2011http://imageshack.us/photo/my-images/406/forceb.png/
04:15.51CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3232 10/wiki/User:Abhijit: /* Log */
04:37.13starseekerabhi2011: any chance of making a video with the spheres?
04:37.38abhi2011starseeker: yes I am working on that
04:37.43starseekersweet!
04:38.11abhi2011I need the spheres to overlap somewhat , to generate contact points and rt does some wierd colors when objects overlap
04:38.48abhi2011but it should be ok for small velocites
04:39.08starseekerhmm.  So it's not actually a "true" contact test but a "slightly intersecting" test?
04:39.27abhi2011yes thats right
04:39.50abhi2011because rt will create contact points based on the overlap area
04:40.06abhi2011or rather to put it better
04:40.42abhi2011I can create contact points using rt, only when they overlap
04:41.20starseekerwould it be possible to use the intersecting rays to "back up" just to the point where the longest intersecting ray becomes zero, and proceed again from there using the information?
04:41.22abhi2011as the rays report overlap regions
04:42.30abhi2011by becoming zero you mean, there is no overlap region reported for the longest overlapping ray ?
04:42.39starseekersomething like that
04:42.44abhi2011*longest ray
04:42.46abhi2011ok
04:42.50starseekerjust a thought
04:42.56abhi2011yes I think it should be possible
04:43.14starseekerbasically the idea would be to not have to solid things "merge slightly" when interacting...
04:43.26abhi2011yes, I was also thinking that if 2 objects are very close to each other
04:43.27starseekerbut I don't know if that's compatible with the approach - just a random thought
04:43.35abhi2011then the air gap will be very small too
04:43.46abhi2011so if I shoot rays in their overlap region
04:43.57abhi2011and check for the smallest air gap
04:44.18abhi2011then at a certain points ...say 0.04 mm, I could generate the points
04:44.44abhi2011then the objects have not yet physically intersected as there is still small air gap between them
04:44.49starseekernods
04:45.27starseekermay not need to ensure an air gap even - just stray thoughts
04:45.31starseekeryou're the expert :-)
04:45.44abhi2011currently I seem to have an issue with 2 objects penetrating too much into each other, if alowed to do so, when they have high relative velocities
04:46.01abhi2011hehe, yep all ideas help :)
04:46.19starseekerwell, it is "bullet" ;-)
04:46.30abhi2011hehe yeah
04:47.06abhi2011ok I ll make 2 vids, one with a sphere dropped from a low altitude
04:47.15abhi2011and an another from a high one
04:47.18abhi2011and see what happens
04:47.22starseekersweet
04:47.34starseekerstill fantastic progress
04:47.42abhi2011thanks :)
04:47.59abhi2011cant wait to try the billiard table case with custom forces :P
04:48.04starseekerwho knows - brlcad might even think up some scenarios where overlapping would be useful
04:48.08starseekerhehe :-)
04:48.22starseeker"BRL-CAD - now, with pool simulations!"
04:48.48abhi2011:)
04:49.02abhi2011so , there is this powerful server everyone keeps talking about
04:49.09abhi2011bullet is not installed there ?
04:49.14starseekerum
04:49.16starseekerdunno
04:49.25starseeker``Erik: we have a powerful server?
05:19.27*** join/#brlcad abhi2011 (~chatzilla@117.200.82.100)
06:05.19*** join/#brlcad abhi2011 (75c85d7f@gateway/web/freenode/ip.117.200.93.127)
07:38.43*** join/#brlcad abhi2011 (~chatzilla@117.200.89.207)
07:41.18abhi2011http://www.youtube.com/watch?v=nrOtSd07rCY
07:41.25abhi2011this is with slow striking spheres
07:42.33abhi2011the reaction force from the sphere at the bottom is straight upwards, opposite to the velocity of the upper sphere
07:42.55abhi2011yet , it does not seem correct as the reaction should be at 45 degrees to the vertical
07:43.22abhi2011so I ll try with the summing normals at the overlapping region approach and check if that gives better results
07:44.49abhi2011for fast moving sphere , this more of an issue, as a fast sphere suddenly penetrates deep into the lower sphere : http://www.youtube.com/watch?v=7cZesIJapF4
07:45.10abhi2011causing a sudden high reaction force
07:45.22abhi2011which does not seem correct either
07:45.33abhi2011will try and figure out a solution
07:49.57*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
07:50.03CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3233 10/wiki/User:Abhijit: /* Log */
07:50.47CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3234 10/wiki/User:Abhijit: /* Log */
07:51.29CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3235 10/wiki/User:Abhijit: /* Log */
08:46.50CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3236 10/wiki/User:Abhijit: /* Log Nov 9th */
08:50.21CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3237 10/wiki/User:Abhijit: /* Updated Development Time line(Oct 6th) */
08:50.50CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3238 10/wiki/User:Abhijit: /* Updated Development Time line(Nov 9th) */
08:57.04CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3239 10/wiki/User:Abhijit: /* Log */
09:02.09CIA-109BRL-CAD: 03abhi2011 * r47455 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c): Switched to summing of normals approach to generate contact pairs. Added a #define to switch back to velocity based generation quickly if needed.
09:15.07CIA-109BRL-CAD: 03Abhi2011 07http://brlcad.org * r3240 10/wiki/User:Abhijit: /* Log */
09:54.30*** join/#brlcad abhi2011 (~chatzilla@117.200.80.178)
12:10.47``Erikstarseeker: he might be referring to the new gcc compile farm machine that brlcad was playing on? I think it's 64 power7 cores?
12:12.09``Erikhttp://gcc.gnu.org/wiki/CompileFarm   gcc110... 64 power7 cores at 3.55ghz, 64g ram, fedora ppc64
12:13.55``ErikI see brlcad logged into it right now, and the load is 0... altivec capable, even
12:16.11``Erikwould guess a hair over half a million VGR's
12:17.36``Erikwe also have the cat machines, those're 16 xeon cores a whack, not exactly chump change
12:23.11``Erikhm, abhi isn't here
12:34.40``Erikffs, this email is going to be a book.
13:54.36*** join/#brlcad abhi2011 (~chatzilla@117.200.87.72)
13:58.44abhi2011``Erik: Thanks for the mail :)
13:58.57abhi2011very insightful
13:59.14abhi2011trying to digest all the info now
14:02.35starseekerabhi2011: nifty video!
14:03.01abhi2011hehe, I ll try n pop in a few more stuff
14:03.04starseekeragree it's not quite right, but still nice progress!
14:05.12abhi2011hmm, so the basic idea now is to do zero penetration physics
14:05.19abhi2011or to recover from penetration
14:08.32abhi2011hehe, agree on the "fairly gross simplifications of geometry" part  player characters :P
14:08.35*** join/#brlcad merzo (~merzo@193.254.217.44)
14:08.54abhi2011I think bullet uses just a capsule shape for a player, rotating it or making it jump as needed
14:08.55``Erik:D most of my background comes from old (quake2 era) video games, so take it with a fat grain of salt
14:09.37abhi2011:), yeah me have never done it, so any info is useful
14:09.39``Erikback when I was doing it, the 'hot' thing was to have the entire character represented by a stretched sphere
14:09.47abhi2011ok
14:10.35``Erikthe capsule supposedly better represents *shrug*
14:10.48``ErikI tried to cc brlcad and starseeker, not sure if they got 'em
14:11.13``ErikI think brlcad won't be back until next week, maybe :/
14:11.13abhi2011ok, hmm, yes, for large time delta, bullet breaks up the update into smaller internal sub steps
14:11.20abhi2011oh ok
14:12.15abhi2011was thinking about the " extending the boundary of an object slightly"  idea though
14:12.26abhi2011I think bullet does it with the basic shapes it uses
14:12.41abhi2011but I guess trying that approach for brl-cad shapes would be tough
14:13.31``ErikBRL-CAD provides both a bounding sphere and aabb for each primitive, both are easy to extend
14:13.32abhi2011'cause the entire periphery of an object would need to be detected and extended
14:14.09abhi2011ok
14:14.50abhi2011so  a ray shot though the primitive, would give the exit point a little but further along than , it would , without extension
14:15.01abhi2011and the entry point a little bit earlier
14:15.19``Erikoh, and http://brlcad.svn.sourceforge.net/viewvc/brlcad/rtcmp/trunk/rt/rt.c?revision=34030 is about as simple as you're going to get for ray-tracing in BRL-CAD, the 'hit' function is more complex than you need, but the rest should be minimal
14:16.05abhi2011ok
14:20.22abhi2011``Erik: so by "solve the impulse vector", you mean calculating the reaction force from the collision , by using change in momentum etc ?
14:29.12``Erikyeh, though thinking, the resultant velocity vector is what you actually want in the end, not just the delta *shrug*
14:37.56abhi2011well yes
14:38.25abhi2011actually I let Bullet calculate the resultant velocity :)
14:38.32abhi2011I just give it a resultant normal
14:38.38abhi2011pointing from object A to B
14:48.36*** join/#brlcad piksi (piksi@pi-xi.net)
14:54.23*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:20.32CIA-109BRL-CAD: 03bob1961 * r47456 10/brlcad/trunk/src/other/clipper/ (clipper.cpp clipper.hpp): Updates from Angus.
17:37.24*** join/#brlcad abhi2011 (~chatzilla@117.200.80.182)
17:37.39CIA-109BRL-CAD: 03bob1961 * r47457 10/brlcad/trunk/src/tclscripts/mged/skt_ed.tcl: Update calls to dist and find_arc_center to reflect the fact that they are no longer in the Sketch_editor namespace.
18:32.43CIA-109BRL-CAD: 03starseeker * r47458 10/brlcad/trunk/src/conv/g-obj.c: Faces were all using the same value due to variable i not being changed in the loop... report from Christopher Pitts, bug tracker #3435642
19:13.47CIA-109BRL-CAD: 03bob1961 * r47459 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added a method for "l". The "g" command will now expand it's argument list.
19:22.12*** join/#brlcad merzo (~merzo@91-101-133-95.pool.ukrtel.net)
21:43.15``Eriknice. http://technet.microsoft.com/en-us/security/bulletin/ms11-083
21:43.41``Erikpossible remote code execution by dumping udp packets at a target machine.
22:17.59CIA-109BRL-CAD: 03n_reed * r47460 10/brlcad/trunk/doc/bison_to_lemon.txt: minor update on aliases
22:53.06CIA-109BRL-CAD: 03n_reed * r47461 10/brlcad/trunk/src/other/step/CMake/FindLEMON.cmake: add modified lemon_target macro
22:58.52CIA-109BRL-CAD: 03n_reed * r47462 10/brlcad/trunk/src/ (2 files in 2 dirs): modified CMakeLists for alt lemon macro
23:41.34CIA-109BRL-CAD: 03starseeker * r47463 10/brlcad/trunk/ (4 files in 4 dirs): Get the FindLEMON logic working with the new paradigm (specifying the target header file)
23:53.11CIA-109BRL-CAD: 03n_reed * r47464 10/brlcad/trunk/src/other/re2c/ (6 files in 2 dirs): switched re2c yacc parser with lemon parser
23:58.07CIA-109BRL-CAD: 03n_reed * r47465 10/brlcad/trunk/src/other/step/ (CMake/FindYACC.cmake CMakeLists.txt): FindYACC no longer used; removed
IRC log for #brlcad on 20111110

IRC log for #brlcad on 20111110

00:17.04CIA-109BRL-CAD: 03starseeker * r47466 10/brlcad/trunk/src/other/re2c/CMakeLists.txt: need the lemon bootstrap before doing the re2c bootstrap
00:25.31CIA-109BRL-CAD: 03starseeker * r47467 10/brlcad/trunk/src/other/re2c/ (CMakeLists.txt parser.yy): Couple more tweaks - re2c builds now
00:30.18starseekerwoo hoo!
00:36.22CIA-109BRL-CAD: 03starseeker * r47468 10/brlcad/trunk/src/other/step/src/express/CMakeLists.txt: quiet messages for now
00:46.37*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
00:59.08CIA-109BRL-CAD: 03n_reed * r47469 10/brlcad/trunk/src/other/ (5 files in 3 dirs): remove old re2c bison sources
00:59.12*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
01:09.47*** join/#brlcad DarkCalf (DC@173.231.40.98)
09:49.37*** join/#brlcad yiyus (1242712427@je.je.je)
12:47.18*** join/#brlcad abhi2011 (~chatzilla@117.200.93.61)
15:32.11*** join/#brlcad abhi2011 (~chatzilla@117.200.89.240)
15:34.37*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
16:13.10CIA-109BRL-CAD: 03n_reed * r47470 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: updated example usage comment
16:23.11*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
16:25.45d_rossbergi just saw a strange effect in version 7.20.4: the ray-trace doesn't return the regions but the solids for V4 databases
16:26.23d_rossbergboth in windows and linux
17:04.47*** join/#brlcad piksi (piksi@pi-xi.net)
17:58.56CIA-109BRL-CAD: 03starseeker * r47471 10/geomcore/trunk/src/GS/testclient/gstestclient.c: Put in the definitions for ntohll and htonll.
20:41.55*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
20:50.49CIA-109BRL-CAD: 03starseeker * r47472 10/brlcad/trunk/src/other/CMakeLists.txt: handle lemon before re2c, since re2c is using lemon now
23:49.27*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20111111

IRC log for #brlcad on 20111111

00:08.04*** join/#brlcad piksi (piksi@pi-xi.net)
00:27.15*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
00:48.52*** join/#brlcad abhi2011 (~chatzilla@117.200.82.161)
02:28.36*** join/#brlcad abhi2011_ (~chatzilla@117.200.82.161)
03:25.15*** join/#brlcad abhi2011 (~chatzilla@117.200.86.46)
04:44.29*** join/#brlcad abhi2011 (~chatzilla@117.200.80.242)
05:46.37*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
06:20.42*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
07:16.17*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
07:28.39*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
07:42.04*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
11:54.31CIA-109BRL-CAD: 03d_rossberg * r47473 10/brlcad/trunk/src/librt/dir.c:
11:54.31CIA-109BRL-CAD: removed a bug (at least) in versions 7.20.2 and 7.20.4 which prevents the detection of V4 database's regions in ray-trace
11:54.31CIA-109BRL-CAD: this is more a work-around than a real bug-fix, I couldn't find the place where the detection was changed from region-flag to -attribute
12:25.14*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
14:48.39*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
16:20.15CIA-109BRL-CAD: 03HarveyTodd 07http://brlcad.org * r3241 10/wiki/Main_Page: /* BRL-CAD Wiki */
17:45.11CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3242 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/HarveyTodd|HarveyTodd]] ([[User talk:HarveyTodd|Talk]]); changed back to last version by [[User:Sean|Sean]]
17:45.38CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:HarveyTodd]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
20:27.48*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
21:00.02*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
21:24.07*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
IRC log for #brlcad on 20111112

IRC log for #brlcad on 20111112

01:31.46*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
02:43.31*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
05:52.32*** join/#brlcad abhi2011 (~chatzilla@117.200.82.200)
08:28.56*** join/#brlcad abhi2011 (~chatzilla@117.200.90.209)
11:49.52*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
12:18.36*** join/#brlcad abhi2011 (~chatzilla@117.200.82.48)
15:23.27*** join/#brlcad abhi2011 (~chatzilla@117.200.86.154)
16:19.42*** join/#brlcad abhi2011 (~chatzilla@117.200.86.235)
18:18.23*** join/#brlcad Stattrav_ (~Stattrav@117.192.138.104)
18:40.29*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
18:42.48*** join/#brlcad Stattrav_ (~Stattrav@117.192.139.145)
18:56.08*** join/#brlcad Forth (~Forth@92.242.118.253)
19:25.11*** join/#brlcad Stattrav_ (~Stattrav@117.192.130.219)
19:31.24*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
19:32.42*** join/#brlcad Stattrav_ (~Stattrav@117.192.131.0)
19:44.08*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
19:45.26*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
IRC log for #brlcad on 20111113

IRC log for #brlcad on 20111113

01:55.53*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1128565288.dsl.bell.ca)
01:56.44IriX64http://pastebin.ca/2094069
01:57.05IriX64a cmake attempt
01:57.46IriX64ciao
03:07.47starseekerthat looks like an incomplete checkout, if it's from svn
03:07.59starseekerno version info...
03:35.02*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
04:24.24*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
04:28.13starseekerO.o http://gizmodo.com/5351348/amazon-kindle-2-hacked-to-run-linux
04:55.16louipcthe INSTALL.cmake file isn't up to date is it?
04:55.27starseekerprobably not
04:55.45starseekerdon't know if I fixed it after the latest Big Rework
04:56.08starseekerlouipc: any specific troubles?
04:56.15louipcunder configuration options seems like it's not using cmake
04:56.50starseekerah, right - it's not done yet in that sense
04:59.16louipcstarseeker: yeah was just wondering how to disable strict with cmake
04:59.25starseekerah
04:59.32starseekerone sec
04:59.51starseeker-DBRLCAD-ENABLE_STRICT=OFF
05:00.32starseekeralthough I'm sure i'd be interesting to know what's failing for strict
05:01.52louipcI'll get back to you on that
05:08.19CIA-109BRL-CAD: 03starseeker * r47474 10/brlcad/trunk/INSTALL.cmake: Change a few of the now wildly incorrect sections of INSTALL.cmake - more work to do here, if the current setup is in fact the final configuration.
05:13.14starseekerer s/i'd/we'd ;-)
05:19.17CIA-109BRL-CAD: 03starseeker * r47475 10/brlcad/trunk/src/libged/simulate/simrt.c: remove unused var
05:19.26starseekerlouipc: that help?
06:20.02louipcstarseeker: yeah a bit less confusing thanks
06:20.41louipcstarseeker: here's where it failed - http://louipc.mine.nu/brlcad/builderr20111113
06:27.15starseekerO.o
07:08.37*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
10:50.40*** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no)
13:09.41*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:28.59*** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com)
13:28.59*** join/#brlcad piksi (piksi@pi-xi.net)
13:28.59*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:29.00*** join/#brlcad kanzure (~kanzure@131.252.130.248)
13:29.00*** join/#brlcad yiyus (1242712427@je.je.je)
13:29.00*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
13:29.00*** join/#brlcad CIA-109 (~CIA@cia.atheme.org)
13:29.00*** join/#brlcad DarkCalf (DC@173.231.40.98)
13:29.00*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
13:29.00*** join/#brlcad bhinesley (~bhinesley@adsl-99-52-241-103.dsl.bkfd14.sbcglobal.net)
13:29.00*** join/#brlcad ChanServ (ChanServ@services.)
13:29.00*** mode/#brlcad [+o ChanServ] by wolfe.freenode.net
13:30.15*** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no)
13:30.15*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
13:30.15*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
13:30.15*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
13:30.15*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
13:30.15*** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
13:30.15*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
13:30.15*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
13:30.48*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
13:45.33*** join/#brlcad bhinesley (~bhinesley@99.52.241.103)
13:45.51*** join/#brlcad DarkCalf (DC@173.231.40.98)
13:45.51*** join/#brlcad CIA-109 (~CIA@cia.atheme.org)
13:48.05*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
13:48.05*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
13:48.05*** join/#brlcad yiyus (1242712427@je.je.je)
13:48.05*** join/#brlcad kanzure (~kanzure@131.252.130.248)
13:48.05*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:48.05*** join/#brlcad piksi (piksi@pi-xi.net)
13:48.05*** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com)
14:27.19*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
15:39.19*** join/#brlcad piksi (~piksi@pi-xi.net)
15:45.11*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
16:40.44*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
17:46.34*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
18:03.19*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
18:24.09*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
20:42.44*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
23:09.45*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
23:18.25*** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc)
23:38.56*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
23:39.55*** join/#brlcad Technicus|2 (~Technicus@DSLPool-net208-2.wctc.net)
IRC log for #brlcad on 20111114

IRC log for #brlcad on 20111114

01:05.27*** join/#brlcad FrantiK (~FrantiK@unaffiliated/frantik)
02:38.40*** part/#brlcad FrantiK (~FrantiK@unaffiliated/frantik)
03:22.22*** join/#brlcad DarkCalf (DC@173.231.40.98)
07:51.51*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
08:05.52*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:41.01*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
12:04.16*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:25.58CIA-109BRL-CAD: 03d_rossberg * r47476 10/brlcad/trunk/src/librt/primitives/nmg/nmg_copy.c: the mate's parent was the parent's mate
12:42.46CIA-109BRL-CAD: 03d_rossberg * r47477 10/rt^3/trunk/ (5 files in 2 dirs): torso of a C++ class interface to BRL-CAD's non-manifold geometry element
12:45.49CIA-109BRL-CAD: 03d_rossberg * r47478 10/brlcad/trunk/misc/win32-msvc/Dll/CMakeLists.txt: included NonManifoldGeometry in the brlcad.dll build
13:10.01*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
14:08.14*** join/#brlcad abhi2011 (~chatzilla@117.200.90.157)
14:52.40*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
17:23.54*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
18:08.31brlcadwaves
18:11.04brlcadbhinesley: duly noted, awesome (delayed response)
18:12.08``Erikbrlcad: did you have something for indianlarry?
18:29.15*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
19:30.14brlcadsent
19:41.07brlcadlouipc: that's pretty impressive
19:42.17brlcadthose warnings are actually errors -- it's overrunning an array
19:43.18brlcadimpressive that it figured out that a double[2] was passed to function as a double* then to another function as a double* and then dereferenced as a double[3] ...
19:43.34brlcadlouipc: what compiler version and OS was that?
19:54.18*** join/#brlcad merzo (~merzo@194-214-132-95.pool.ukrtel.net)
21:13.03louipcbrlcad: gcc 4.6.2, arch linux
21:13.59louipcit's a multilib build of gcc, so I can build 32 bit binaries on my 64bit system if needed
21:14.13louipcnot sure if that's significant
21:53.56starseekerOooo:  http://www.techworld.com.au/article/407302/amd_16-core_opteron_chips_arrive_after_wait
21:57.46starseekerah, phooey - not full fledged cores
22:22.38*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:21.05*** join/#brlcad jarray52 (~bigbear@unaffiliated/jarray52)
23:23.37jarray52Is BRL-CAD a good tool for CAD/CAE/CAM work on something like a DIY motorcycle, snow blower, or diesel generator?
23:59.55louipcjarray52: ok for cad, if you have pro/e you can exchange data I think (but have to compile the extension and need a license), no CAM features
IRC log for #brlcad on 20111115

IRC log for #brlcad on 20111115

00:05.45*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
01:08.54jarray52louipc: What would be the primary limitations of using brl-cad for designing something like a car, motorcycle, diesel generator, or satellite?
01:10.56jarray52And the primary advantages over AutoCad or solidworks?
01:59.46starseekermakes a note to read this in more detail: http://www.linuxjournal.com/article/3687
02:02.42louipcjarray52: brl-cad has no dimensioning feature, or 2d drafting ability, no step export, and step import is still in development
02:05.41louipcjarray52: one of brl-cad's main purposes was for ballistics analysis for the military, so it doesn't have the regular CAD stuff you usually expect
02:08.42louipcjarray52: not even a shaded view for solids in editing.. you have to explicitly render the view
02:09.32jarray52What are its primary advantages?
02:10.34louipcseems more geared for making 'true' solids
02:10.36jarray52over something like solidworks
02:10.40jarray52or autocad
02:10.43jarray52other than cost
02:11.04louipcit's not really in the same realm at the moment
02:11.17louipcor ever? dunno
02:12.29louipcdepends on what you want to do I guess
02:12.37jarray52in quality or purpose?
02:12.45louipcpurpose
02:13.01jarray52it can export .dxf
02:13.25louipcthink so
02:54.54*** join/#brlcad abhi2011 (~chatzilla@117.200.80.13)
03:23.19*** join/#brlcad abhi2011 (~chatzilla@117.200.86.180)
03:38.20brlcadjarray52: the primary limitation is usability -- like any cad system, there's a significant learning curve
03:38.30brlcadand ours is particularly steep
03:40.39brlcadjarray52: BRL-CAD's strength is for assisting with a variety of engineering analysis work, generally niche fields that have varied/unpredicatble requirements
03:42.41jarray52brlcad: After getting past the learning curve, is the system nicely useable?
03:42.53brlcadfor basic design/modeling, BRL-CAD is good once you get up the learning curve but it is a different command-line driven approach that usually favors people with scripting skills
03:43.21brlcadit's usable, been used for production analysis work in the DoD for several decades
03:43.29jarray52I'm a python/c++ programmer with little CAD experience. So, I really like the idea of scripting oriented CAD.
03:43.54brlcadbut make no mistake, that learning curve is steep -- brl-cad is huge with lots of features and lots of ways to get tasks done  ;)
03:44.02jarray52Is the engineering analysis work limited to ballistics/electromagnetics.
03:44.06jarray52?
03:44.36jarray52brlcad: Is the learning curve steeper than learning a programming language like C++ for the first time?
03:44.45brlcadnot really, and we don't even include that analysis logic directly within BRL-CAD -- hooks are provided to the analysis codes
03:44.58brlcadoh heavens no
03:45.15jarray52what about learning python for the first time?
03:46.03brlcadthe biggest issue is probably that it's not a discoverable system, you'll only learn by going through tutorials (for which there are EXTENSIVE tutorials across a range of topics), reading man pages, and modeling, modeling, modeling
03:46.41brlcadI don't think so, but that's a bit of a skewed question to ask...
03:46.59jarray52Once mastered, does it have lots of features not found in programs like autocad, catia, and pro engineer?
03:47.11brlcadis it harder to learn being a professional woodworker or a professional mechanic?
03:47.24jarray52sorry...
03:47.27brlcadthey both can take decades to master ;)
03:47.40jarray52the questions were misguided...
03:47.57brlcadit's fine, just don't want you to have unrealistic expectations
03:48.27brlcadthere are some features BRL-CAD provides that are arguably better or more powerful than features in commercial CAD systems
03:48.38jarray52such as?
03:49.15brlcadwe are one of the very best at loading superbly complex models with minimal memory and processing, and still being able to render/analyse those models more quickly than anyone else
03:49.51brlcadnotorious for being able to open models that bring Pro/E, NX, and others to their knees on a powerful workstation
03:50.24brlcadour other flexibility is in the breadth of flexibility, lots and lots of tools that you can chain together to get a job done
03:51.47jarray52Just so I understand... this type of thing could for example be used to model an aircraft carrier with planes taking off and landing or a space station with multiple space vehicles docking, leaving, and so on.
03:52.27jarray52Is that the type of specialized thing that brlcad would do well?
03:52.28brlcadif we were an operating system code, we'd be more like bsd userland tools and a bsd microkernel -- not the pretty shiny layer on top ala osx or the facades of gnome/gtk, windows, etc
03:52.53starseekerOur graphical interactions are very primitive by modern standards
03:52.54jarray52microkernel?
03:53.47starseekerjarray52: more like using a (relatively) small amount of information to represent complex geometry - that's a specialty
03:53.48jarray52Would this be a good tool to design and model a diesel or car engine?
03:54.12jarray52with internal moving parts and all...
03:54.22brlcadjarray52: nevermind the microkernel analogy if it's unfamiliar, the linux kernel works as an analogy too -- we're (presently) more of a kernel, not an easy-to-use distribution like ubuntu or fedora
03:54.22starseekerwe don't currently simlulate part interactions
03:54.43brlcadjarray52: you can model just about anything -- it's what you do with the model once you're done
03:54.45starseeker(some nifty work going on to integrate bullet, but that's in the experimental stages)
03:55.12brlcadso yeah, you could model up an entire aircraft carrier down to every nut bolt and wire, no problem
03:55.15starseekerjarray52: if you're going to create a model in BRL-CAD, you'll need to use constructive solid geometry
03:55.20brlcadgenerate renderings and visualizations, no problem
03:56.02brlcadbut then if you want blueprints -- we can provide the hidden line blueprint-style image, but not with dimensions or labels annotated
03:56.33brlcador if you want an animation, no problem .. but we don't (yet) provide physics simulations with contact constraints
03:57.16jarray52starseeker: I don't understand what you mean by "we don't currently simulate part interactions".
03:57.25brlcadjarray52: take a look at the introduction to mged tutorial and scripting tutorial on the website, they'll give you a good idea of some things possible (along with the image gallery)
03:57.29jarray52in light of the other comments made by yourself and brlcad.
03:57.46starseekerjarray52: if you model two gears and try to have one turn the other, for example
03:58.00starseekerwe don't do that right now
03:58.18brlcadjarray52: http://brlcad.org/wiki/Documentation  <-- #2
03:58.34brlcadand http://brlcad.org/wiki/SGI_Cube for a very brief scripting example
03:59.12jarray52starseeker: Does any cad program allow one gear to turn another?
03:59.30brlcadyeah, the big five all have that ability
04:00.02jarray52brlcad: big five=CATIA, Pro/Engineer, NX, AutoCAD, xxx?
04:00.09brlcadyou have to specify a lot of crap to make it happen automagically, but it's "possible"
04:00.13brlcadsolidworks
04:00.18jarray52right
04:00.56brlcadtechnically, it's sorta possible in brl-cad, but that's functionality that was last used more than 10 years ago
04:01.17brlcadwe have someone working on a new system now, way way cooler and easier to use .. but just getting started :)
04:01.53jarray52brlcad: So, the user has to specify the motion for animations along with contact constraints, but it is possible, right?
04:03.06brlcadjarray52: this may be more familiar with your python background .. it's a perl modeling example, but could do almost exactly the same with python: http://brlcad.org/wiki/Spiral
04:03.49brlcadjarray52: well like I said -- it's a new system and I wouldn't recommend trying to use the old system unless you're willing to help debug
04:04.31brlcaduntil then, you basically have to manually put geometry where you want it, motion is just basic model transformations
04:05.06brlcadala claymation, just not quite as tedious
04:05.21brlcad(because you can script it all)
04:05.58jarray52brlcad: That's actually very cool because an external program could be doing calculations and transformations and moving the parts.
04:06.05brlcadlouipc: ah, interesting, I'd tried .1 and it found some new issues .. .2 finds more .. someone must be actively boosting up those detection abilities
04:06.41brlcadjarray52: that's actually the intent (and you can see how we start to "fit in" with external analysis codes)
04:07.59jarray52brlcad: And, once the model and external analysis code work the way they are intended to work(in theory at least), the parts can be exported to .dxf and manufactured.
04:08.55*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
04:09.28jarray52brlcad: I think you have me sold on BRL-CAD now.
04:10.09starseekerjarray52: the thing that will probably feel strangest about BRL-CAD in its current form is the lack of 3D shaded displays - we visualize only with wireframes or raytracing now, unless you happen to have a triangle based model
04:10.53jarray52Raytracing with wireframes only?
04:11.05starseekerno, interactive display with wireframe only
04:11.13starseekerraytrace is when it gets pretty :-)
04:11.23brlcadinteractive as in grab the mouse and spin the model around -- wireframe only
04:11.34brlcadhit the render button, though, and you get your pretty shaded picture
04:12.04jarray52brlcad: That's acceptable.
04:12.33jarray52brlcad: At the end of the day, one can sell the pretty picture to a boss or investors.
04:12.39jarray52:)
04:12.41brlcadnods :)
04:12.52brlcadyou've seen the gallery yes?
04:12.58jarray52brlcad: Yes.
04:13.06jarray52brlcad: And read through some of the manuals.
04:13.19brlcadso that's a pretty wide range of different types of projects and different ability levels
04:13.21jarray52brlcad: I'm a CAD/CAE/CAM newbie.
04:13.27jarray52brlcad: Yes.
04:13.33brlcadall the better, less to unlearn :)
04:14.20starseekerfolks expecting a Blender-like GUI are in for a shock, but there's a lot of power under the hood
04:14.56jarray52starseeker: I prefer scripted model development.
04:15.07starseekerlonger term we're planning to get there, but there's a *lot* of foundational work that has to come before the pretty interactive 3d
04:15.10starseeker:-)
04:15.18starseekerjarray52: then you're in the right place :-)
04:15.38jarray52In theory, scripted development should be faster, right?
04:15.55starseekerfor some classes of problems, absolutely
04:15.59jarray52probably depends on the designer.
04:16.10jarray52starseeker: Yes. Most definitely.
04:16.13brlcadvery much so
04:16.18starseekerif you have data you can feed the script, that's where scripting shines
04:16.31brlcadif the designer doesn't know how to write a script, that's a pretty huge hurdle ;)
04:16.37starseekerjarray52: if you really want to go to town, there are C apis for model generation
04:17.05brlcadjarray52: a case study example that may be of interest: http://brlcad.org/wiki/Ronja
04:17.06starseekerthat's what the tire tools does, for example - tire dimensions in, tire geometry out.
04:17.10starseekerprocedural modeling
04:18.04brlcadjarray52: that's an individual that learned to model in less than a day, spent maybe a week modeling his design, then another week writing scripts to generate various images and animations:  http://ronja.twibright.com/3d/
04:19.15brlcadnot the best example of good modeling practices in his models, but a decent showcase of what is possible within just a few days time
04:19.40starseekeroh, this one is kinda fun for "what's possible"  http://more.brlcad.org/model/basic-impeller
04:20.13brlcadthat'd be a fun one to feed to an arylic printer
04:20.27starseekerreflects we really should get that default GPL license label off the more.brlcad.org listings...
04:21.45jarray52brlcad: BRL-CAD would probably be a good tool for modelling a network of telephone or power transmission lines including the powerplant, right?
04:21.59brlcadsure
04:22.17brlcadstarseeker: you going to close out and document sf bug #3435642 ?
04:22.22brlcadthe obj export bug
04:22.23starseekerfun with the pipe primitive :-)
04:22.33starseekerbrlcad: oh, right - he confirmed the fix, didn't he
04:22.36jarray52brlcad: This would be the type of design for which BRL-CAD shines, right?
04:23.50brlcadyeah, there are only a few types of models that BRL-CAD is ill-suited for direct modeling (import is fine though)
04:25.28brlcadnamely: soft bodies (e.g., human skin) and highly curved surfaces (e.g., some modern car bodies)
04:26.47brlcadobjects that can be broken down into constituent primitives shapes can be directly modeled much easier
04:27.17louipcbrlcad: http://louipc.mine.nu/brlcad/brlcad-7.20.4-1-x86_64-build.log
04:27.39louipcthat's a full build log with my version of gcc if that interests you
04:27.52louipcstrict=off
04:31.45CIA-109BRL-CAD: 03brlcad * r47479 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c:
04:31.46CIA-109BRL-CAD: attempt a fix for a variety of gcc 4.6.2 strict compilation failures reported by
04:31.46CIA-109BRL-CAD: louipc (irc). compiler was clever enough to figure out that 2d-arrays were
04:31.46CIA-109BRL-CAD: getting passed around as pointers and getting later treated as 3d-arrays.
04:32.03brlcadlouipc: thanks... but do you have an svn checkout? :)
04:32.09louipcyeah
04:32.10CIA-109BRL-CAD: 03starseeker * r47480 10/brlcad/trunk/NEWS:
04:32.10CIA-109BRL-CAD: obj export was producing facets that all shared the same number instead of
04:32.10CIA-109BRL-CAD: pointing to the correct points - problem was very precisely identified by
04:32.10CIA-109BRL-CAD: Christopher Pitts (down to the incorrect variable in the source file), so he
04:32.10CIA-109BRL-CAD: gets credit for the fix - thanks\!
04:32.26brlcadline numbers will be askew and easier to verify if you can svn up while I fix
04:32.40louipcok
04:34.11brlcadstarseeker: cool, thx
04:35.02brlcadunrelared, r47471 seems wrong .. removed bu.h and pulled in a bunch of header foo it was using in the test client?
04:35.19brlcadpresume you encountered some problem?
04:35.44starseekerthe point of that client was to be totally self contained
04:36.29brlcadis ntohll required for something in the test client??
04:36.35brlcadthat seems .. wrong :)
04:36.50starseekerIIRC, Eric was using it to ensure network order when packing some stuff
04:37.35starseekershrugs - I'm still doing remedial education at this point, I did that to ensure the build worked
04:37.40brlcadno problem
04:37.45brlcadit was more a curiosity
04:37.55brlcadit could frankly be a shell script making telnet calls
04:38.33starseekerin principle, sure - in practice I'm trying to at least *pretend* the goal is to be portable to Windows :-P
04:38.42brlcadbut by "self contained" the main requirement is actually just not calling any gs/ge code
04:38.47starseekerright
04:39.01brlcadbu.h isn't in that category, so it's an impl detail
04:39.31brlcadit's the stuff in the geomcore checkout that should be avoided (for the indep test only of course)
04:39.54starseekernods - I could have fixed the build logic too, but the logic ran "why's this failing - oh, that's supposed to be self-contained - huh it's just using that one feature - commit"
04:39.54brlcadeither way, like I said -- more just a curiosity, carry on ;)
04:40.18starseekerresumes wallowing in ignorance :-P
04:40.30starseekerbtw, welcome back
04:41.25brlcadit raised my "what?" radar simply because it fails DRY and that usually trumps
04:41.39starseekerponders whether SCL should do as BRL-CAD does with version numbers...
04:42.36brlcadfor a project that small, the version number could live in the top-level CMakeLists.txt file, maybe wrap in a macro if it's needed in multiple places but the built-in versioning hooks are probably sufficient
04:43.08brlcadwe're more of a platform where that number is used all over the place in various ways
04:43.11brlcadscl not so much
04:43.38starseekernods - that was my thought
04:43.56starseekerjust do some .in files if they want it in headers
04:44.51starseekers/Eric/Erik
04:44.57starseekeralright, bedtime
04:47.09brlcadhasta la pasta
04:48.42louipcoops? http://louipc.mine.nu/brlcad/brlcad-svn47480-build.log
04:48.48jarray52brlcad: Thanks for answering my questions.
04:49.11jarray52I want to thank starseeker and others as well.
04:50.23louipcthanks for being patient and sticking around ;)
05:39.25jordisayolbrlcad: hasta la pasta!?
05:41.11jarray528-)
08:10.20*** join/#brlcad merzo (~merzo@193.254.217.44)
08:52.57*** join/#brlcad abhi2011 (~chatzilla@117.200.85.67)
09:07.51*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
11:39.05*** join/#brlcad abhi2011 (~chatzilla@117.200.88.176)
12:45.29*** join/#brlcad abhi2011_ (~chatzilla@117.200.88.176)
12:50.03*** join/#brlcad abhi2011_ (~chatzilla@117.200.88.176)
13:27.18*** join/#brlcad abhi2011 (~chatzilla@117.200.88.176)
13:42.04*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
14:10.20*** join/#brlcad abhi2011 (~chatzilla@117.200.82.152)
14:22.24*** join/#brlcad piksi (piksi@pi-xi.net)
14:34.32*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
15:03.38CIA-109BRL-CAD: 03d_rossberg * r47481 10/rt^3/trunk/ (2 files in 2 dirs):
15:03.39CIA-109BRL-CAD: method to get a simple facetized boundary-representation of a subtree
15:03.39CIA-109BRL-CAD: it's a method of the database because not only one element is involved but the tree below the requested element
15:09.48``Erikthe GS "ping/pong" uses a network order uint64, so ntohll() was needed... personally, I think the protocol should evolve as a human readable ascii thing over the line (yes, so telnet can be used, and it can be easily debugged), then add a 'binary' command and mode down the road
15:14.28*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:41.40brlcadd_rossberg: not that it matters much, but "nmg" stands for n-manifold geometry
15:42.07brlcadthe original paper was entitled non-manifold, but by the time it was implemented and announced, it became n-manifold
15:48.35brlcadof course, the generalized structure happens to support n-manifold surfaces as well as non-manifold vertices and edges (not sure about non-manifold faces)
16:00.29*** join/#brlcad abhi2011_ (~chatzilla@117.200.84.128)
16:02.07d_rossbergthese n-manifold vs. non-manifold sounds unfortunate, espaecially because it is still the original Weiler non-manifild
16:02.51d_rossbergincluding all its ballast
16:03.23brlcadit's mainly due to the audience perspective, though
16:03.46brlcadweiler was trying to solve the academic problem of how to model non-manifold entities
16:04.17brlcadthe structure does that, even if the dominant use is for n-manifold surface boundaries
16:05.18d_rossbergi wouldn't mind to get rid of the burden
16:05.23brlcadfrom our users perspective, it should really just be called a "mesh" or "solid polygonal mesh" or similar :)
16:05.50brlcadburden?
16:06.14d_rossbergthe model, region and lower dimensional things
16:07.02brlcadyou mean implement a non-weiler polygonal mesh api or something else? :)
16:07.17d_rossbergall we really need is a single shell
16:08.36d_rossbergit looks like most of the algorothms using nmg can't handle models with multiple regions
16:09.30brlcadthat's because they're all just copies of each other and the first guy was lazy
16:09.34d_rossbergthese are relics of the original nmg CAD project
16:09.48``Erikmost assume an NMG is a single NMG region with a single NMG shell, iirc
16:11.21brlcadI don't believe the boolean evaluator used for E/ev is that limited
16:11.58d_rossbergand support of Euler operations would be nice
16:13.27brlcadif I have an rcc and subtract an arb8 from the middle, makes two shells -- you really don't want to create two single-shell nmg objects, you want just one named object with the two shells in it
16:15.25d_rossbergnmg_booltree_leaf_tess creates a new model for every primitive
16:16.13brlcadnmg supports most euler operations iirc
16:16.37brlcadperhaps not all
16:22.28brlcadcreates a new model for each prim, but then pairwise extracts their (single) shell and performs the boolean
16:22.53brlcadthe limitation is only on a single primitive that might have multiple shells (BoT, pnts, dsp, ..)
16:24.14brlcadotherwise, the boolean of two shells will result in n-shells
16:28.14d_rossberga shell is a simple collection of faces, loops, edges and a vertex, there is no real restriction to a single connected volume
16:28.24d_rossberghowever, i plan to write down my impress
16:28.44d_rossberg-ions and send them to the devel-list
16:28.55d_rossberg... later
16:29.54brlcadwell, no restriction other than that is the (current) definition of a shell :)
16:32.31brlcadthat said, I do agree that there's no practical benefit that comes to mind for having models and regions (to a slightly lesser degree)
16:33.49brlcadthere would be a purpose for regions and models if you could associate user-data (void*) to caller API
16:34.58*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
16:35.42*** join/#brlcad abhi2011 (~chatzilla@117.200.82.93)
17:21.04*** join/#brlcad abhi2011 (~chatzilla@117.200.82.93)
18:22.46starseekerhah, cool:  http://code.google.com/p/libmv/
18:51.57``Erikwas looking at that a while ago, have they actually been working on it? O.o seemed like a dead end at the time
18:52.48CIA-109BRL-CAD: 03erikgreenwald * r47482 10/geomcore/trunk/tests/func/GE/GeometryEngineTest.cxx: fix usage typo
19:00.53*** join/#brlcad merzo (~merzo@128-101-133-95.pool.ukrtel.net)
19:02.24*** join/#brlcad abhi2011_ (~chatzilla@117.200.80.170)
19:06.11brlcad"BRLCAD" is a typo too
19:06.32brlcaddash merely in the wrong place
19:59.25CIA-109BRL-CAD: 03brlcad * r47483 10/brlcad/trunk/ (5 files in 5 dirs):
19:59.25CIA-109BRL-CAD: make the invoking wrapper batch scripts all set the PATH before running
19:59.25CIA-109BRL-CAD: mged/archer/bwish/rtwizard so that tools invoked by commands can be found.
19:59.25CIA-109BRL-CAD: untested, but should do the trick without requiring the user to have
19:59.25CIA-109BRL-CAD: admin/profile rights to modify the PATH permanently. this is in response to a
19:59.25CIA-109BRL-CAD: feature request from the dwayne kregel.
20:13.25CIA-109BRL-CAD: 03brlcad * r47484 10/brlcad/trunk/ (4 files in 2 dirs): apply another tclscript update from carl g moore jr that reports what the input object names are that weren't combs and makes reid report the highest value set.
20:20.56CIA-109BRL-CAD: 03brlcad * r47485 10/brlcad/trunk/TODO: document dwayne's detailed feature request for a geometry prep lintian command
20:55.02CIA-109BRL-CAD: 03brlcad * r47486 10/brlcad/trunk/NEWS:
20:55.02CIA-109BRL-CAD: daniel applied a fix in r47473 for a bug that was preventing the detection of V4
20:55.02CIA-109BRL-CAD: regions during raytrace. it looks like this is the same bug reported by chris
20:55.02CIA-109BRL-CAD: pitts a couple weeks ago, which he'd traced down to db5_sync_attr_to_comb()
20:55.02CIA-109BRL-CAD: wiping out the comb structure.
21:02.47CIA-109BRL-CAD: 03brlcad * r47487 10/brlcad/trunk/NEWS: bob added the 'l'ist command to archer, which improves/fixes the 'g' grouping command
21:08.45CIA-109BRL-CAD: 03brlcad * r47488 10/brlcad/trunk/AUTHORS: special thanks to chris pitts for his efforts to report, diagnose, and even help pinpoint where in the source code a problem was occurring. helped with v4 raytracing and obj export issue.
21:11.02CIA-109BRL-CAD: 03brlcad * r47489 10/brlcad/trunk/AUTHORS: browder now belongs up in the code contributions section given all of the recent documentation efforts.
22:53.22*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
23:10.59CIA-109BRL-CAD: 03n_reed * r47490 10/brlcad/trunk/src/other/ (9 files in 2 dirs): adding sources for an experimental scanner-generator
23:11.24*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:20.54*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
IRC log for #brlcad on 20111116

IRC log for #brlcad on 20111116

00:13.37*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
00:22.42*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
00:49.18*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
03:20.27starseekerhah, sweet!  http://spacenav.sourceforge.net/
03:32.32brlcadshame only the windows port is lgpl, but pretty cool regardless
03:47.37*** join/#brlcad abhi2011 (~chatzilla@117.200.88.17)
03:55.26starseekerbrlcad: we wouldn't need to bundle the driver though would we?
03:55.29starseekerthe sdk is BSD license
04:05.43abhi2011brlcad: with regard the mail, so can you explain a bit more about what you mean by the segment closest to the object
04:19.13*** join/#brlcad abhi2011_ (~chatzilla@117.200.90.21)
04:33.09*** join/#brlcad abhi2011_ (~chatzilla@117.200.88.129)
04:39.54brlcadabhi2011: probably best demonstrated with a picture, but the basic idea is to shoot a grid of rays from behind object A towards object B
04:42.06brlcadfor all the rays that hit B, you find the one with the furthest "back" starting point, use it's normal on B's surface
08:32.54*** join/#brlcad abhi2011 (~chatzilla@117.200.90.206)
09:28.54*** join/#brlcad abhi2011 (~chatzilla@117.200.90.206)
10:32.30*** join/#brlcad abhi2011_ (~chatzilla@117.200.90.206)
10:59.27*** join/#brlcad abhi2011_ (~chatzilla@117.200.82.25)
13:42.14*** join/#brlcad kanzure_ (~kanzure@131.252.130.248)
13:48.05``Erikbrlcad: new crit == 3268 vgr's (opposed to 1100 for current and 1300 for old replacement)
14:59.08CIA-109BRL-CAD: 03erikgreenwald * r47491 10/geomcore/trunk/tests/func/GE/GeometryEngineTest.cxx: minor tweaks to usage output
15:16.20*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:28.05brlcadnot too shabby
16:27.09CIA-109BRL-CAD: 03brlcad * r47492 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: remove the pointer indirection since that messes with array indexing and causes a compiler warning on some platform somewhere.
16:33.30*** join/#brlcad yukonbob (~bch@S01060024a5c9dad4.ok.shawcable.net)
16:33.35yukonbobhello, #brlcad
16:44.19*** join/#brlcad abhi2011 (~chatzilla@117.200.81.168)
17:08.39*** join/#brlcad abhi2011 (~chatzilla@117.200.81.168)
17:19.05*** join/#brlcad abhi2011_ (~chatzilla@117.200.81.168)
17:50.11CIA-109BRL-CAD: 03starseeker * r47493 10/brlcad/trunk/src/ (4 files in 3 dirs): Turn on clipper library for Bob's stuff
17:53.07*** join/#brlcad abhi2011_ (~chatzilla@117.200.81.168)
19:32.47*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
19:46.11CIA-109BRL-CAD: 03bob1961 * r47494 10/brlcad/trunk/ (9 files in 2 dirs): Added a flag to the drawLines3D functions for optionally drawing line strips instead of lines.
20:16.05CIA-109BRL-CAD: 03bob1961 * r47495 10/brlcad/trunk/ (include/ged.h src/libged/view.c src/mged/setup.c): Changed the ged_view function to ged_view_func so that it's different from struct ged_view. This eliminates a problem that appears when including ged.h in a C++ file.
20:25.49CIA-109BRL-CAD: 03erikgreenwald * r47496 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: reflect change from ged_view to ged_view_func in table
20:27.49CIA-109BRL-CAD: 03erikgreenwald * r47497 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: pass 0 to new sflags field
20:31.53CIA-109BRL-CAD: 03bob1961 * r47498 10/brlcad/trunk/ (3 files in 2 dirs): Added code to interface with src/other/clipper. More work to do here --- checking in for safety.
20:40.27CIA-109BRL-CAD: 03brlcad * r47499 10/brlcad/trunk/TODO: they already have the init funcs, need pkgIndex.tcl file for our core libs
20:43.13CIA-109BRL-CAD: 03brlcad * r47500 10/brlcad/trunk/src/tclscripts/archer/BotUtility.tcl: include requisite dependency packages as well as loading libbu so we can find botEditor.tcl and quell failure message during build.
20:44.33CIA-109BRL-CAD: 03bob1961 * r47501 10/brlcad/trunk/ (include/tclcad.h src/libtclcad/tclcad_obj.c): Added code to utilize src/other/clipper. Needs more work --- checking in for safety.
21:02.33CIA-109BRL-CAD: 03brlcad * r47502 10/brlcad/trunk/TODO: added dwayne's idea to wrong section, promote up a few easy tasks for this upcoming minor
21:13.39CIA-109BRL-CAD: 03bob1961 * r47503 10/brlcad/trunk/ (include/ged.h src/libtclcad/tclcad_obj.c): Added the gdps_prev_point and gdps_curr_polygon members to struct ged_data_polygon_state.
21:37.29CIA-109BRL-CAD: 03brlcad * r47504 10/brlcad/trunk/src/librt/primitives/nmg/nmg_copy.c: convert //-style comments to /**/
21:45.58CIA-109BRL-CAD: 03brlcad * r47505 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: bah, still issues with quellage. expand the vmove to avoid the parens. make the nmg_good_dirs container size be consistently checked too.
22:01.11CIA-109BRL-CAD: 03brlcad * r47506 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: copy paste error. ret isn't actually set/used, so shouldn't conditionalize on it.
22:06.37CIA-109BRL-CAD: 03brlcad * r47507 10/brlcad/trunk/src/libged/Makefile.am: tclcad uses clipper so have to enable it for autotools compilation. include src/other/clipper as header search dir too.
22:14.31CIA-109BRL-CAD: 03brlcad * r47508 10/brlcad/trunk/src/libged/clipper.cpp: update header
22:19.38CIA-109BRL-CAD: 03brlcad * r47509 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am clipper.cpp polyclip.cpp):
22:19.38CIA-109BRL-CAD: rename clipper.cpp to polyclip.cpp so as to not conflict with the same-named
22:19.38CIA-109BRL-CAD: clipper.cpp in src/other. this was path of least resistance since it's not
22:19.38CIA-109BRL-CAD: worth the effort to add autotools build logic for clipper or conditionalize
22:19.38CIA-109BRL-CAD: compilation.
22:21.35*** join/#brlcad yukonbob (~bch@207.6.71.53)
22:21.40yukonbobhello, #brlcad
22:25.24CIA-109BRL-CAD: 03brlcad * r47510 10/brlcad/trunk/src/libged/polyclip.cpp: update function names to match new file name. common.h before sys header too.
22:28.10CIA-109BRL-CAD: 03brlcad * r47511 10/brlcad/trunk/src/libged/polyclip.cpp: non-API functions shouldn't have ged_ prefix and should be made static when possible.
22:56.00CIA-109BRL-CAD: 03n_reed * r47512 10/brlcad/trunk/src/other/perplex/ (Makefile.local perplex.c perplex.h scanner.re template.c): borrowing flex's dynamic buffers to implement yytext string
23:00.39*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:23.18CIA-109BRL-CAD: 03bob1961 * r47513 10/brlcad/trunk/ (3 files in 3 dirs): Added more parameters (i.e. scale factors and matrices for transforming to/from model/view) to ged_clip_polygon, ged_clip_polygons, load_polygon, load_polygons and extract.
23:58.16CIA-109BRL-CAD: 03bob1961 * r47514 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Fixed to_mouse_poly_rect to work in an arbitrary plane.
IRC log for #brlcad on 20111117

IRC log for #brlcad on 20111117

00:03.25CIA-109BRL-CAD: 03bob1961 * r47515 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Updated to_data_polys() to call ged_clip_polygon() with a scale factor of LONG_MAX.
01:38.33*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
02:03.20*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
03:32.15*** join/#brlcad abhi2011 (~chatzilla@117.200.84.149)
04:49.58CIA-109BRL-CAD: 03starseeker * r47516 10/geomcore/trunk/geomserv_boost/ (258 files in 34 dirs):
04:49.59CIA-109BRL-CAD: Checkpoint some work studying boost::asio + Google's protobuf - probably not a
04:49.59CIA-109BRL-CAD: direction we want to go right now, but saving what has been done in case it
04:49.59CIA-109BRL-CAD: should prove useful at some point in the future. Decided not to add the entire
04:49.59CIA-109BRL-CAD: CMake-ified boost, just include the one tweak needed. Same deal for protobuf -
04:49.59CIA-109BRL-CAD: see README for the locations to get them from.
05:32.47*** join/#brlcad abhi2011_ (~chatzilla@117.200.88.52)
05:42.38CIA-109BRL-CAD: 03starseeker * r47517 10/geomcore/trunk/geomserv_boost/: Ah, checkpoint succeeded. Can clear it now, version control knows about it.
08:02.39*** join/#brlcad abhi2011 (~chatzilla@117.200.88.52)
08:14.53*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
08:30.14*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
09:12.04*** join/#brlcad abhi2011 (~chatzilla@117.200.88.52)
09:39.35abhi2011there seems to be ummatched endif at the end of brlcad_config.h
09:39.45abhi2011*an unmatched
09:41.38abhi2011brlcad_config.h is generated by cmake logic I think
09:49.01abhi2011ok removed  an extra : FILE(APPEND ${CONFIG_H_FILE} "#define __CONFIG_H__\n")
09:49.06abhi2011lets see if it compiles ok
10:13.19abhi2011nope that wasnt the right line
10:13.32abhi2011probably something else
12:02.25*** join/#brlcad abhi2011 (~chatzilla@117.200.84.80)
12:30.39*** join/#brlcad abhi2011 (~chatzilla@117.200.84.80)
12:48.24*** join/#brlcad abhi2011_ (~chatzilla@117.200.84.80)
13:03.14*** join/#brlcad abhi2011 (~chatzilla@117.200.84.80)
13:42.40*** join/#brlcad abhi2011_ (~chatzilla@117.200.84.80)
14:50.46*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
14:54.26starseekerabhi2011: can you post your brlcad_config.h somewhere?  also, are you trying a clean compile?
14:56.31*** join/#brlcad abhi2011_ (~chatzilla@117.200.85.81)
15:12.05*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:22.22*** join/#brlcad abhi2011_ (~chatzilla@117.200.85.81)
15:44.53CIA-109BRL-CAD: 03bob1961 * r47518 10/brlcad/trunk/src/libged/polyclip.cpp: Added a try catch block around a call to clipper's AddPolygon method.
15:46.35CIA-109BRL-CAD: 03bob1961 * r47519 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Use clipper's weird upper limit as a scale factor for the call to ged_clip_polgon().
15:50.10CIA-109BRL-CAD: 03starseeker * r47520 10/geomcore/trunk/geomserv_boost/ (5 files in 4 dirs): Gah, missed a couple things. Try again to checkpoint a building version of geomserv_boost
15:50.34*** join/#brlcad abhi2011_ (~chatzilla@117.200.82.230)
16:00.51CIA-109BRL-CAD: 03starseeker * r47521 10/geomcore/trunk/geomserv_boost/: OK, this time it actually built based on what was in svn tree (given the boost/protobuf downloads and glog/gflags/gtest in third_party) so we're good.
16:20.19*** join/#brlcad abhi2011_ (~chatzilla@117.200.82.230)
16:33.49CIA-109BRL-CAD: 03bob1961 * r47522 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Added functions to expose the current poly modes.
17:06.23*** join/#brlcad abhi2011_ (~chatzilla@117.200.82.230)
17:50.29*** join/#brlcad abhi2011_ (~chatzilla@117.200.82.230)
17:57.37starseekerabhi2011: were you still having brlcad_config.h problems?
18:11.30*** join/#brlcad yukonbob (~bch@207.6.71.53)
18:11.33yukonbobhello, #brlcad
18:26.27starseekerhello yukonbob
18:26.32starseekerwhat's new?
18:28.07yukonboboh -- what's new... working on getting to Seattle for a new gig...
18:28.31yukonbobseeing lots of brlcad mailing list activity lately, which is exciting.
18:28.44starseeker:-)
18:28.52starseekerdoing anything with Tcl/Tk lately?
18:29.05yukonboboccasionally working on my nbsd/tcl/brlcad integration, which is satisfying.
18:29.18yukonbobstarseeker: always.
18:29.20yukonbob:)
18:29.32starseekeryukonbob: did you get a chance to check out the CMake Tcl/Tk build?
18:29.46yukonbobhaven't looked in detail, no.
18:30.03starseekerhttps://github.com/starseeker/tcltk
18:30.05yukonbobI saw discssion on tcl mailing list, and I've seen commits over the months.
18:30.29starseekerneeds to put a TIP together, apparently - not sure how else to keep that process moving
18:30.54yukonbobthese "big" changes always throw me for a loop.
18:31.05starseekerhow so?
18:31.09yukonboband they're always tcl-related ;)
18:31.19starseekerheh
18:31.40starseekeryou mean 8.5 -> 8.6?
18:32.18yukonbobwell, when tcl8.5 was introduced, 8.5 was beta or alpha, and not widely distributed... my env is nbsd, and I had already done surgery to tease out nbsd-provided support and get a good build system running, then a beta version of tcl was tossed in.
18:32.31yukonbobthat pretty much killed my involvement for long time.
18:32.40starseekerah, right
18:32.51starseekerwell, rest assured we aren't requiring 8.6 :-)
18:32.59yukonbobNow I've actually got 8.6 integration working, and the build system is shifting under my feet ;)
18:33.05starseekerthat's just the version in the github project because I figured it would be an easier sell
18:33.09yukonbobis already there..
18:33.13starseekerah, cool!
18:33.42starseekeryukonbob: actually, there's not really a shift in the Tcl/Tk build - just another option
18:34.02yukonbobstarseeker: in conversation w/ brlcad he suggested auto* is on it's way out.
18:34.06yukonbobover the months...
18:34.11starseekeroh, the BRL-CAD build
18:34.13starseekeryeah
18:34.29starseekerdoes netbsd have CMake?
18:41.35starseekeryukonbob: out of curiosity, have you submitted your tcl/tk 8.6 patches for BRL-CAD?
18:45.20yukonbobI haven't. Am parallelly (sp?) working locally -- I *think* I've got commit status... I should build a branch and hack.
18:45.42yukonbobThe work is basically: make things modular on nbsd.
18:46.09yukonbobI've committed some patches and discussion as issues come up, but haven't been doing dev in-tree.
18:46.11starseekerwould advocate branching in svn - we're all curious :-)
18:47.04yukonbobtests something.
18:48.18*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
19:02.47yukonbobstarseeker: mind if I try an inconsequential test commit? Like adding a space to README?
19:08.28CIA-109BRL-CAD: 03bharder * r47523 10/brlcad/trunk/README: ws test commit
19:09.03yukonbobok -- I still have access; I'll create a branch and get this h4x0ring closer to the canonical project.
19:14.03*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
19:16.25CIA-109BRL-CAD: 03starseeker * r47524 10/brlcad/trunk/src/libpkg/ (7 files in 2 dirs): Add separate client and server examples based on tpkg.c for libpkg. Use localhost by default if client doesn't specify a host for simplicity.
19:20.19*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
19:20.54CIA-109BRL-CAD: 03brlcad * r47525 10/brlcad/trunk/src/ (19 files in 10 dirs): replace all calls to unlink() and remove() with calls to bu_file_delete() so we can get more consistent and portable behavior.
19:23.45abhi2011starseeker: there were some linking errors : http://bin.cakephp.org/view/2126104478
19:25.17abhi2011ok trying with a fresh chkout now
19:27.30*** join/#brlcad abhi2011_ (~chatzilla@117.200.82.230)
19:30.07starseekerabhi2011: ah, that's the new clipper stuff
19:30.40CIA-109BRL-CAD: 03brlcad * r47526 10/brlcad/trunk/HACKING: add bu_file_delete to the use-this-instead-of-that function list
19:41.21CIA-109BRL-CAD: 03starseeker * r47527 10/brlcad/trunk/src/other/clipper/ (CMakeLists.txt clipper.hpp): Make a stab at getting clipper to act like a library in Windows - untested.
19:43.07starseekerabhi2011: see if that helps any...
19:49.19abhi2011starseeker: the clipper related errors are gone, I have some errors due to linking with opengl : http://bin.cakephp.org/view/129832489
19:51.09abhi2011hmm there is some clipper.lib related things there too
19:53.51starseekerabhi2011: not sure what the opengl stuff is about - the clipper.lib stuff is probably our not having that whipped into shape as a Windows library
19:54.27abhi2011ok
19:54.41starseekerabhi2011: I'd recommend disabling the togl build
19:54.54abhi2011ok
19:55.44starseekerhmm, oops
19:55.48starseekerone second
19:55.52abhi2011ok
19:55.55abhi2011:)
19:55.59starseekerthat's only supposed to be on for X11 builds...
19:56.02starseekergrumble...
19:57.25abhi2011ok,,,yaawwwnn,,,will chk it tomorrow then...getting kinda late in the night here :)
20:00.40CIA-109BRL-CAD: 03starseeker * r47528 10/brlcad/trunk/src/ (adrt/CMakeLists.txt other/CMakeLists.txt): Togl isn't behaving well yet under non-X11 builds - turn it off unless we are X11
20:00.56starseekerabhi2011: k
20:12.46CIA-109BRL-CAD: 03n_reed * r47529 10/brlcad/trunk/src/other/perplex/ (Makefile.local perplex.c perplex.h scanner.re template.c): make scanner input buffer dynamic
20:15.29CIA-109BRL-CAD: 03brlcad * r47530 10/brlcad/trunk/include/bn.h: document what range of values are returned from bn_randmt()
20:31.41*** join/#brlcad yukonbob (~bch@207.6.71.53)
21:18.20*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
21:30.15brlcadstarseeker: some of the "AUTO" items in cmake shouldn't be, only the ones that are detection-based
21:30.26brlcade.g., optimized .. it's on and off
21:30.39brlcadauto doesn't make sense, you don't know :)
21:31.06brlcad64bit is detection-based but most of the compile flags aren't
21:34.37CIA-109BRL-CAD: 03brlcad * r47531 10/brlcad/trunk/ (5 files in 3 dirs):
21:34.38CIA-109BRL-CAD: formally mark all of the muves-specific commands as DEPRECATED, making them
21:34.38CIA-109BRL-CAD: report a deprecation warning if they're used. this includes em, e_muves,
21:34.38CIA-109BRL-CAD: l_muves, lm, read_muves, and t_muves. rationale is that those are
21:34.38CIA-109BRL-CAD: domain-specific extensions that don't really belong in brl-cad (they belong with
21:34.38CIA-109BRL-CAD: muves). they would make for a potentially suitable set of plugins to a
21:34.39CIA-109BRL-CAD: plugin-oriented libged, but not something we maintain and bundle.
21:43.44CIA-109BRL-CAD: 03brlcad * r47532 10/brlcad/trunk/BUGS: critical TIE bug encountered. seems to be corrupting the application structure. maybe related to or be known 32-bit bug.
21:44.13brlcad``Erik: that was supposedly a 64-bit compile, returning garbage in app structure and wrong segment hit count
21:56.42CIA-109BRL-CAD: 03brlcad * r47533 10/brlcad/trunk/BUGS: more info on TIE bug, return value seems wrong
21:58.25CIA-109BRL-CAD: 03lbutler * r47534 10/brlcad/trunk/src/rt/view.c: a quick hack to add ambient occlusion
22:29.15CIA-109BRL-CAD: 03lbutler * r47535 10/brlcad/trunk/src/rt/view.c: ambient occlusion computations included. set ambSamples non-zero to get sampling of ambient occlusion. set ambRadius non-zero to bound the distance considered "occluding".
22:39.54CIA-109BRL-CAD: 03bob1961 * r47536 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Incorporate snap-to-grid with polygon rectangle/circle creation. Update to_data_pick() and to_data_move() to work with data polygons. Change data_polys to data_polygons.
22:50.26CIA-109BRL-CAD: 03n_reed * r47537 10/brlcad/trunk/src/other/perplex/ (6 files): adding lemon parser; moving towards useful conversion of input
23:07.39CIA-109BRL-CAD: 03starseeker * r47538 10/brlcad/trunk/src/ (libged/CMakeLists.txt other/clipper/clipper.hpp): More clipper tweaks
23:10.18CIA-109BRL-CAD: 03lbutler * r47539 10/brlcad/trunk/src/rt/view.c: get two partitions by default. Shouldn't need more.
IRC log for #brlcad on 20111118

IRC log for #brlcad on 20111118

00:50.33CIA-109BRL-CAD: 03starseeker * r47540 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake ThirdParty.cmake ThirdParty_TCL.cmake): Make the third party options a bit more informative
01:08.31*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
01:12.30CIA-109BRL-CAD: 03starseeker * r47541 10/brlcad/trunk/ (TODO.cmake misc/CMake/BRLCAD_Util.cmake): Get the on/off toggles with auto option displaying their actual state, not just 'AUTO'
01:17.50CIA-109BRL-CAD: 03starseeker * r47542 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: AUTO isn't always in the front with new labels
01:23.34CIA-109BRL-CAD: 03starseeker * r47543 10/brlcad/trunk/CMakeLists.txt: Be more informative about what's going on with the CPU type, too
01:24.18starseekerbrlcad: hopefully that'll be more informative
01:27.19CIA-109BRL-CAD: 03starseeker * r47544 10/brlcad/trunk/TODO.cmake: add a todo item for the alias mechanism
02:49.23CIA-109BRL-CAD: 03starseeker * r47545 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Proof-of-concept implementation of a BRLCAD_OPTION macro that supports aliases for an option and appends documentation to a txt file.
02:50.16starseekerbrlcad: before I go too much farther with that I'd appreciate some feedback (in particular, how to write out the documentation)
02:54.04CIA-109BRL-CAD: 03starseeker * r47546 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: tweak
02:57.48CIA-109BRL-CAD: 03starseeker * r47547 10/brlcad/trunk/CMakeLists.txt: correct global example
03:04.42*** join/#brlcad abhi2011 (~chatzilla@117.200.86.6)
03:06.09CIA-109BRL-CAD: 03starseeker * r47548 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Wait - not handling things quite right with the macro. FORCE shouldn't be needed for that var in the GLOBAL file.
03:14.32*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
03:17.02CIA-109BRL-CAD: 03starseeker * r47549 10/brlcad/trunk/ (CMakeLists.txt src/other/CMakeLists.txt): Fix some of the stray variables that should be advanced
03:18.56CIA-109BRL-CAD: 03starseeker * r47550 10/brlcad/trunk/CMakeLists.txt: Hmm, that one is easier to change than I thought. Static libs, not the whole thing static
03:36.22abhi2011starseeker: there are mismatched if/endif pairs in brlcad_config.h : http://bin.cakephp.org/view/430932163
03:37.07abhi2011there are 2 endifs at the end
04:21.11*** join/#brlcad abhi2011 (~chatzilla@117.200.89.252)
04:35.11*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
04:52.56abhi2011probably its the cmakecache again, will clear and check
05:20.15*** join/#brlcad abhi2011_ (~chatzilla@117.200.89.252)
05:39.19starseekerabhi2011: yeah, that's usually the cache or a stale file, and after that series of changes to the build logic this evening you'll probably have to clear out and reconfigure
09:21.00*** join/#brlcad abhi2011 (~chatzilla@117.200.89.252)
09:48.34*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
14:25.25*** join/#brlcad abhi2011 (~chatzilla@117.200.80.155)
14:45.25*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:23.10CIA-109BRL-CAD: 03starseeker * r47551 10/brlcad/trunk/src/libpkg/example/CMakeLists.txt: Add libbu to the link lines...
15:37.18*** join/#brlcad abhi2011_ (~chatzilla@117.200.83.178)
16:03.08*** join/#brlcad Elrohir (~kvirc@p5B149B04.dip.t-dialin.net)
16:03.08abhi2011starseeker: the other errors are gone now, however 3 link errors are still there for libpkg : http://bin.cakephp.org/view/1734456229
16:25.56starseekerabhi2011: does commit 47551 fix it?
16:41.10abhi2011starseeker: yes thanks :), that did the trick
17:22.45CIA-109BRL-CAD: 03starseeker * r47552 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake ThirdParty.cmake ThirdParty_TCL.cmake): Tweaks and corrections to new CMake labeling.
17:25.00CIA-109BRL-CAD: 03n_reed * r47553 10/brlcad/trunk/doc/bison_to_lemon.txt: update on alias substitution
17:37.12*** join/#brlcad abhi2011_ (~chatzilla@117.200.83.178)
18:01.22abhi2011nope spoke too early :P
18:01.26abhi2011same error
18:01.52abhi2011http://bin.cakephp.org/view/412812688
18:03.40abhi2011well libged compiles , so I can proceed with testing the simulate command :)
18:11.48abhi2011so when a ray is travelling through a air region , is there some flag set in the struct partition for it (that is returned in the hit call back)
18:12.43abhi2011or is only way to check that a ray segment is travelling through air, to check the order of the out and in primitives
18:32.31CIA-109BRL-CAD: 03bob1961 * r47554 10/brlcad/trunk/src/ (libtclcad/tclcad_obj.c tclscripts/lib/Ged.tcl): These mods add the functionality to apply snap-to-grid to data polygon editing.
19:19.04*** join/#brlcad yukonbob (~bch@S01060024a5c9dad4.ok.shawcable.net)
19:19.09yukonbobhello, #brlcad
19:19.12brlcadhello
19:19.34yukonbobhey brlcad :) -- how're things?
19:19.47yukonbobseeing lots of interesting discussions in newsletters.
19:20.25brlcadusual, busy, fun, frustrating, interesting, difficult, routine, new, etc
19:20.59yukonbobwhat's "new"?
20:22.27*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
20:53.36CIA-109BRL-CAD: 03n_reed * r47555 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.c perplex.h scanner.re template.c): pass app data to lemon parser; first try at embellishing input
21:03.04starseekeryukonbob: any luck with making the tcltk 8.6 branch of BRL-CAD/
21:03.10starseeker?
21:03.31yukonbobstarseeker: haven't even tried yet.
21:04.31yukonbobI have a local copy and installation; has been a while since I've played w/ the build, so I'd retry that, confirm it works. The code base will be out-of-date w/ current repo, *but* should be a working piece, which is the important part.
21:04.45CIA-109BRL-CAD: 03brlcad * r47556 10/brlcad/trunk/src/rt/view.c: retStatus is unused
21:05.09yukonbobfrom there, pull changes from trunk -> 8.6, test, fix, test, fix, commit, lather, rinse, repeat.
21:09.02CIA-109BRL-CAD: 03brlcad * r47557 10/brlcad/trunk/src/librtserver/rtserverTest.c: remove/comment out unused code. removes -a option since use_air isn't used.
21:09.25starseekerif the changes for 8.6 are something we can integrate back into trunk, it might make your life easier
21:10.13CIA-109BRL-CAD: 03starseeker * r47558 10/brlcad/trunk/src/libpkg/example/CMakeLists.txt: Ah, right - need special compile flags for MSVC... (ugh)
21:11.48yukonbobstarseeker: the work I've got so far is as it relates to my work w/ NetBSD, modularization, and BRLCAD. I'll see how it works; I know that I'm not at tip of repo, and that I've tried/failed w/ more recent code; I'll take stock though, and get something (with a description of that "something") committed.
21:13.35starseekerarchivist: does 47558 do the trick?
21:13.40starseekeryukonbob: sounds good!
21:14.02starseekerwhen you say "modularization", what are you referring to?
21:15.04brlcadyukonbob: more nurbs, physics engine, geometry editing goodness, cmake stabilizing, archer revitalizing, ...
21:15.34brlcadgetting 8.6 tested and udpated would be pretty helpful
21:15.56yukonbobwill need to come to know nurbs. and is also still pretty interested in (and may have work for) dsp.
21:16.18yukonbobdsp still a stable, maintained, first-class citizen in BRLCADville?
21:16.25brlcaddsp is awesome
21:16.37brlcadunderutilized and underdocumented, but good stuff nonetheless
21:16.50starseekerfor head-scratching values of "maintained" :-P
21:16.58yukonbobdsp was one of my first forrays into brlcad, and I think my first bug-report ;)
21:17.26yukonbobanyway -- I'll get my scratch-work massaged and committed.
21:17.42brlcadlots of ways it can be improved further still, but hard-pressed to find better in-memory solid geometry terrain representation on the scale it supports
21:17.50yukonbobwas not a fan of 8.5, but -is- a fan of 8.6, so happy to have that a side-effect of his work.
21:18.01starseekersweet
21:18.06CIA-109BRL-CAD: 03n_reed * r47559 10/brlcad/trunk/src/other/perplex/ (scanner.re template.c): use re2c syntax for setting conditions
21:18.12starseekercan build 8.6 with CMake - took some pains to be sure I could, actually
21:18.23brlcadwell, as you noted.. you do still have commit ability :)
21:18.39starseekerneeds to get a TIP written up - would REALLY love to have the CMake build logic just "there" in 8.6 final
21:21.28starseekeryukonbob: I need to set up a virtual machine with NetBSD so I can try a build - any recommendations on pre-cooked VirtualBox images?
21:23.21yukonbobstarseeker: no...
21:23.40yukonbob1s.
21:24.14yukonbobstarseeker: virtualbox == that sun vm?
21:24.34yukonbobsees "yes".
21:25.14CIA-109BRL-CAD: 03brlcad * r47560 10/brlcad/trunk/ (9 files in 9 dirs):
21:25.15CIA-109BRL-CAD: rename BRLCAD-CPU_TYPE and CMAKE_CPU_TYPE to BRLCAD-WORD_SIZE and
21:25.15CIA-109BRL-CAD: CMAKE_WORD_SIZE respectively so as not to imply chip type or architecture. CPU
21:25.15CIA-109BRL-CAD: may be multimode as could the compiler, so it's not a good moniker. also
21:25.15CIA-109BRL-CAD: consistently use either ##BIT or ##-bit styles when referring to the size in
21:25.15CIA-109BRL-CAD: text.
21:26.02starseekerbrlcad: awesome, thanks!
21:26.08brlcadstarseeker: so I'm leaning more towards renaming all the BRLCAD- cases to BRLCAD_ grouping all vars together, for improved usability
21:26.35starseekernods - sounds good. I have no particularly strong feelings on that, so whatever you feel is best
21:26.51brlcadit'd be nice to have subgroupings, but not at that usability crux since we'd still want to document what it really is
21:27.02brlcadthen the aliases can just be shorthand and typo preventions
21:27.14starseekernods
21:27.15brlcadnot every _- permutation :)
21:29.32CIA-109BRL-CAD: 03starseeker * r47561 10/brlcad/trunk/src/libpkg/example/ (client.c server.c): Hmm... trying to send a message back to the client from the server. Doing something wrong...
21:31.43starseekerI suppose I should have known it wouldn't be that simple...
21:36.58yukonbobstarseeker: re: nbsd -- nothing I see off top of head.
21:37.08starseekerno problem
21:37.54yukonbobbrl-cad still maintains own build server?
21:38.19starseekerum... you mean brlcad's setup?
21:38.42yukonbobnot sure -- I've had an account on what I thought was a brl-cad machine in past.
21:39.33starseekeryeah, that's probably it - yeah, he's still got it up
21:39.47yukonbobonly wondering for same reasons you're wondering about nbsd -- If there was some other box that's linux or fbsd or $whatever, just another opportunity to test build/run, shake out bugs, etc., etc.
21:40.08starseekerhmm... well, here's a bunch of images... no netbsd though http://virtualboxes.org/images/
21:40.38starseekercome to think of it, that might be the opensolaris image I grabbed
21:41.05starseekerhopes he remember how to get into that - it was set up for building, and it's a long shot whether that could be done again
21:41.06yukonbobah -- my account is still good.
21:41.27yukonboboh wow. timewarp.
21:41.29yukonbob:)
21:41.34starseekerhehe
21:41.44yukonbobs'all good in the 'hood. ;)
21:58.40brlcadstarseeker: fyi, I did a quick check and confirmed that the server should be able to send back to the client bidirectionally
21:58.48brlcadyour comment yesterday didn't sound right..
21:59.34brlcadfbserv sends back error notifications to the client being one relatively obvious example
22:00.51brlcadthat's a pretty nifty virtualization OS list .. would be great for automated compilation testing for someone to set up
22:01.21brlcadrun vm with each OS image, add brl-cad sources, compile, report to dashboard
22:01.45brlcadshudders at the awesome power of that
22:05.16starseekerwas discussing that with some of the GSoC guys
22:05.49brlcadinteresting, I was too
22:05.58starseekerJenkins is apparently one of the relevant tools for managing something like that...
22:06.16brlcadmore for gci purposes, though -- provide an image completely preconfigured, go!
22:06.18yukonboba build dashboard?
22:06.27starseekernods
22:06.39yukonbobcbuild
22:07.08yukonboberr. ctest.
22:07.33starseekeroh - we don't have ctest integrated yet
22:07.38yukonbobhttp://www.vtk.org/Wiki/CMake_Testing_With_CTest <--- w/ cdash, or dart...
22:07.56yukonbobhas never actually used these, but is aware.
22:08.49yukonbobout.
22:08.54yukonbobchat later, cadheads.
22:08.57starseekerlater!
22:09.04brlcadjenkins is one of the top ones
22:09.17starseekerhmm https://wiki.jenkins-ci.org/display/JENKINS/VirtualBox+Plugin
22:09.18brlcadhudson is a fork that seems more promising
22:09.38brlcadcruisecontrol is the old steadfast best
22:09.54starseekerum... thought jenkins was a fork of hudson?
22:09.57brlcadbuildbot is one of the newercomers with some neat features
22:10.45brlcadsorry, that's right
22:11.48brlcad"Both the Jenkins and Hudson projects appear to consider the other to be a fork."
22:12.04brlcadmore Oracle stupidity
22:13.09CIA-109BRL-CAD: 03bob1961 * r47562 10/brlcad/trunk/ (3 files in 3 dirs): Added the mechanism for sketching out elliptical shaped polygons.
22:13.11brlcadI think any one of those four choices would be perfect for our needs, it's mostly just needing someone to champion setting it up proper
22:13.36starseekerbrlcad: OK, I'll take a look at fbserv
22:14.26brlcadsuggest just trying to figure it out with your own example still :)
22:14.59brlcadmaster of your own domain and whatnot
22:15.14brlcadplus it then requires really understanding what state both client and server are in
22:15.43starseekerdoen't want to understand pkg... just wants it to work and go away...
22:15.44brlcadput printing statements before and after all of your send() and recv() statements in both client and server, so you can see who is waiting on what
22:16.53brlcaddon't think that's a productive mindset
22:17.00brlcadit's not a means to an end, we use it already
22:17.24brlcadso you either want to learn it so you can/could use it or debug it or extend it, or you leave it to someone else...
22:18.22starseekerfair enough
22:18.32brlcadthat would even be the case if we picked up some 3rd party package .. it's all fine and dandy when it works, but then it's a brick wall black box when anything goes wrong (which it eventually always does)
22:19.15velociostrichActivity on this channel? Unheard of!
22:19.23velociostrichgoes back into hiding
22:19.44brlcadvelociostrich: it's usually like this most days...
22:19.47CIA-109BRL-CAD: 03bob1961 * r47563 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Removed junk that was mistakenly included with the previous commit.
22:19.49brlcadsave maybe for last week
22:20.08velociostrichI wouldn't know, I'm not in here often, but when I have been I rarely noticed activity
22:20.35velociostrichBesides the 'e' command, is there any way to get a nicer preview of work in mged ala other cad packages, e.g., opencascade based alternatives?
22:20.41brlcad*shrug*
22:20.41velociostrichiirc it was 'e', anyway
22:21.02brlcadvelociostrich: you can render via raytracing (File menu)
22:21.29velociostrichYes, I do realize that
22:21.32brlcadfor simple models, you can use the E or ev commands to get a polygonal wireframe
22:21.42velociostrichhow do e and ev differ?
22:21.58brlcade just draws the fundamental wireframe
22:22.05brlcadev evaluates a polygonal wireframe
22:22.18brlcadE also evaluates, but with a slightly different algorithm
22:22.43brlcadyou probably are looking for shaded display support, which is available for certain types of models but not all so it's disabled by default
22:23.01brlcadfuture release will enable shaded display support for all geometry types
22:23.19velociostrichstrange, it seems that ev is having some depth buffer related issues (Does brlcad use a depth buffer?)
22:23.30velociostrichthings on top of things that shouldn't be
22:23.34brlcadthe depth buffer can be turned on/off under Misc
22:23.59brlcadalong with depth lighting, and a few other modes
22:25.31velociostrichaha
22:25.48velociostrichalthough it seems that the depth buffer doesn't work unless Z clipping and the buffer are enabled
22:25.57brlcadstarseeker: maybe you can convince bob to make that nsegs=30 dynamically adjust
22:26.09brlcadvelociostrich: yep, iirc that sounds right
22:26.45velociostrichstrange
22:28.16velociostrichMight I ask if there is any particular reason for the use of Tk and not a (as far as I know, ignorant as I am) more modern toolkit like Qt/Gtk for Archer (which afaik is much newer than mged)?
22:30.13CIA-109BRL-CAD: 03brlcad * r47564 10/brlcad/trunk/ (25 files in 20 dirs): rename all of the BRLCAD- cmake variables to BRLCAD_ so we can consistently only use underscores everywhere. should help improve simplicity of docs and use.
22:30.18brlcadvelociostrich: archer is still mged, just the project name -- it's a refactoring of mged's existing code from pure tcl to itcl
22:30.33velociostrichoooh
22:30.42brlcadmain reason is that tcl/tk was adopted long before any of the modern toolkit's existed
22:30.53velociostrichYeah, I assumed as much
22:30.59brlcadqt is on our horizon for archer's eventual replacement, couple years out on our planning schedule
22:31.20velociostrichYeah, from and end-users' standpoint, Tk makes Archer/mged look dated unfortunately
22:31.35velociostrichI've noticed that most people are quick to judge a book by its cover
22:31.37brlcadstill need to refactor more of mged's internal engine code down into lower library layers so the new GUI doesn't have to reinvent the wheel
22:32.15brlcadin all fairness, Tk can be made to look like most modern GUIs... it just takes a bit of effort to get off the defaults
22:32.25velociostrichperhaps
22:32.32brlcadwe just use the defaults because there are more pressing engine matters to develop
22:32.40velociostrichI can understand that
22:33.02velociostrichEspecially considering the KLOCs you guys have on your hands
22:33.04brlcadif you'd like to help in that regard (or library refactoring or whatever really), have at it
22:33.14brlcadlemme know how I can help you get started ;)
22:33.16starseekerarcher is better that way than mged - we're mostly using the new tile/ttk widgets there
22:33.19velociostrichIf only I had time, I would :/
22:33.45brlcadyou just need a mutual itch to scratch ;)
22:33.58brlcada project that is interesting and tangible perhaps
22:34.03velociostrichAnd time
22:34.33brlcadtime is merely a matter of priorities
22:34.43brlcadif you had that itch, some need, you'd scratch it
22:34.53brlcadbecause itchy things get scratched
22:34.54brlcad:)
22:35.40velociostrichYou're damn right, now stop enticing me before my priorities go out of wack for a few weeks while I do that ;)
22:35.54CIA-109BRL-CAD: 03tbrowder2 * r47565 10/brlcad/trunk/INSTALL.cmake: give a tad bit of help for a novice cmake builder; indent the configuration args to cmake; eliminate the old autotools stuff to eliminate confusion; show as a work in progress
22:37.12velociostrichAlso, out of curiosity, do you know if the ARL still uses BRL-CAD, or have they abandoned it in favor of Autocad and friends?
22:38.15brlcadvelociostrich: yep, still heavily used
22:38.50brlcadit's pretty much core business to the DoD for the foreseeable decade
22:39.00velociostrichinteresting
22:39.03velociostrichlikely with certain extras that the public won't ever see, though
22:39.12velociostrichnamely extra ballistics bits
22:39.38velociostrichWhich I assume was the point of it being solid geometry based and having the raytracing library and all that
22:39.39brlcadthere are other CAD packages that have to interoperate with more these days than before, so strong focus on STEP import, for example, so we can bring in external CAD models without changing the representation format
22:39.57brlcadthose extra ballistic bits aren't part of brl-cad, never have been
22:40.24velociostrichYes, but would have used the raytracing library, correct?
22:40.29brlcadthose bits call into our core libraries, which are built for exactly that purpose (and are still pretty much the best at it barnone)
22:40.39velociostrichYes, that's what I meant
22:41.56velociostrichY'know, that makes me wonder if perhaps brlcad's raytracing library might be well suited to the games industry; from what I understand AI makes heavy use of raytracing for pathfinding and such, and they claim it's quite expensive to compute
22:42.16velociostrichwhich I think is typically done using whatever partitioning scheme they're using
22:42.29velociostrichwhich is less than ideal
22:42.30brlcadit is very well suited for that purpose
22:42.57brlcadused within DoD by a couple groups playing wargames in that way (sorta)
22:43.00CIA-109BRL-CAD: 03n_reed * r47566 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re template.c): changed token text allocation scheme to be leak resistant
22:48.17brlcadstarseeker: /home/sean/brlcad/src/libpkg/example/server.c:117:10: error: variable ?bytes? set but not used [-Werror=unused-but-set-variable]
22:48.18CIA-109BRL-CAD: 03bob1961 * r47567 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Dynamically calculate the number of segments used to approximate circles and ellipses using the window size.
22:48.53starseekerbrlcad: hang on - will be doing a commit in a sec anyhow
22:54.03CIA-109BRL-CAD: 03starseeker * r47568 10/brlcad/trunk/src/libpkg/example/ (client.c server.c): Back to basics - don't worry about the file, just dirt simple back-and-forth.
22:54.14starseekerbrlcad: convinced ;-)
22:56.00*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:12.10starseekerok, I see why it was doing what it was doing, I think...
23:12.41starseekerbrlcad: thanks for the print statement suggestion, that helped
23:12.59starseekerdidn't realize it didn't break out of the while loop after completing the file transfer
23:30.43*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
23:35.38*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
23:43.08*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
IRC log for #brlcad on 20111119

IRC log for #brlcad on 20111119

01:48.23brlcadstarseeker: np
02:06.58*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
03:14.14CIA-109BRL-CAD: 03108.21.96.185 07http://brlcad.org * r3243 10/wiki/Category:Summer_of_Code: Google Money is Dirty Money
03:26.53*** join/#brlcad abhi2011 (~chatzilla@117.200.86.187)
03:31.47CIA-109BRL-CAD: 03brlcad * r47569 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: (log message trimmed)
03:31.47CIA-109BRL-CAD: basing the number of segments off of a chord length that's 5% of the view width
03:31.47CIA-109BRL-CAD: will still create chunkly segments (50px long for a 1024 display) for large
03:31.47CIA-109BRL-CAD: circles and sub-pixel chords for small circles (less than 20px). instead, try
03:31.47CIA-109BRL-CAD: basing the size off of the circle's circumference in terms of pixels. this uses
03:31.48CIA-109BRL-CAD: a chord length of 4px so the circles are always relatively smooth regardless of
03:31.49CIA-109BRL-CAD: size. assumes from glancing through the logic that 'r' is actually the diameter
03:33.44CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:108.21.96.185]] with an expiry time of infinite (anonymous users only, account creation disabled): Inserting nonsense/gibberish into pages
03:33.54CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[Category:Summer of Code]]": idiot
03:35.37CIA-109BRL-CAD: 03Sean 07http://brlcad.org * r3244 10/wiki/Category:Summer_of_Code: add some content
03:42.48*** join/#brlcad yukonbob (~bch@S01064ce67640d81d.ok.shawcable.net)
03:42.52yukonbobhello, #brlcad
04:19.37*** join/#brlcad abhi2011_ (~chatzilla@117.200.84.2)
04:53.59CIA-109BRL-CAD: 03abhi2011 * r47570 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Started adding air gap detection code.
05:05.09CIA-109BRL-CAD: 03brlcad * r47571 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: there were two places a chord length was being calculated, one circular and one elliptical. looks like the diameter in this second section is the greater of the x or y delta.
05:16.05*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
05:46.11abhi2011brlcad: setting rtip->useair = 1  is sufficient for getting air regions , reported as one of the hit regions ?
06:20.37*** join/#brlcad abhi2011_ (~chatzilla@117.200.84.2)
06:56.06abhi2011http://imageshack.us/photo/my-images/192/forcei.png/
06:57.02abhi2011no airgaps seem to be reported, there must some setting in the rt_i* I am missing
06:58.54CIA-109BRL-CAD: 03abhi2011 * r47572 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c): Trying to convert the air regions to hit regions, so they are inserted in the hit regions list.
11:14.32*** join/#brlcad merzo (~merzo@53-232-132-95.pool.ukrtel.net)
11:21.06*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
12:16.09*** join/#brlcad abhi2011 (~chatzilla@117.200.90.203)
12:41.33*** join/#brlcad abhi2011_ (~chatzilla@117.200.90.203)
13:28.04abhi2011SIGPIPE seems to be exposed to the windows compile : ..\..\..\..\brlcad\src\libpkg\example\server.c(221) : error C2065: 'SIGPIPE' : undeclared identifier
13:31.18CIA-109BRL-CAD: 03abhi2011 * r47573 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c): Added initial code to detect and show air gaps.
14:49.39*** join/#brlcad milamber1 (~devlin@d118-75-244-176.try.wideopenwest.com)
15:01.27*** join/#brlcad abhi2011_ (~chatzilla@117.200.84.242)
15:50.18CIA-109BRL-CAD: 03abhi2011 * r47574 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h): Committing the logic for airgaps in case I need to use it later, before switching to the proper one using a_onehit = 0
16:11.06CIA-109BRL-CAD: 03starseeker * r47575 10/brlcad/trunk/src/libpkg/example/server.c: Windows doesn't like the SIGPIPE stuff.
16:31.47abhi2011thanks
16:31.54starseekernp
16:33.39abhi2011haha..not so fast
16:33.45abhi2011more incoming : http://bin.cakephp.org/view/1415770574
16:33.48abhi2011:) :)
16:34.58abhi2011this opengl linking thing seems to turn up in many places
16:46.25starseekerum
16:48.01starseekerah - brlcad changed a lot of the variable names
16:48.13starseekeryou may need to clean out your cache and re-run CMake
17:01.31*** join/#brlcad abhi2011_ (~chatzilla@117.200.84.242)
19:09.39abhi2011yep finally compile went ok
19:31.52*** join/#brlcad yukonbob (~bch@S01060024a5c9dad4.ok.shawcable.net)
20:38.50brlcadstarseeker: caution on r47575, should understand what that does
20:49.29CIA-109BRL-CAD: 03brlcad * r47576 10/brlcad/trunk/src/libpkg/example/CMakeLists.txt: there's no point in conditionalizing the BRLCAD_DLL compile flag. it's only used on Windows already.
20:51.17CIA-109BRL-CAD: 03brlcad * r47577 10/brlcad/trunk/bench/CMakeLists.txt: more unnecessary conditionalization of preprocessor flags
21:02.00CIA-109BRL-CAD: 03brlcad * r47578 10/brlcad/trunk/src/ (6 files in 6 dirs): more removal of unnecessary MSVC conditionalization for Windows. all of the MSVC sections outside of the very top-level CMakeLists.txt do not belong there, low-hanging poisoned fruit that should be gotten rid of.
22:40.08CIA-109BRL-CAD: 03brlcad * r47579 10/brlcad/trunk/TODO.cmake: add two items. eliminate MSVC from non-top-level CMakeLists.txt files and add deprecation warnings.
22:40.18starseekerbrlcad: I conditionalized BRLCAD_DLL to keep it out of the non-MSVC command lines in VERBOSE mode - intent was to avoid cluttering the gcc lines with non-functional stuff
22:41.50starseekerand removing some of the MSVC flags may get into other issues - like getting libpc working with Visual Studio...
23:59.42CIA-109BRL-CAD: 03tbrowder2 * r47580 10/brlcad/trunk/HACKING.cmake: add references to Debian packages and Fedora rpms
IRC log for #brlcad on 20111120

IRC log for #brlcad on 20111120

00:01.07CIA-109BRL-CAD: 03tbrowder2 * r47581 10/brlcad/trunk/doc/README.Linux: add info on Debian packages and Fedora rpms
03:46.21*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
04:52.41*** join/#brlcad abhi2011 (~chatzilla@117.200.84.98)
05:03.02*** join/#brlcad Forth (~Forth@92.242.118.253)
05:03.45*** part/#brlcad Forth (~Forth@92.242.118.253)
06:15.27*** join/#brlcad abhi2011_ (~chatzilla@117.200.92.64)
09:47.15*** join/#brlcad abhi2011 (~chatzilla@117.200.92.64)
09:48.37abhi2011hmm, the windows compile went fine, but mged seems to have lost its windows
09:48.58abhi2011says libpng15d.dll is missing from your computer
09:52.03abhi2011ok, its working now :)
12:02.26*** join/#brlcad Forth (~Forth@92.242.118.253)
12:03.50*** part/#brlcad Forth (~Forth@92.242.118.253)
12:28.09*** join/#brlcad abhi2011 (~chatzilla@117.200.82.135)
12:30.53*** join/#brlcad abhi2011_ (~chatzilla@117.200.82.135)
IRC log for #brlcad on 20111121

IRC log for #brlcad on 20111121

02:52.29*** join/#brlcad ibot (~ibot@rikers.org)
02:52.29*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
03:49.08*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
07:37.45*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
08:11.18*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
09:14.28*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
13:01.00*** join/#brlcad abhi2011 (~chatzilla@117.200.90.204)
13:58.00*** join/#brlcad abhi2011 (~chatzilla@117.200.88.113)
14:30.48*** join/#brlcad abhi2011 (~chatzilla@117.200.88.113)
14:44.31brlcadstarseeker: I know, and that was one of the points being made .. they're never "worth it" in the long run :)
14:45.23brlcadat least not when maintaining excessive portability (backwards and forewards) is the goal
14:59.38brlcadand it's worth saying that "it's all good" given past misinterpretations of ranting -- just a lot to say on the topic ;)
15:12.49starseekerdo I undersdand you correctly that you want to change the conditionalized mechanism currently being used in the .h files?
15:13.01starseekers/undersdand/understand
15:13.07starseekerkick brain into gear
15:13.55starseekeror just change how the CMake logic triggers it?
15:19.16starseekeris certainly in favor of excessive portability :-) - just not sure how that blasted import/export trick Windows needs can be made to play nicely
15:21.12starseekerboth the shared library and executable targets currently need BRLCAD_DLL with MSVC, but if I understand correctly the static libraries *shouldn't* have it
15:23.43CIA-109BRL-CAD: 03brlcad * r47582 10/brlcad/trunk/src/libbu/vls.c:
15:23.43CIA-109BRL-CAD: it was an interesting idea, but not a great one. did a quick test to see how
15:23.43CIA-109BRL-CAD: much time might be gained if we skipped the initial vls allocation. looked to
15:23.43CIA-109BRL-CAD: be about 25% for bu_vls_printf() which is marginally interesting at best.
15:23.43CIA-109BRL-CAD: probably not worth the complexity and long-term maintenance (error-prone), at
15:23.44CIA-109BRL-CAD: least for now.
15:23.57starseekerwhich rules out any global setting of it, unless... perhaps we want to have toplevel BRLCAD_SHARED_COMPILE_FLAGS and BRLCAD_STATIC_COMPILE_FLAGS variables?
15:32.18brlcadstarseeker: the .h files still are conditionalized, changing how cmake triggers
15:41.35brlcadprobably don't need different flag variables
15:43.25brlcadif you conditionally set flags and add them (as vars), then those variables you add them to are implicitly conditionalized too
15:45.15brlcadI think the problem stems from the logic in bu.h presently only providing BU_EXPORT_DLL with no corresponding BU_IMPORT_DLL
15:45.41brlcadnot export does not mean import .. e.g., when compiling static
15:46.46brlcadso that could simplify to a three-way if/elseif/else toggling on just those two variables -- then cmake has to set either BU_EXPORT_DLL or BU_IMPORT_DLL or neither
15:48.19brlcadwith that, BRLCAD_DLL can go away and a cmake test is needed to determine whether __declspec(dllimport) works .. if it does, then variables get triggered
15:51.45brlcadif (dllimport_works) then LIBBU_CPPFLAGS+="-DBU_EXPORT_DLL" ; LIBBU_STATIC_CPPFLAGS+="..nada.." ; bu-using non-static apps CPPFLAGS+="-DBU_IMPORT_DLL"
15:52.48brlcadmay need a layer of variables in there to avoid duplicating information all over the place but that's the gist in pseudocode
16:40.41CIA-109BRL-CAD: 03brlcad * r47583 10/brlcad/trunk/NEWS:
16:40.41CIA-109BRL-CAD: butler added an initial stab and providing ambient occlusion to rt. this is
16:40.41CIA-109BRL-CAD: presently disabled by default and enabled with the ambSamples and ambRadius rt
16:40.41CIA-109BRL-CAD: variables. more work is needed on controlling the sample pattern and noise.
16:42.23*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
17:43.04CIA-109BRL-CAD: 03n_reed * r47584 10/brlcad/trunk/doc/bison_to_lemon.txt: more on assigning types to symbols
17:45.49CIA-109BRL-CAD: 03n_reed * r47585 10/brlcad/trunk/src/other/perplex/ (scanner.re template.c): don't allocate new token string without freeing existing string
18:04.28CIA-109BRL-CAD: 03n_reed * r47586 10/brlcad/trunk/src/other/perplex/ (parser.y scanner.re): fix separator pattern; properly close output scanner
18:26.59*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
19:30.09*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
19:55.47*** join/#brlcad Forth (~Forth@92.242.118.253)
19:57.53*** part/#brlcad Forth (~Forth@92.242.118.253)
20:13.07CIA-109BRL-CAD: 03n_reed * r47587 10/brlcad/trunk/src/other/perplex/ (Makefile.local perplex.h scanner.re template.c): fixed start condition initialization; removed requirement for EOF rule in input
20:27.47brlcadstarseeker: n_reed: e-mail sent, assistance requested
20:28.04*** join/#brlcad merzo (~merzo@19-255-132-95.pool.ukrtel.net)
21:25.33*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
22:46.58*** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
22:47.18*** part/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
22:53.09*** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
IRC log for #brlcad on 20111122

IRC log for #brlcad on 20111122

00:20.33*** part/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com)
01:12.10*** join/#brlcad n_reed (~nreed1@c-68-55-142-136.hsd1.md.comcast.net)
01:52.53*** join/#brlcad CIA-61 (~CIA@cia.atheme.org)
05:27.54*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
05:53.49brlcadwanders into the night
06:20.29n_reedobserves the night from a safe distance
12:35.23starseekerslept through the night...
12:35.46starseekerhangs head in shame
14:46.49*** part/#brlcad n_reed (~nreed1@c-68-55-142-136.hsd1.md.comcast.net)
15:21.36*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:49.15CIA-61BRL-CAD: 03indianlarry * r47588 10/brlcad/trunk/src/conv/CMakeLists.txt: Wrapped ON_DLL_IMPORTS definition for MSVC only.
17:01.09CIA-61BRL-CAD: 03brlcad * r47589 10/brlcad/trunk/TODO: looks like twist is also not an option, so make sure we can set the size and rotation
17:07.02CIA-61BRL-CAD: 03brlcad * r47590 10/brlcad/trunk/TODO: uv callback missing for BoT, NMG, and BREP
17:10.45starseekerbrlcad: if I'm understanding correctly (re: understanding r47575) ignoring SIGPIPE is what allows the server to keep running when a pipe connection unexpectedly dies?
17:11.01starseekerso not having it means a client misbehaving can take down the server?
17:11.15starseekerwhat would be the cross-platform solution?
17:32.05``ErikI think that'd be more for the servers shell being jerked out from under it, like if your ssh dropped... not a socket issue
17:42.51CIA-61BRL-CAD: 03bob1961 * r47591 10/brlcad/trunk/src/libdm/ (dm-ogl.c dm-wgl.c): Ignore if less than 2 points.
17:54.53CIA-61BRL-CAD: 03n_reed * r47592 10/brlcad/trunk/ (doc/docbook/system/man1/en/obj-g.xml src/conv/obj-g.c): add r option to obj-g for setting orientation on imported bots
17:59.17CIA-61BRL-CAD: 03bob1961 * r47593 10/brlcad/trunk/ (4 files in 3 dirs): Add polygon contour mode for specifying arbitrary polygonal contours.
17:59.19*** join/#brlcad merzo (~merzo@72-4-133-95.pool.ukrtel.net)
18:07.57CIA-61BRL-CAD: 03bob1961 * r47594 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Change the number of segments calculation to reflect the fact that "r" is the radius.
18:26.19CIA-61BRL-CAD: 03starseeker * r47595 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake):
18:26.19CIA-61BRL-CAD: Ah - the '-' to '_' conversion ended up with BRLCAD_BUNDLED_LIBS being listed in
18:26.19CIA-61BRL-CAD: its own alias list. That exposes two problems - one it doesn't need to list
18:26.19CIA-61BRL-CAD: itself as an alias, and two the macro shouldn't be treating it as an alias when
18:26.19CIA-61BRL-CAD: it's the actual variable (Bad Things happen.)
19:05.49CIA-61BRL-CAD: 03indianlarry * r47596 10/brlcad/trunk/include/rtgeom.h: magic for solid type 'uint32_t ' not 'unsigned long', 'brep' debug command was broken where long not 32bit
19:22.14CIA-61BRL-CAD: 03bob1961 * r47597 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Update bindings for the top and bottom views to match MGED.
19:22.19CIA-61BRL-CAD: 03starseeker * r47598 10/brlcad/trunk/src/libpkg/example/server.c: put SIGPIPE ignore back in, wrapping it this time for platforms that don't define it (Windows)
19:23.41CIA-61BRL-CAD: 03starseeker * r47599 10/brlcad/trunk/src/libpkg/tpkg.c: tpkg should be checking for SIGPIPE too...
19:35.57*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
20:18.22CIA-61BRL-CAD: 03bob1961 * r47600 10/brlcad/trunk/ (include/ged.h src/libtclcad/tclcad_obj.c): Change matp_t members of ged_data_polygon_state to mat_t. Added gdps_rotation and gdps_origin to ged_data_polygon_state. Getting ready to export ged_polygons to sketches.
20:29.41CIA-61BRL-CAD: 03bob1961 * r47601 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: The number of segments calculations for circles and ellipses needs to be scaled by gv_scale because "r" is in view coordinates. Also set a minimum for the number of segments.
20:49.01*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
20:57.28CIA-61BRL-CAD: 03starseeker * r47602 10/brlcad/trunk/include/bu.h: Stub in an example for how the new declspec ifdef will look...
21:05.53CIA-61BRL-CAD: 03starseeker * r47603 10/brlcad/trunk/ (3 files in 2 dirs): Start preparing to use some kind of test for the declspec import/export flags - sub in a variable instead of MSVC platform conditional.
21:08.26starseekerbrlcad: was that example more what you were looking for (bu.h)
21:14.54CIA-61BRL-CAD: 03starseeker * r47604 10/brlcad/trunk/src/ (libged/CMakeLists.txt other/clipper/clipper.hpp): Try a localized test with libged and clipper...
21:17.57starseekerbrlcad: should timer-nt and timer42 in librt be folded back into libbu's timer?
21:25.21``Erikhas thought about doing that recently
21:29.39starseekerprobably should be done if we're going to remove the MSVC conditional pertaining to them...
IRC log for #brlcad on 20111123

IRC log for #brlcad on 20111123

01:19.35brlcadstarseeker: you still have to check if BU_EXPORTS is defined, else you can end up with a double-definition error
01:19.55brlcader, BU_EXPORT
01:22.37brlcadthe plural naming convention you pulled from opennurbs doesn't really apply to C code too (wasn't even necessary for opennurbs really, they're all the same macro)
01:23.23brlcadthat one's not a big deal, of course, just not necessary
01:24.20brlcadmaybe better to keep it consistent with opennurbs, that's fine too
01:44.19CIA-61BRL-CAD: 03brlcad * r47605 10/brlcad/trunk/include/bu.h: make sure BU_EXPORT isn't already defined (so callers have some means to override), and error out if caller tries to import and export simultaneously.
01:45.28CIA-61BRL-CAD: 03starseeker * r47606 10/brlcad/trunk/src/other/clipper/CMakeLists.txt: tweak clipper dll CMake logic.
01:46.12starseekerbrlcad: this still feels funny to me somehow - explicitly calling out the import with a library specific flag, rather than using the more "global" BRLCAD_DLL seems to complicate the build logic quite a bit...
01:46.14brlcadthat template should work well, how's it look?
01:48.24brlcadit does complicate matters some given each library has to be listed now, that was to be expected
01:48.43brlcadthe problem and benefit of BRLCAD_DLL is that it was global
01:48.59starseekerbrlcad:  don't we still need that last else case with the empty BU_EXPORT ?
01:49.03brlcadit effectively meant *_IMPORT_DLL
01:49.23starseekernods - finding myself thinking that wasn't such a bad idea, really...
01:50.17brlcadit's not a terrible idea but there are some downsides
01:50.39brlcadcan't make a target that both exports and imports (plugins, libraries)
01:51.22starseekerbrlcad: the "check for both definitions" case - will the logic ever get there?
01:51.26brlcadalso means that there's cross-library pollution which prevents core library components from standing on their own
01:51.29starseekershouldn't we be checking for that first?
01:51.34brlcade.g., a libbu distribution akin to apr
01:52.27brlcadyeah, you're right
01:52.31brlcadon both counts
01:52.57starseekerone sec..
01:53.40brlcadalready fixed
01:53.43CIA-61BRL-CAD: 03brlcad * r47607 10/brlcad/trunk/include/bu.h: starseeker right on both counts, need the empty BU_EXPORT so preprocessor makes the symbol go away and the error case needs to be tested first
01:53.52CIA-61BRL-CAD: 03starseeker * r47608 10/brlcad/trunk/src/other/clipper/clipper.hpp: Upgrade the export macro logic for clipper (hopefully)...
01:54.46starseekerdo we need BU_DLL_IMPORTS for a library that just links to librt?
01:56.15brlcadI don't remember the dll import/export rules that closely but I believe it depends how the library is defined
01:56.38starseekermm.  Well, I guess there's always the "try it and see" approach...  
01:56.41brlcadif librt imports bu/bn and exports it's symbols, then I *think* it'll look for their dll when librt is loaded
01:56.55starseekerguess I'll be playing with the windows build again tomorrow (joy...)
01:57.08brlcadif it doesn't import, they get linked static and have to be resolved at compile time
01:57.50starseekeris trying to decide if librt should define an RT_DEFINES variable that holds BU_DLL_IMPORTS, BN_DLL_IMPORTS, etc...
01:58.51brlcadto do it "proper", I believe so
01:59.25brlcadrather, it needs to have them defined when librt is compiled .. but not necessarily when rt is compiled
01:59.45brlcad(but can)
02:00.54brlcadit needs them when rt is compiled if librt doesn't import them or if it also uses bu/bn too (which it does)
02:02.08starseekerneeds to think tactically about how to set this up... would *really* suck to have to specify defines for executables per-exec instead of per directory
02:03.53starseekerprobably need to for exec targets in the same directory as a library (test apps, etc.) since I can't go defining both, but (say) in util I would prefer to "define 'em all and let the compiler sort it out", so to speak
02:12.14brlcadstarseeker: how about in a/the exec wrapper macro, have it look for variables matching the provided prefix -- then it's a naming convention all our libs use to define their vars in one place
02:12.43starseekeryou mean use the library list to go after the variables?
02:13.07starseekermight work, except when we send in libraries that aren't ours...
02:13.14brlcadsomething like BUILD_MY_EXEC(rt, LIBRT LIBBN LIBBU)
02:13.38starseekernods - BRLCAD_EXEC already has most of that
02:13.46brlcadwhich would then look for LIBRT_LIBS, LIBRT_CPPFLAGS, LIBRT_CFLAGS, LIBBN_LIBS, LIBBN_CPPFLAGS, LIBBN_CFLAGS, etc
02:14.01starseekercome to think of it...
02:14.30starseekeryeah, there might be a way to handle it there
02:14.39starseekerwill look into it tomorrow
02:14.51brlcadLIBRT_LDFLAGS might be different from LIBRT_LIBS
02:15.07brlcad-lrt vs deps -lbn -lbu -ltcl ...
02:15.19starseekercmake uses full paths for most things
02:15.37starseekerI can recognize when I'm looking at a full path (do so for the distcheck logic)
02:15.49brlcadpath isn't the issue
02:16.09brlcadit's what libraries are added to the link line (and in what order if you want to get pedantic)
02:16.26starseekerI was thinking to use the list of libraries passed to BRLCAD_EXEC
02:17.09starseekercouple ideas, actually
02:17.10brlcadright, but then if libraries are self-aware of their dependencies (and they are)
02:17.31brlcadthen you wouldn't need to specify all the (potential) dependencies any time a library is used
02:17.58brlcadlike my example above -- kind of silly to list libbn and libbu since librt requires them
02:18.11starseekeroh, I see...
02:18.14starseekerdifferent issue
02:18.16brlcadI couldv'e queried a var set by librt that told me bn, bu, etc
02:18.36brlcadthat could greatly reduce redundancy throughout the build files
02:19.06starseekernods... again less explicit though
02:19.55brlcadyet less error-prone too
02:20.20brlcadmost devs don't think very long about what the actual libs are, they copy-paste another similar and add libs until it compiles
02:20.40starseekertrue... the way we're trending here though, I'm going to *have* to write up some sort of detailed overview of what we're doing and why
02:21.42starseekergranting there are usually good reasons for what's being done, the further we get from "vanilla" the greater the hurdles become for a newbie to figure out what's happening and why
02:22.08brlcadalready warranted with any custom macro -- it's obvious to you now because you wrote it and you still remember
02:22.19starseekerright
02:22.38starseekerin fact, for a lot of reasons I'd *better* do it now
02:22.51starseeker's memory is... quirky
02:23.13brlcadmight let you clean out some unnecessary macros too if you attempt to document them :)
02:23.24brlcad"oh yeah .. no longer need this one"
02:23.48starseekerheh - one of the fundamental arguments for literate programming, actually - "if I have to explain to a human what I'm trying to do, it's hard to hide the stupid parts :-P"
02:24.00brlcadit actually looks like you already do some sort of lib dependency expansion in BRLCAD_ADDEXEC
02:24.32starseekeruh... where are you looking?
02:24.45brlcadjust looking at some binaries
02:24.53brlcadsrc/rt/CMakeLists.txt for example
02:25.04brlcadno mention of libbu, but guarantee they all use it
02:25.29starseekeractually that's probably just dumb luck
02:25.35brlcadheh
02:25.53brlcadenfeeds
02:26.43starseekerthat list is passed pretty much as-is to target_link_libraries - did it mainly because it cut a few hundred add_executable/target_link_libraries/install triplets down to a one-liner
02:27.10starseekers/a one-liner/one-liners/
02:27.20starseekeryeah, gotta get outta here
02:34.59*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
03:14.39*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
04:13.23CIA-61BRL-CAD: 03brlcad * r47609 10/brlcad/trunk/NEWS: nick added a new -r orientation option for the obj-g importer so you can specify 1/2/3 as values for unoriented, ccw, and cw orientation.
05:26.30brlcadstarseeker: then I'd wonder if cmake is doing some expansion for us since the libs deps are listed with the libs and it expands correctly
05:26.48brlcadeither way, somehow it's happening now, so that's a good sign
05:27.12brlcadinstalls cmake on gcc12 (openbsd sparc64)
06:26.23*** join/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com)
07:42.45*** join/#brlcad merzo (~merzo@193.254.217.44)
11:50.28CIA-61BRL-CAD: 03erikgreenwald * r47610 10/brlcad/trunk/include/bu.h: add missing #endif
12:12.02``Erikhm, anne mccaffrey passed
12:13.06``Erikdoom3 source released, too
13:36.21*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
16:37.07*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
16:37.07*** join/#brlcad 77CAA2ALN (~Technicus@DSLPool-net208-2.wctc.net)
16:59.53CIA-61BRL-CAD: 03brlcad * r47611 10/brlcad/trunk/HACKING: gentoo folks moved brl-cad from sci-misc to media-gfx
17:32.32brlcadstarseeker: any technical reason for the lack of blank lines in the cmake files?
17:33.17starseekeruh... not really
17:33.31brlcadk
17:34.04starseekercan't think of any offhand, although there may be a few cases where it matters (messages can't have stray end-of-line characters, for example...)
17:34.29starseekeror rather, they can but it messes with the formatting of the printed result
17:41.19brlcadthat's fine, it's more whether there was some reason the logic or macros prohibited it
17:42.37brlcadlike a C file without blank lines, a bit of a readability hindrance
18:12.40CIA-61BRL-CAD: 03brlcad * r47612 10/brlcad/trunk/misc/CMake/ (BRLCAD_CompilerFlags.cmake CompilerFlags.cmake): relax the comparisons to substring matches
18:14.22CIA-61BRL-CAD: 03brlcad * r47613 10/brlcad/trunk/CMakeLists.txt: similar, relax string comparisons. makes the unknown value test a little more robust
18:18.12CIA-61BRL-CAD: 03brlcad * r47614 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: trying to make some sense of the logic, add ws for readability
18:29.43CIA-61BRL-CAD: 03brlcad * r47615 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: simplify logic with relaxed substring searching
18:41.02CIA-61BRL-CAD: 03brlcad * r47616 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: more logic simplification. reorder IF/ELSE to avoid needing NOT, eliminate need for multiple comparisons by using substring comparison. reword cache string to indicate what action is being taken.
18:42.44CIA-61BRL-CAD: 03starseeker * r47617 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake:
18:42.44CIA-61BRL-CAD: Make an initial stab at support for library-wide usage of <LIB>_DLL_IMPORTS
18:42.44CIA-61BRL-CAD: approach to building with MSVC. This is just hte macro logic and (for the
18:42.44CIA-61BRL-CAD: moment, until the rest of this is worked out) the Windows build is almost
18:42.44CIA-61BRL-CAD: certainly well and truly busted.
18:48.13CIA-61BRL-CAD: 03starseeker * r47618 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: remove debug prints for now.
18:48.38CIA-61BRL-CAD: 03brlcad * r47619 10/brlcad/trunk/misc/CMake/ThirdParty.cmake:
18:48.39CIA-61BRL-CAD: big restructuring in support of better reporting for whether bundled or sys libs
18:48.39CIA-61BRL-CAD: are being used (and why). few cases weren't being handled and the string
18:48.39CIA-61BRL-CAD: STREQUAL testing was causing cmake to report warnings. simplify string
18:48.39CIA-61BRL-CAD: comparisons to substrings where applicable, reduce/reorder logic for clarity,
18:48.39CIA-61BRL-CAD: and reword messages for consistency.
18:52.33CIA-61BRL-CAD: 03starseeker * r47620 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: stray duplicate comment line
19:01.05CIA-61BRL-CAD: 03brlcad * r47621 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake:
19:01.06CIA-61BRL-CAD: sync up with the same that was done for ThirdParty_Tcl.cmake using consistent
19:01.06CIA-61BRL-CAD: printing statements (e.g., they might not be libs), relax to substring matching
19:01.06CIA-61BRL-CAD: and reduced logic where we can. inject blank lines, separators, and comments
19:01.06CIA-61BRL-CAD: for improved readabaility.
19:09.19CIA-61BRL-CAD: 03starseeker * r47622 10/brlcad/trunk/include/ (22 files): Convert all the include headers to the <LIB>_DLL_IMPORTS format
19:15.34CIA-61BRL-CAD: 03brlcad * r47623 10/brlcad/trunk/misc/CMake/ (33 files):
19:15.34CIA-61BRL-CAD: as these are build system infrastructure and not actual build rules, they should
19:15.34CIA-61BRL-CAD: include the requisite license headers and footers like any other source file.
19:15.34CIA-61BRL-CAD: CMakeLists.txt don't need the wrapping, but macro files should
19:26.11starseekerbrlcad: uh... - a lot of those Find* cmake macro files are based on other macro files, might want to be careful
19:26.43starseekerI'd have to dig back to make sure, but I think at least FindGL, FindX11 and FindYACC are based off of other macros
19:27.02starseekerI was waiting until things settled to do a thorough review of all of that
19:38.47CIA-61BRL-CAD: 03brlcad * r47624 10/brlcad/trunk/autogen.sh: given the magnitude of impact, add a massive deprecation notice to begin our requisite deprecation notification process. refer them to the INSTALL file for now since there's not (yet?) an equivalent step
19:39.23``Erikis seeing tons of cmake breakage right now, http://paste.lisp.org/display/126045
19:39.48brlcadlegally, that needs to happen asap and should have happened before a release was made with them
19:40.17starseekerk - I'll do a scan-through
19:41.21brlcadif they are mererly bundled for convenience, our header should be pulled or appended after theirs
19:41.36starseekermost of them are tweaked
19:41.52starseekermaybe all of them
19:45.34brlcadif it's not significant (like no logic changes, just additions of paths, removal of code, or just a couple lines) then our header is arguably not necessary
19:47.19brlcad``Erik: your build failure looks related to r47617, work in progress .. though my build curiously worked, maybe I need to wipe cache to hit it
19:47.58CIA-61BRL-CAD: 03starseeker * r47625 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake CheckCFileRuns.cmake): Add the full license text for ChechCFileRuns.cmake - need to fix up the rest of the Kitware-based files to have the full BSD license txt.
19:51.05brlcadstarseeker: do they use the same 3-clause license?
19:53.03brlcadif they do, there can just be 2 copyright lines instead of two copies of the text
19:53.07starseekerI believe so, give or take some minor wording and formatting...
19:53.19starseekertake a look at CheckCFileRuns.cmake, it's got both
19:54.06CIA-61BRL-CAD: 03starseeker * r47626 10/brlcad/trunk/misc/CMake/CheckPrototypeExists.cmake: CheckPrototypeExists.cmake is from KDE, flesh out their BSD license and add a link to the file origin
19:59.30CIA-61BRL-CAD: 03brlcad * r47627 10/brlcad/trunk/autogen.sh: move the deprecation section down so we're more sure echo -n work. still before anything is printed.
20:00.51CIA-61BRL-CAD: 03starseeker * r47628 10/brlcad/trunk/misc/CMake/FindLEMON.cmake: FindLEMON was originally based on FindBISON - note that fact. Trying to stay close to the formatting of 'standard' CMake modules for those that we might have a hope of getting accepted into CMake proper at some point.
20:03.11CIA-61BRL-CAD: 03starseeker * r47629 10/brlcad/trunk/misc/CMake/FindLEX.cmake: FindLEX.cmake is basically FindFLEX.cmake slightly generalized, and we already had ourselves listed in the 'standard' CMake BSD license. We may not even need this at all once the perplex/re2c/lemon work is complete...
20:04.07starseekermutter... looks like I got some of them "properly" containing the full license, but missed a few
20:04.44starseekerI think in the GL/X11 case I might have been hoping to get the changes accepted back... ah well, no matter
20:08.22CIA-61BRL-CAD: 03starseeker * r47630 10/brlcad/trunk/misc/CMake/ (FindGL.cmake FindX11.cmake FindZLIB.cmake): Add the rest of the 'full' licenses for the Kitware stuff - was hoping to commit these changes back to Kitware, but either way we'll have to hang on to these until we can require a modern enough CMake with the changes.
20:15.29CIA-61BRL-CAD: 03brlcad * r47631 10/brlcad/trunk/configure.ac: add a similar massive deprecation notice with an annoying pause to configure.
20:18.38CIA-61BRL-CAD: 03brlcad * r47632 10/brlcad/trunk/configure.ac: put a deprecation notice in the summary too since most people actually read it.
20:23.06CIA-61BRL-CAD: 03brlcad * r47633 10/brlcad/trunk/Makefile.am: last one, repeat the deprecation warning when they run autotools make too.
20:58.01CIA-61BRL-CAD: 03brlcad * r47634 10/brlcad/trunk/src/rt/view.c:
20:58.01CIA-61BRL-CAD: can't compile due to cmake errors, but add an ambOffset parameter so you can
20:58.01CIA-61BRL-CAD: control how far we pull away from a surface before shooting ambient rays. this
20:58.01CIA-61BRL-CAD: is intended to help 'smooth out' shots against polygonal models where you get
20:58.01CIA-61BRL-CAD: artifacts from hitting nearby/neighboring polygons.
20:58.09starseekerreflects that with the new open source SCL activity, he's probably going to need to beef up the FindSCL macro...
21:02.04CIA-61BRL-CAD: 03brlcad * r47635 10/brlcad/trunk/src/rt/view.c: reduce the code duplication in ambient occlusion. pulling the branch out of both loops is inconsequential to performance in the long term.
21:02.45CIA-61BRL-CAD: 03starseeker * r47636 10/brlcad/trunk/ (9 files in 9 dirs): This should get the build working again on non Windows platforms... also, start the process of clearing out BRLCAD_DLL
21:04.18starseekerbrlcad: something else is busted - LEMON_EXECUTABLE is set to NOTFOUND
21:06.10starseekerand the global BRLCAD_BUNDLED_LIBS flag being set to bundled isn't turning everything on anymore
21:20.18brlcadcurious, I didn't modify FindLEMON
21:21.15brlcadthe BRLCAD_BUNDLED_LIBS isn't too surprising, couldn't test it with the breakage and the logic in BRLCAD_Util seems quite a mess..
21:40.14brlcadlooks like the problem is actually in ThirdParty, fix forthcoming
21:42.22CIA-61BRL-CAD: 03bob1961 * r47637 10/brlcad/trunk/include/ged.h: Added gdps_scale to ged_data_polygon_state.
21:52.05*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
21:58.59CIA-61BRL-CAD: 03brlcad * r47638 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: getting a feel for how the aggregate BRLCAD_BUNDLED_LIBS was implemented. this makes ccmake report proper propagation of the parent BUNDLED (AUTO) setting (but still keying off AUTO at higher precedence than BUNDLED).
22:35.56CIA-61BRL-CAD: 03brlcad * r47639 10/brlcad/trunk/misc/CMake/ThirdParty.cmake:
22:35.57CIA-61BRL-CAD: this seems to get things back to working for the parent BRLCAD_BUNDLED_LIBS
22:35.57CIA-61BRL-CAD: option. wasn't accounting for a stray STREQUAL in the parent logic and wasn't
22:35.57CIA-61BRL-CAD: setting the ON/OFF variable consistently with the statements being printed
22:48.01CIA-61BRL-CAD: 03brlcad * r47640 10/brlcad/trunk/misc/CMake/ThirdParty.cmake:
22:48.01CIA-61BRL-CAD: if BRLCAD_BUNDLED_LIBS is set to SYSTEM and system-installed libs aren't
22:48.01CIA-61BRL-CAD: available, it's not our problem -- let them proceed as if it was installed and
22:48.01CIA-61BRL-CAD: found since that's what they asked for. perhaps useful for distribution
22:48.01CIA-61BRL-CAD: debugging.
22:52.34CIA-61BRL-CAD: 03brlcad * r47641 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: mark BRLCAD_LIBS as advanced
23:16.09CIA-61BRL-CAD: 03brlcad * r47642 10/brlcad/trunk/src/other/ (re2c/CMake/FindLEMON.cmake step/CMake/FindLEMON.cmake): sync top-level cmake file
23:46.32CIA-61BRL-CAD: 03starseeker * r47643 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: LIBRARY->EXECUTABLE
IRC log for #brlcad on 20111124

IRC log for #brlcad on 20111124

00:15.42CIA-61BRL-CAD: 03starseeker * r47644 10/brlcad/trunk/misc/CMake/CheckCFileRuns.cmake: Tweak CheckCFileRuns.cmake
00:20.28CIA-61BRL-CAD: 03starseeker * r47645 10/brlcad/trunk/misc/CMake/distcheck_buildsys.cmake.in: Add header and footer to core distcheck file checking logic
00:24.51CIA-61BRL-CAD: 03starseeker * r47646 10/brlcad/trunk/misc/CMake/ResolveCompilerPaths.cmake: Not our file - revert copyright statement
00:26.13CIA-61BRL-CAD: 03starseeker * r47647 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake util_macros.cmake): Not only is it not ours, it doesn't apper to be used anywhere. Just clear it until there's a clear need.
02:08.43CIA-61BRL-CAD: 03starseeker * r47648 10/brlcad/trunk/ (5 files in 4 dirs): (log message trimmed)
02:08.43CIA-61BRL-CAD: Get the build working again. Interestingly, the new approach to defines appears
02:08.43CIA-61BRL-CAD: to actually have beneficial DRY consequences even beyond MSVC - the display
02:08.43CIA-61BRL-CAD: manager definitions needed for libdm had been required in libtclcad and mged as
02:08.43CIA-61BRL-CAD: well, but now they automatically inherit libdm's settings. Which means we can't
02:08.43CIA-61BRL-CAD: cheat by defining something for a library and then defining that same flag
02:08.44CIA-61BRL-CAD: differently when compiling an app that uses that library, but on the whole an
02:38.05CIA-61BRL-CAD: 03starseeker * r47649 10/brlcad/trunk/ (5 files in 5 dirs): Do a little more reworking of local defines - also make the ADD_DEFS routines more robust/cleaner.
02:49.53CIA-61BRL-CAD: 03starseeker * r47650 10/brlcad/trunk/ (3 files in 3 dirs): rename, add a utility macro for easer testing/assignment of defines without lists...
02:49.57starseekernifty
03:43.35CIA-61BRL-CAD: 03louipc * r47651 10/brlcad/trunk/misc/archlinux/PKGBUILD:
03:43.35CIA-61BRL-CAD: Update PKGBUILD...
03:43.35CIA-61BRL-CAD: Uses package function
03:43.35CIA-61BRL-CAD: Update dependencies
03:43.35CIA-61BRL-CAD: Use cmake for configuration.
03:43.36CIA-61BRL-CAD: Trim comments.
04:30.49louipcsourceforge doesn't allow svn access via ssh?
05:00.57CIA-61BRL-CAD: 03starseeker * r47652 10/brlcad/trunk/src/libged/simulate/simrt.c: Hmm - gentoo build didn't like TRUE and FALSE...
05:57.01*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
08:00.28*** join/#brlcad merzo (~merzo@193.254.217.44)
12:52.24*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
13:03.25*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
13:13.29``Eriklouipc: they do, but you need to upload your keys via their web interface and wait for propogation
13:13.51*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
13:26.12*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
13:47.10*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
14:24.22*** join/#brlcad merzo (~merzo@193.254.217.44)
19:32.52*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
19:35.04*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
20:48.17*** join/#brlcad yukonbob (~bch@70.97.16.199)
20:48.21yukonbobhello, #brlcad
22:46.28*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
23:17.39*** join/#brlcad piksi (piksi@pi-xi.net)
23:17.39*** join/#brlcad CIA-61 (~CIA@cia.atheme.org)
23:17.39*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
23:17.39*** join/#brlcad ChanServ (ChanServ@services.)
23:17.39*** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
23:17.39*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
23:17.39*** join/#brlcad bhinesley (~bhinesley@99.52.241.103)
23:17.39*** join/#brlcad DarkCalf (DC@173.231.40.98)
23:17.39*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
23:17.39*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
23:17.39*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
23:17.40*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
23:17.40*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
23:17.40*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
23:17.40*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
23:17.40*** join/#brlcad louipc (~louipc@archlinux/fellow/louipc)
23:17.40*** join/#brlcad yiyus (1242712427@je.je.je)
23:17.40*** mode/#brlcad [+o ChanServ] by kornbluth.freenode.net
23:39.43*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
IRC log for #brlcad on 20111125

IRC log for #brlcad on 20111125

00:40.02louipc``Erik: yeah I did that a ages ago. What's the path to the repo for that?
01:18.29*** join/#brlcad yukonbob (~bch@50.46.245.87)
01:18.32yukonbobhello, #brlcad
01:26.23starseekerhello yukonbob
01:27.38yukonbobhai
01:28.18yukonbobhave you ever heard of (or better, know of) "weird" renderers for brlcad, ie: toon shader, or "8 bit", or other fx like that?
01:38.55yukonbobtracks core dumps.
02:01.56CIA-61BRL-CAD: 03starseeker * r47653 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CMakeFiles.cmake): Move macro out of toplevel CMakeLists.txt file
02:05.13CIA-61BRL-CAD: 03starseeker * r47654 10/brlcad/trunk/CMakeLists.txt: not using the contents of the VARIABLES setting - remove this macro and calls
03:46.10CIA-61BRL-CAD: 03starseeker * r47655 10/brlcad/trunk/misc/CMake/ (BRLCAD_Util.cmake ThirdParty.cmake ThirdParty_TCL.cmake): Make a stab at consolidating TCL_BUNDLE_OPTION and BUNDLE_OPTION, mark the _DEFINES vars as advanced.
06:14.48starseekerhuh - http://polarssl.org/
06:56.33*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
08:24.59*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
08:36.41*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
17:02.25CIA-61BRL-CAD: 03n_reed * r47656 10/brlcad/trunk/src/tclscripts/mged/comb.tcl: Don't save existing color attribute. It overrides comb color set in gui.
20:39.33*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
21:59.36CIA-61BRL-CAD: 03n_reed * r47657 10/brlcad/trunk/src/libbu/parse.c: only treat shader string as stack or envmap if shader name matches exactly
22:15.37CIA-61BRL-CAD: 03n_reed * r47658 10/brlcad/trunk/src/libbu/parse.c: removed is_stack bool from bu_shader_to_tcl_list; was always false, and would cause bad output if true
22:37.10n_reed.
IRC log for #brlcad on 20111126

IRC log for #brlcad on 20111126

00:05.34*** join/#brlcad ibot (~ibot@rikers.org)
00:05.34*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
00:13.09*** join/#brlcad yiyus (1242712427@je.je.je)
00:33.45*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
01:44.58CIA-61BRL-CAD: 03n_reed * r47659 10/brlcad/trunk/src/libbu/parse.c: allow braces around shader parameters, e.g. "plastic {sp .5 di .5}" as well as "plastic sp=.5 di=.5", in bu_shader_to_tcl_list (used by mater)
04:43.17*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:21.44*** join/#brlcad merzo (~merzo@227-73-132-95.pool.ukrtel.net)
15:54.54brlcad..
16:16.04jordisayolbrlcad: After this extensive discourse, I have nothing more to add...
19:35.33*** join/#brlcad yiyus (1242712427@je.je.je)
20:27.35*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
21:22.08*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177872364.dsl.bell.ca)
21:22.27IriX64http://pastebin.com/V1hgkCeZ
21:22.33IriX64just happened
21:22.37IriX64ciao
23:11.06*** join/#brlcad merzo (~merzo@175-9-133-95.pool.ukrtel.net)
IRC log for #brlcad on 20111127

IRC log for #brlcad on 20111127

08:18.53*** join/#brlcad Forth (~Forth@92.242.118.253)
15:16.14n_reedI'm guessing Irix64's problem is the result of an in-source build
22:42.00*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
22:42.01*** join/#brlcad piksi (piksi@pi-xi.net)
22:45.14*** join/#brlcad CIA-59 (~CIA@cia.atheme.org)
23:23.24*** join/#brlcad yukonbob (~bch@50.46.245.87)
23:23.26yukonbobhello, #brlcad
23:34.30DarkCalfhello yukonbob
23:35.34yukonbobhello, DarkCalf
23:39.21DarkCalfhello world!
23:40.33yukonbobputs "hello, world!"
IRC log for #brlcad on 20111128

IRC log for #brlcad on 20111128

00:35.22*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
17:21.44*** join/#brlcad merzo (~merzo@75-37-132-95.pool.ukrtel.net)
17:32.35CIA-59BRL-CAD: 03starseeker * r47660 10/brlcad/trunk/src/other/ (10 files in 3 dirs):
17:32.35CIA-59BRL-CAD: move parser.h to re2c_parser.h - renaming the lemon generated parser.h file
17:32.35CIA-59BRL-CAD: after generation to avoid conflict only works when src dir != build dir. If
17:32.35CIA-59BRL-CAD: doing an in src build, lemon will still stomp parser.h on its way to generating
17:32.35CIA-59BRL-CAD: parser_tokens.h
17:57.20*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
17:57.58*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
18:33.28CIA-59BRL-CAD: 03starseeker * r47661 10/brlcad/trunk/src/libpkg/example/ (client.c server.c):
18:33.28CIA-59BRL-CAD: Start trying to figure out how to properly shuffle a file back and forth between
18:33.28CIA-59BRL-CAD: client and server. Ideally, want to have the server send the file to the
18:33.28CIA-59BRL-CAD: client, have the client reconstitute the file, and then fire the file back at
18:33.29CIA-59BRL-CAD: the server, which reconstitutes it in turn and maybe compares it to the original
18:33.29CIA-59BRL-CAD: buffer. Not immediately clear how to achieve this yet.
18:34.50CIA-59BRL-CAD: 03starseeker * r47662 10/brlcad/trunk/src/other/CMakeLists.txt: Mark as advanced
18:57.42CIA-59BRL-CAD: 03starseeker * r47663 10/brlcad/trunk/misc/CMake/FindGL.cmake: Whoops, broke the GL logic for MSVC - try again...
19:26.56CIA-59BRL-CAD: 03n_reed * r47664 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.c scanner.re template.c): addressing some compiler warnings
20:23.40CIA-59BRL-CAD: 03n_reed * r47665 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re template.c): fix scanning from string
20:32.55CIA-59BRL-CAD: 03starseeker * r47666 10/brlcad/trunk/src/librt/CMakeLists.txt: Try tweaking the DLL variables for librt - working on unbreaking Windows...
21:12.51CIA-59BRL-CAD: 03starseeker * r47667 10/brlcad/trunk/src/CMakeLists.txt: Add the __WIN32__ definition - may need it for some headers.
21:20.28CIA-59BRL-CAD: 03n_reed * r47668 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.c): allow empty code section
22:03.06CIA-59BRL-CAD: 03n_reed * r47669 10/brlcad/trunk/src/other/perplex/ (perplex.c scanner_template.c template.c): renamed scanner template
22:12.36brlcadstarseeker: __WIN32__ is a compiler define, provided by the compiler
22:13.43brlcaddefining any __* variable invariably can lead to problems down the road, they are reserved for compiler-use
22:14.26brlcadtechnically all _* preprocessor symbols, but most compilers aren't that strict
23:32.06CIA-59BRL-CAD: 03starseeker * r47670 10/brlcad/trunk/src/CMakeLists.txt: remove __WIN32__ - compiler define, and in any case it didn't have the desired result.
23:45.28CIA-59BRL-CAD: 03starseeker * r47671 10/brlcad/trunk/src/libdm/CMakeLists.txt: dm-tk still has issues on Windows.
23:46.27*** join/#brlcad merzo (~merzo@29-12-132-95.pool.ukrtel.net)
23:49.46brlcadlooks like astyle 2.03 is going to include my patch for our format, will have to give it a try
23:55.51starseekerwoo hoo!
IRC log for #brlcad on 20111129

IRC log for #brlcad on 20111129

00:02.27starseekerif it works, should we add it to allow a tweaked indent.sh to work "out of the box", as it were?
00:07.13brlcadyou mean add astyle to our repo?  nah
00:09.36brlcadit's enough to point an offender at the download with instructions that they need to install/run it
00:10.21brlcadit's a thought, but still not necessary until a complete style is defined
00:10.56starseekeralrightie
00:11.02brlcadwhich would still take at least a day I think to get right, test, verify
00:11.43brlcadnext step is for someone(tm) to work on a matching style definition
00:12.00brlcadthat would have been a good GCI task :)
00:12.51starseekerheh - next year :-)
00:13.04brlcadmaybe :)
00:13.35brlcadit's still a highly dubious program from an efficiency perspective -- most I talked to said it's a wash at best
00:13.56starseekerhmm.  Maybe just as well then
00:14.01brlcadI was interested more from a community building/awareness perspective, get 'em aware young
00:17.06starseekersees the core chromium browser is BSD licensed... cool. Might have to try that. Been avoiding Chrome itself.
00:18.18starseekerOo - lots of design docs
00:18.41starseekeryow - multi *process* architecture?
00:19.00starseekerbacks away slowly...
00:22.11brlcadyou do realize why it's designed that way though, right?
00:22.23brlcadflash crashing doesn't bring down your browser
00:22.27starseekersure - so the browser is robust when individual pages fail
00:22.35starseekerer, yeah :-)
00:22.59starseekernot very useful for our own problem domain though
00:22.59brlcadif a plugin fails, no impact other than maybe a page load failing
00:23.15brlcadif we had lots of unreliable plugins, perhaps
00:53.55CIA-59BRL-CAD: 03starseeker * r47672 10/brlcad/trunk/src/librt/CMakeLists.txt: Because librt is using so many different DLL_IMPORTS/EXPORTS flags, we're going to have to handle a few things manually. Any reason not to roll TIE_DLL and DB5_DLL into RT_DLL?
01:01.45brlcadno reason comes to mind, wondered why they were separate to begin with
01:05.41CIA-59BRL-CAD: 03starseeker * r47673 10/brlcad/trunk/ (include/db5.h include/tie.h src/librt/CMakeLists.txt): DB5 and TIE export prefixes switched to RT
02:09.46*** join/#brlcad louipc (~louipc@archlinux/fellow/louipc)
02:15.08CIA-59BRL-CAD: 03starseeker * r47674 10/brlcad/trunk/src/ (8 files in 7 dirs): Make a stab at dealing with more MSVC build issues with new setup. Not tested yet.
02:59.06*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
03:11.55starseekerhuh, cool - wonder if features could be snarfed from this for astyle:  http://gcgreatcode.cvs.sourceforge.net/viewvc/gcgreatcode/GC/GC.txt?revision=1.4&view=markup
03:22.42starseekerBRL-CAD builds on Windows once more
03:22.51starseekeris outta here
03:22.57louipcbye
03:27.17louipcAnyone know the address/url to checkout/commit via svn+ssh? or is brlcad not set up for that?
05:35.56*** join/#brlcad IriX64 (~kvirc@bas2-sudbury98-1177872364.dsl.bell.ca)
05:36.07IriX64http://pastebin.com/6qAwbny1
05:36.16IriX64just checked out and happened
05:36.22IriX64ciao
06:19.11*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:28.37brlcad~cadsvn
13:28.37ibotTo obtain BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad
13:32.32brlcadlouipc: it should work, though I admittedly haven't used that method in a very long time
13:33.24brlcadI believe svn+ssh requires uploading your ssh key ( https://sourceforge.net/apps/trac/sourceforge/wiki/SSH%20keys ) or it will prompt for password multiple times for a single checkout
13:41.21brlcadlouipc: I take it back, looks like they changed it to be https-only some time ago (about a year ago) though they keys will still work and get used
13:45.53brlcadlouipc: ahh, and their new beta website interface will support it in the upcoming months: https://sourceforge.net/p/forge/documentation/svn%20-%20Beta/
13:46.57brlcadbrl-cad has not yet migrated to the beta interface
14:00.48``ErikTIE_DLL being seperate is legacy from when libtie linked librt
14:27.47CIA-59BRL-CAD: 03d_rossberg * r47675 10/brlcad/trunk/src/ (librt/CMakeLists.txt libwdb/CMakeLists.txt): the brlcad.dll needs an openNURBS.dll: setting the compiler switches
14:31.33CIA-59BRL-CAD: 03d_rossberg * r47676 10/rt^3/trunk/src/coreInterface/ConstDatabase.cpp: the result of a test for NULL should be honored
14:36.56starseekerhmm... IriX64's error raises the question of how hard we should look for jni.h... at least on my system, no special effort is required
14:37.36starseekernot sure if that should be regarded as a system configuration issue...
14:39.21starseekeroh, right, I've got that config thing working
14:39.24starseekerhmm...
14:47.22starseekermight have to treat it as a config issue, or there are other issues
14:47.42starseekermy system has both java itself and gcc supplying jni.h headers
14:48.42starseeker(incompatible ones, I might add)
14:50.53starseekershakes head - need help for this one, don't know enough about Java/JNI
15:07.07``Erikat the moment, the only jni using stuff is incredibly muves specific, so I'd say "not at all" for the time being... :D make 'em set the variable
15:46.39CIA-59BRL-CAD: 03brlcad * r47677 10/brlcad/trunk/src/rt/viewedge.c: carl reported a typo
15:54.25CIA-59BRL-CAD: 03brlcad * r47678 10/brlcad/trunk/src/tclscripts/rtwizard/examples/ (5 files in 5 dirs): various additional corrections from carl for rtwizard.
16:18.00CIA-59BRL-CAD: 03brlcad * r47679 10/brlcad/trunk/src/adrt/isst_tcltk.c: TIE_EXPORT is dead
16:42.40CIA-59BRL-CAD: 03bob1961 * r47680 10/brlcad/trunk/src/rt/do.c: Remove call to do_ae() from within cm_ae(). This causes a segmentation fault. Besides, do_ae() gets called later in main.c if necessary.
17:22.06CIA-59BRL-CAD: 03n_reed * r47681 10/brlcad/trunk/src/other/perplex/ (9 files): borrowing re2c's option parser
17:22.28CIA-59BRL-CAD: 03starseeker * r47682 10/brlcad/trunk/CMakeLists.txt: Do a little more to disable librtserver - may have to eventually do an actual compile test on this, but hopefully this will avoid some issues.
17:50.14CIA-59BRL-CAD: 03bob1961 * r47683 10/brlcad/trunk/ (4 files in 4 dirs): Added a data_polygons subcommand for saving a polygon as a sketch. Also added one for importing polygon data from a sketch.
18:07.07CIA-59BRL-CAD: 03starseeker * r47684 10/brlcad/trunk/src/other/libutahrle/CMakeLists.txt: Hmm, must have had a stale libutahrle lib file around. Tweak MSVC build flags.
18:11.56CIA-59BRL-CAD: 03n_reed * r47685 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner_template.c): added option for specifying output file
19:07.16*** join/#brlcad merzo (~merzo@29-12-132-95.pool.ukrtel.net)
19:09.21*** join/#brlcad Forth (~Forth@92.242.118.253)
19:11.58*** part/#brlcad Forth (~Forth@92.242.118.253)
19:12.50CIA-59BRL-CAD: 03bob1961 * r47686 10/brlcad/trunk/src/rt/do.c: Revert the previous commit.
19:22.12CIA-59BRL-CAD: 03bob1961 * r47687 10/brlcad/trunk/src/rt/do.c: Check rtip for NULL before trying to use withing do_ae().
19:33.44CIA-59BRL-CAD: 03erikgreenwald * r47688 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: remove uninitialized (and basically unused) ret variable
19:34.34CIA-59BRL-CAD: 03starseeker * r47689 10/brlcad/trunk/ (3 files in 3 dirs): Clean up the OSX framework detection
19:43.38CIA-59BRL-CAD: 03erikgreenwald * r47690 10/brlcad/trunk/src/librt/CMakeLists.txt: Set OBJ_BREP on all statics, not just windows
19:59.17CIA-59BRL-CAD: 03starseeker * r47691 10/brlcad/trunk/src/libdm/CMakeLists.txt: the libdm static build does need some defines - add those.
20:04.14CIA-59BRL-CAD: 03starseeker * r47692 10/brlcad/trunk/src/librt/CMakeLists.txt: just BUILD_STATIC_LIBS
20:05.34CIA-59BRL-CAD: 03n_reed * r47693 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner.re scanner_template.c): add ability to generate a header file
20:17.05CIA-59BRL-CAD: 03erikgreenwald * r47694 10/brlcad/trunk/src/libged/CMakeLists.txt: Move FB includes to end to try to shuffle macports include dir out...
20:32.12starseeker``Erik: brlcad said defining that broke some other platform
20:32.27starseekerapparently defining that can have Bad Side-effects...
20:35.48``Erikhm, thought I had it safely wrapped *shrug*
21:05.24CIA-59BRL-CAD: 03bob1961 * r47695 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: ae2dir doesn't take a view parameter
21:08.27brlcad``Erik: you did have it wrapped, and it still caused a problem because it was a compiler variable
21:09.33brlcadthat's why the _* vars aren't supposed to be used, compiler is allowed to claim imminent domain on them and screw up caller code in seeminly unreasonable ways
21:11.31brlcadif I remember the problem correctly, it would fail the build even if you #undef _VAR ; #define _VAR 1 ; it would abort saying you're screwing with an already defined _VAR and no #ifdef logic could get around it
21:12.42``Erikhm *shrug* if fails on my laptop, too (very up to date), but turning off strict allows it to pass
21:12.49brlcadso need some other fix (like always putting X11 includes last)
21:14.31brlcadso great, you have a repeatable platform environment where you can find another solution :P
21:14.35CIA-59BRL-CAD: 03starseeker * r47696 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Just remove duplicates regardless
21:14.55starseekervotes for smacking the zlib developers with a wet trout
21:16.40``Erikalso have slews of warnings from variatic macros in an X header, :D all good fun here
21:17.50brlcadI just got those for the first time today from an autotools build, FD_SET() and FD_ISSET()
21:18.21brlcadat least seemingly related
21:18.45brlcaderror: ISO C forbids braced-groups within expressions
21:28.32CIA-59BRL-CAD: 03n_reed * r47697 10/brlcad/trunk/src/other/perplex/ (parser.y scanner.re scanner_template.c): address compiler warnings
21:35.12brlcadstarseeker: false alarm on the strict failure discrepancy, it wasn't compiling optimized which triggers the failure
21:50.18CIA-59BRL-CAD: 03bob1961 * r47698 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: When using "put" to create an extrude primitive it's possible to get a segmentation fault if the sketch name is not specified. This updates rt_extrude_adjust() to check if sketch_name is NULL.
21:53.44CIA-59BRL-CAD: 03erikgreenwald * r47699 10/brlcad/trunk/misc/CMake/Fink_MacPorts.cmake: add include dirs to remove command
21:58.41starseekerphew :-)
21:59.26starseekerlooks like we can work around the zlib thing by disabling macports
22:23.16CIA-59BRL-CAD: 03brlcad * r47700 10/brlcad/trunk/src/libged/polyclip.cpp: curr_lsg won't be initialized if the list is empty. make sure we don't dereference.
22:28.54CIA-59BRL-CAD: 03brlcad * r47701 10/brlcad/trunk/include/ (CMakeLists.txt Makefile.am bselect.h):
22:28.56CIA-59BRL-CAD: add a new header for wrapping the logic and functionality necessary for
22:28.56CIA-59BRL-CAD: protecting against a bug in gcc 4.6.2 where the FD_*() macros aren't marked as
22:28.56CIA-59BRL-CAD: extensions causing gcc to emit a warning during -O3 compilation about ISO C
22:28.56CIA-59BRL-CAD: forbidding braced-groups within expressions. this may need some more
22:28.56CIA-59BRL-CAD: precautions to ensure we only perform this workaround when absolutely necessary,
22:28.57CIA-59BRL-CAD: but it seems to work well for the platform (linux) exhibiting the error.
22:32.59CIA-59BRL-CAD: 03brlcad * r47702 10/brlcad/trunk/src/ (7 files in 5 dirs):
22:32.59CIA-59BRL-CAD: replace includes of sys/select with the new bselect.h header so we can avoid a
22:33.00CIA-59BRL-CAD: gcc 4.6.2 'ISO C forbids braced-groups within expressions' -O3 -pedantic error.
22:33.00CIA-59BRL-CAD: looks like the '-Werror=edantic' problem is already reported.
22:36.28CIA-59BRL-CAD: 03brlcad * r47703 10/brlcad/trunk/src/conv/enf-g.c: initialize variables before use. atof may fail.
22:42.40CIA-59BRL-CAD: 03brlcad * r47704 10/brlcad/trunk/src/ (6 files in 3 dirs): few more select() caller stragglers that didn't include sys/select.h directly. include bselect.h ftw.
23:08.31CIA-59BRL-CAD: 03brlcad * r47705 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c:
23:08.31CIA-59BRL-CAD: reworking more variables since compilation is halting on bugs that gcc 4.6.2
23:08.31CIA-59BRL-CAD: detected where we're calling V3ARGS on point2d_t variables being passed around.
23:08.31CIA-59BRL-CAD: make isect_line2_ellipse() take 2d entities and promote the rest to 3d for now.
IRC log for #brlcad on 20111130

IRC log for #brlcad on 20111130

00:44.22louipcbrlcad: ok thanks for the info
00:53.35CIA-59BRL-CAD: 03starseeker * r47706 10/brlcad/trunk/CMakeLists.txt: with any luck, we don't need to separately call out tcl and tk build deps...
03:03.03*** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net)
03:05.25pacman87brlcad: ping/pm?
03:44.19*** join/#brlcad Forth (~Forth@92.242.118.253)
03:45.01*** part/#brlcad Forth (~Forth@92.242.118.253)
03:45.22brlcadpacman87: hm? sure? what?
03:48.53*** part/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net)
03:49.11*** join/#brlcad pacman87 (~Timothy@adsl-208-191-158-89.dsl.hstntx.swbell.net)
03:50.13pacman87brlcad: pm'd
04:02.31pacman87has there been any progress on the revolve primitive lately?
04:03.45brlcadyeah, it was included in an exhaustive performance profile a couple weeks ago
04:03.58brlcadalong with all of the other primitives, it was part of a NURBS performance analysis
04:04.19brlcadit didn't fare so well and unfortunately crashed for some of the test cases
04:04.50brlcadso there are some new to-do entries to investigate and fix
04:10.59pacman87I might be able to take another look at it mid-january, once all the dust settles from graduation/christmas/moving
04:30.25brlcadawesome
06:01.27*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
07:00.23*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
07:01.57*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:25.25*** join/#brlcad merzo (~merzo@193.254.217.44)
15:24.08CIA-59BRL-CAD: 03erikgreenwald * r47707 10/brlcad/trunk/src/libgcv/bottess.c: disable function level static declarations. fix debugging output parameters.
15:49.51*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
16:01.41CIA-59BRL-CAD: 03n_reed * r47708 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.h scanner.re): added support for braces and strings inside actions
16:36.07CIA-59BRL-CAD: 03n_reed * r47709 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re): added support for single quote strings and comments inside actions
18:49.29*** join/#brlcad Forth (~Forth@92.242.118.253)
18:58.36CIA-59BRL-CAD: 03starseeker * r47710 10/brlcad/trunk/src/other/CMakeLists.txt: If we're not able to build SCL, set the build var to off so it gets reported that way...
19:11.26CIA-59BRL-CAD: 03starseeker * r47711 10/brlcad/trunk/src/other/CMakeLists.txt: Mark BUILD_SCL as advanced
19:31.23CIA-59BRL-CAD: 03starseeker * r47712 10/brlcad/trunk/src/other/CMakeLists.txt: Ah, right - was setting the wrong thing for the toplevel mechanism. This is tested and works on Win32
19:51.27*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
21:05.21CIA-59BRL-CAD: 03bob1961 * r47713 10/brlcad/trunk/ (3 files in 3 dirs): Provide a way to select the target polygon.
21:10.52*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
21:11.09brlcadnetworking woes at the isp apparently
21:13.06*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
21:16.22CIA-59BRL-CAD: 03brlcad * r47714 10/brlcad/trunk/src/ (conv/iges/iges.c lgt/do_options.c proc-db/csgbrep.cpp): more strict quellage.
22:28.56brlcadif I had been using cmake instead of ccmake for specifying options, I would have expected tom browder's example to work
22:29.03brlcaddid he typo one of the names?
22:31.57CIA-59BRL-CAD: 03n_reed * r47715 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.h scanner.re): added basic support for start condition scopes
23:12.54*** join/#brlcad pacman87 (~Timothy@208-191-158-89.lightspeed.austtx.sbcglobal.net)
23:26.58*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
23:29.42CIA-59BRL-CAD: 03starseeker * r47716 10/brlcad/trunk/ (15 files in 15 dirs): Add a scheme for sorting include directories for BRL-CAD libraries, with an eye towards favoring local includes over system directories. Not tested in any of the problem cases as yet.
IRC log for #brlcad on 20111201

IRC log for #brlcad on 20111201

00:44.05*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
02:46.43CIA-59BRL-CAD: 03starseeker * r47717 10/brlcad/trunk/misc/CMake/DiffCache.cmake: The new _DEFINES showed some holes in the cache diffing routine. This should be more robust and cleaner.
02:52.20CIA-59BRL-CAD: 03starseeker * r47718 10/brlcad/trunk/src/libged/CMakeLists.txt: Put FB back in alphabetical order - hopefully the sorting logic will handle the situation, if not the 'correct' approach will have to be to disable macports.
02:54.26*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
02:55.30starseekerwonders what on earth he did to irssi...
02:55.46starseekerhope I didn't miss anything...
03:00.46starseekerpulls up archives...
03:01.02starseekerbrlcad: he's using the old CMake variable setup
03:01.26starseeker(tom browder)
03:02.00starseekeremailed the correct settings for 7.20.4, which is new enough to be using the newer multi-variable options
03:55.08*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
04:09.40*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
04:19.07*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
06:14.52*** join/#brlcad DarkCalf (DC@173.231.40.98)
10:13.49*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
11:10.24*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
11:29.39*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
13:52.07brlcadstarseeker: you didn't do anything to irssi, it just got disconnected due to some isp routing issue
13:52.22brlcad(.bz was briefly disconnected yesterday)
14:00.35CIA-59BRL-CAD: 03erikgreenwald * r47719 10/brlcad/trunk/src/libgcv/ (CMakeLists.txt Makefile.am test_bottess.c): stub in unit testing for bottess
14:01.11``Erikstarseeker: run irssi inside of screen(1) (irssi lacks bx style nohup miniscreen)
14:13.11CIA-59BRL-CAD: 03brlcad * r47720 10/brlcad/trunk/src/libgcv/test_bottess.c: fix header file name and copyright year (starts with file)
14:16.37CIA-59BRL-CAD: 03brlcad * r47721 10/brlcad/trunk/NEWS: bob fixed a bug in rt where it'd crash if the ae command was called during -c (before rtip was initialized). fixed by delaying the do_ae() processing until after all args are processed.
14:43.34CIA-59BRL-CAD: 03brlcad * r47722 10/brlcad/trunk/AUTHORS:
14:43.34CIA-59BRL-CAD: developers already have the prestige badge and will invariably/usually have all
14:43.34CIA-59BRL-CAD: contributed to docs in some fashion by the time they get that designation (100+
14:43.34CIA-59BRL-CAD: features), so avoid double-listing any dev. also, expand docs to include the
14:43.34CIA-59BRL-CAD: website so we can credit robert leverginton for his work redesigning the main
14:43.35CIA-59BRL-CAD: site back in 2007. responded to my sf posting in june 2007, unveiled new
14:43.36CIA-59BRL-CAD: unified theme drupal+mediawiki+gallery2 site in march 2008.
15:01.16CIA-59BRL-CAD: 03brlcad * r47723 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: prevent a pipe tesselation double-free, detected by the conversion script and verbose blather on linux
15:09.00starseeker``Erik: do run it inside of screen - got into a funky state regardless
15:09.08starseekerprobably hit some weird key combo
15:13.51``Erikah, fun
15:16.26CIA-59BRL-CAD: 03brlcad * r47724 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: cleanup
15:53.30CIA-59BRL-CAD: 03brlcad * r47726 10/brlcad/trunk/NEWS: nick fixed a bug affecting the combination editor where it wasn't preserving the color value set. tcl script was preserving the original color, so needed to not do that.
15:56.59CIA-59BRL-CAD: 03n_reed * r47727 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner_template.c): add option for toggling definition of condition routines
16:21.59brlcadstarseeker: that "funky state" was simply "disconnected from freenode"
16:22.31brlcadif you looked at irssi window 1, you probably would have seen all the notices saying you weren't connected any more
16:23.34brlcadneeded to run /connect or /server
16:26.47CIA-59BRL-CAD: 03brlcad * r47725 10/brlcad/trunk/src/libbu/ (parse.c tcl.c): ws
16:35.00CIA-59BRL-CAD: 03n_reed * r47728 10/brlcad/trunk/src/other/perplex/ (parser.y scanner.re scanner_template.c): minor changes to macro names
16:45.33CIA-59BRL-CAD: 03tbrowder2 * r47729 10/brlcad/trunk/include/brlcad.h: correct typo
17:36.38CIA-59BRL-CAD: 03bob1961 * r47730 10/brlcad/trunk/ (3 files in 3 dirs): Added color, line width and line style at the polygon level.
18:17.36*** join/#brlcad Johnnie (~Johns@host161-101-dynamic.2-79-r.retail.telecomitalia.it)
18:17.38Johnniehi all
18:19.51JohnnieI need to render an IGES/STEP that contains solid geometry with OpenGL. Can BRL-CAD output a tringulated mesh from a solid?
18:24.25starseekernot currently
18:24.38starseekerat least, not for the NURBS geometry that usually makes up a STEP file
18:25.24Johnniethere's other library that permit this?
18:25.33starseekerif you strictly want to visualize a NURBS surface with OpenGL, you might see if OpenSG's support for NURBS can do what you need...
18:25.52Johnniemy problem is that I need to do an IGES/STEP viewer
18:25.55Johnniein opengl
18:26.27Johnniebut I can't find a valid IGES/STEP triangulator
18:27.15starseekerhttp://cg.cs.uni-bonn.de/en/publications/paper-details/kahlesz-2002-nurbs/
18:27.24starseekerthe trick would be to get STEP nurbs into OpenSG
18:28.10starseekeryou might try hooking up opensg and https://github.com/mpictor/StepClassLibrary
18:30.34JohnnieI see.
18:31.05starseekerBRL-CAD is planning to support what you're describing, but we aren't there yet
18:31.35Johnnieso actually BRL-CAD can render IGES via ray-tracing?
18:31.44Johnnie(only)
18:32.47JohnnieI wonder if exists some triangulation library that can already do it
18:32.56Johnnielike GTS
18:33.11starseekerthat's why I suggested opensg - they seem to have some triangulation code
18:33.57starseekermy todo list includes isolating the tesselation code in opensg and seeing whether it can be adapted for use with BRL-CAD
18:35.03Johnniemany library use OpenCascade to achieve this
18:35.27Johnniebut it's an huge library
18:35.28starseekernods. Unfortunately, opencascade isn't license compatible with BRL-CAD
18:35.34Johnnieyep
18:36.08starseekerJohnnie: what are your requirements?  (licensing wise)
18:36.42JohnnieI need to create a commercial IGES/STEP viewer only (no modeling).
18:37.10starseekercommercial... not open source then?
18:37.33JohnnieI'm trying to figure out if some LGPL library exists.
18:37.57starseekerah - opensg is LGPL, last time I looked.
18:38.09Johnniebut can OpenSG import IGES/STEP?
18:38.26starseekernot as far as I know
18:38.45Johnniethere's perhaps commercial library?
18:39.06starseekerI'm sure there are, but I don't know much about those
18:39.14JohnnieAvoid that one that are too expensive (like ACIS, Parasolid)
18:39.49JohnnieLooklike that for AutoCAD file format there's by far more support
18:39.56Johnnie(DWG/DXF)
18:40.04Johnniethan IGES/STEP
18:40.52starseekerour focus here is open source only - commercial CAD is only of interest when it comes to supporting data read/write
18:42.19JohnnieI see. I hope to find some other channel here (on irc.freenode.net) that can give me some other hints. Thanks.
18:47.16starseekergrr
18:47.19starseekerpipe.c:2932: warning: assignment from incompatible pointer type
18:47.41Johnnie(openNURBS toolkit look like interesting)
18:55.24CIA-59BRL-CAD: 03erikgreenwald * r47731 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: split assignments to avoid incompatible pointer error
19:15.00starseekerJohnnie: we use opennurbs, but they don't include tessellation routines
19:15.00*** part/#brlcad Johnnie (~Johns@host161-101-dynamic.2-79-r.retail.telecomitalia.it)
19:41.43CIA-59BRL-CAD: 03starseeker * r47732 10/brlcad/trunk/src/fb/CMakeLists.txt: Ah, right - even though it's not a library, we need to sort includes for at least some of the binaries. Do so for the fb directory.
20:11.35``Erikstarseeker: hehehe "On the other hand, my strategy is not top down, it is bottoms up." http://www.foxnews.com/on-air/hannity/transcript/herman-cain-solving-americas-problems-not-rocket-science
20:11.49``Erik(and yes, it did fail on the same _LARGEFILE64_SOURCE issue)
20:12.32starseekernods
20:12.44starseekerat least turning everything on succeeds
20:13.02``Erikas does disabling strict
20:13.34starseekeror (IIRC) disabling macports includes
20:15.01brlcadstarseeker: fyi, our iges importer will result in a bspline that can be triangulated -- would have been worth trying
20:15.17starseekeroh, really?
20:15.23starseekerdidn't know that
20:15.26starseekercool
20:15.42brlcadi've mentioned that the old nurbs code had tessellation already implemented
20:16.02brlcadit's not adaptive, super slow, but it works
20:16.13starseekerah - didn't realize it was operational
20:16.36brlcadsimple walk over the uv space, chop them up into polys
20:16.57starseekerdoes it "stitch" together for a solid?
20:17.12brlcaddon't know
20:17.23brlcadat least, don't remember
20:17.30brlcadexercise left to the reader
20:17.34starseekerheh
20:18.00brlcadfor his described purpose, it would have been sufficient
20:18.23starseekerwill mention it if he comes back
20:18.48starseekerrather doubts it would be robust/fast enough, but agrees it would have been worth a shot
20:38.53*** join/#brlcad merzo (~merzo@94-41-132-95.pool.ukrtel.net)
20:47.34starseekeranybody else getting a regression failure on the solids test?
20:49.33starseekerlooks as if the light is "brighter"
20:53.15``Erikonly on certain primitives, though
20:54.01CIA-59BRL-CAD: 03brlcad * r47733 10/brlcad/trunk/ (include/bu.h src/libbu/tcl.c):
20:54.02CIA-59BRL-CAD: remove declaration of bu_tcl*() functions that are not used outside of
20:54.02CIA-59BRL-CAD: src/libbu/tcl.c, part of gradual elimination of tcl from libbu. looks like two
20:54.02CIA-59BRL-CAD: are directly used (bu_tcl_structparse_argv() by edsol.c and bu_tcl_setup() by
20:54.02CIA-59BRL-CAD: ssampview) and four others indirectly used through tclscripts.
20:55.41CIA-59BRL-CAD: 03n_reed * r47734 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re): improved parsing of patterns
20:57.39``Eriklinux and fbsd show 25006 off by many for solids, mac shows 25009
21:45.57CIA-59BRL-CAD: 03starseeker * r47735 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Tweak the BRLCAD_OPTION macro - try for supporting DISABLE_ forms of ENABLE_ vars
21:46.08starseekergreat...
21:47.12CIA-59BRL-CAD: 03n_reed * r47736 10/brlcad/trunk/src/other/perplex/ (parser.y scanner_template.c): adding required re2c configuration options for condition support to output
21:59.02CIA-59BRL-CAD: 03brlcad * r47737 10/brlcad/trunk/src/libbu/tcl.c: mark the bu_cmdtab functions as HIDDEN as they don't need to be public API. change their function prefix from bu_tcl_ to tcl_bu_ so they merely prefix the bu function name they wrap.
22:03.48CIA-59BRL-CAD: 03brlcad * r47738 10/brlcad/trunk/doc/deprecation.txt: all of the bu_tcl_* functions are no longer public API.
22:06.52CIA-59BRL-CAD: 03brlcad * r47739 10/brlcad/trunk/doc/deprecation.txt: oops, fix the regex to use both matched patterns.
22:09.45CIA-59BRL-CAD: 03starseeker * r47740 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Add a second 'BRLCAD_OPTION' to test the setup. Need to think about how to handle this for third party cases - may need an option to go with either BRLCAD_OPTION or just a regular option.
22:12.48CIA-59BRL-CAD: 03starseeker * r47741 10/brlcad/trunk/CMakeLists.txt: Nevermind the BRLCAD_ prefix on the aliases - if we need that it can be automated at the macro level
22:26.05*** join/#brlcad Johnnie (~Johns@host161-101-dynamic.2-79-r.retail.telecomitalia.it)
22:28.51``Erikhttp://www.codeschool.com/courses/rails-for-zombies    vrry cool approach, mebbe brlcad should make some BRL-CAD ones of those :> *duck*
23:14.27CIA-59BRL-CAD: 03brlcad * r47742 10/brlcad/trunk/src/libbu/tcl.c:
23:14.27CIA-59BRL-CAD: eliminate 7 seemingly minimal-value bu tcl commands that also seem to be
23:14.27CIA-59BRL-CAD: completely unused within our code: bu_ck_malloc_ptr, bu_malloc_len_roundup,
23:14.27CIA-59BRL-CAD: bu_printb, bu_key_eq_to_key_val, bu_shader_to_tcl_list, bu_key_val_to_key_eq,
23:14.27CIA-59BRL-CAD: bu_shader_to_key_eq. 200 line reduction.
23:17.33brlcadstarseeker: haven't seen the regression failure, but it should be investigated
23:17.56brlcadpossible the ambient occlusion patch changed some lighting default and might need to be conditionalized
23:18.16brlcadyou could unroll that commit and see if it still fails
23:22.15CIA-59BRL-CAD: 03brlcad * r47743 10/brlcad/trunk/src/libbu/parse.c: the _bu_ prefix convention on static functions was a bad idea. use a prefix based on the group/file these functions belong to, i.e., parse_
23:28.40CIA-59BRL-CAD: 03brlcad * r47744 10/brlcad/trunk/src/rttherm/ssampview.tcl: replace bu_get_all_keyword_values with calls to bu_get_value_by_keyword. this was the only use with ill-defined side effects, so reduce.
23:31.32CIA-59BRL-CAD: 03brlcad * r47745 10/brlcad/trunk/src/libbu/tcl.c: removed the only call to bu_get_all_keyword_values from tcl code so its binding can go away. another 100 lines.
23:34.49CIA-59BRL-CAD: 03brlcad * r47746 10/brlcad/trunk/src/rttherm/ssampview.c: replace the call to bu_tcl_setup() and rt_tcl_setup() with the same initialization call used by bwish and mged, calling Bu_Init() and Rt_Init() respectively. allows bu_tcl_setup() to go away.
23:38.29CIA-59BRL-CAD: 03brlcad * r47747 10/brlcad/trunk/ (doc/deprecation.txt include/bu.h src/libbu/tcl.c): remove bu_tcl_setup() in favor of equivalent Bu_Init()
23:48.30``Erikstarseeker: http://projects.goldelico.com/p/gta04-main/
IRC log for #brlcad on 20111202

IRC log for #brlcad on 20111202

00:00.25CIA-59BRL-CAD: 03brlcad * r47748 10/brlcad/trunk/ (include/bu.h src/libbu/tcl.c src/mged/edsol.c): do the same with bu_tcl_structparse_argv(). it was only used in one place, so eliminate it by just making the caller code call bu_structparse_argv() directly.
00:06.22starseekerhah - cool!
00:24.27starseekerdoesn't look like it was the ambient occlusion patch
00:30.10starseekerwhadya bet it's compile flag related...
00:30.20starseekerfires up autotools
00:53.23starseekerok, failure is in autotools too...
00:58.55starseeker47656 is OK...
00:59.55starseeker47659 is bad
01:05.21*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
01:21.23CIA-59BRL-CAD: 03starseeker * r47749 10/brlcad/trunk/src/libbu/parse.c: Try to undo r47659 without ruining the subsequent commits... this was breaking the solids shader regression test, so needs more checking into.
01:21.41brlcadah, right -- nick changed how shaders are parsed so tcl syntax works
01:21.47brlcadmater command
01:27.39CIA-59BRL-CAD: 03brlcad * r47750 10/brlcad/trunk/sh/template.sh: don't just delete the header/footer file before aborting. we might have been running adding a header/footer to a file that already existed. instead restore the backup.
01:28.14CIA-59BRL-CAD: 03brlcad * r47751 10/brlcad/trunk/sh/ (footer.sh header.sh): add support for adding header/footers to .cmake files, using sh-mode
01:28.39CIA-59BRL-CAD: 03brlcad * r47752 10/brlcad/trunk/TODO.cmake: added the deprecation warning to the old build system
01:29.38CIA-59BRL-CAD: 03brlcad * r47753 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: a bug? do what the comment says it is supposed to be doing.
01:34.02CIA-59BRL-CAD: 03starseeker * r47754 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Handle setting of default option in BRLCAD_OPTION
01:40.15CIA-59BRL-CAD: 03brlcad * r47755 10/brlcad/trunk/ (9 files in 7 dirs):
01:40.15CIA-59BRL-CAD: removed bu_badmagic_tcl() and all of the tcl-specific badmagic macros like
01:40.15CIA-59BRL-CAD: BU_CKMAG_TCL and the various bn and rt macros that wrapped it (like
01:40.15CIA-59BRL-CAD: RT_CK_AP_TCL, RT_CK_RTI_TCL, BN_CK_VLIST, etc). one step closer to decoupling
01:40.16CIA-59BRL-CAD: libbu from tcl
02:56.29CIA-59BRL-CAD: 03brlcad * r47756 10/brlcad/trunk/src/libbu/observer.c: _bu_ prefix was a bad idea
03:14.29*** join/#brlcad merzo (~merzo@48-62-132-95.pool.ukrtel.net)
03:24.43*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
03:30.42CIA-59BRL-CAD: 03brlcad * r47757 10/brlcad/trunk/src/libbu/cmdhist.c: _bu_ prefix was a bad idea, use the file name as the prefix
03:35.05CIA-59BRL-CAD: 03brlcad * r47758 10/brlcad/trunk/ (include/bu.h src/libbu/tcl.c): change Bu_Init() to take a void* since dynamic loading should still work just fine without knowing the type. helps decouple the header from needing tcl.h
03:42.54CIA-59BRL-CAD: 03brlcad * r47759 10/brlcad/trunk/src/libbu/cmdhist_obj.c: unfortunately not so simple to remove/move the tcl side of the command history implementation from libbu since it involves non-deprecated tclscripts api.
03:56.06CIA-59BRL-CAD: 03brlcad * r47760 10/brlcad/trunk/ (10 files in 3 dirs):
03:56.06CIA-59BRL-CAD: move command history tcl objects from libbu to libtclcad, changing them from
03:56.06CIA-59BRL-CAD: init during loading of libbu to loading of libtclcad. this should keep things
03:56.06CIA-59BRL-CAD: working for archer and get libbu one step closer to tcliberation.
04:16.04CIA-59BRL-CAD: 03brlcad * r47761 10/brlcad/trunk/TODO: break cyclic dependency between libdm and libged
04:16.51CIA-59BRL-CAD: 03brlcad * r47762 10/brlcad/trunk/doc/deprecation.txt: ws and 3 months should be necessary, not sufficient
14:53.10CIA-59BRL-CAD: 03erikgreenwald * r47763 10/brlcad/trunk/src/libtclcad/cmdhist_obj.c: Move Cho_Init() to the end to avoid undefined function errors (prototypes were removed).
16:12.04n_reedis looking into the solids-regress failure
16:29.06n_reedI assert that r47659 is correct. I believe the test is what needs to be fixed.
16:29.53n_reedr47659 produces different shader strings for the mater calls in solids.sh which wrap plastic shader parameters in curly braces
16:30.04``Erikreference and output pix's are different in brightness, dude
16:30.25n_reedthat's correct
16:32.55``Erikheh, long standing bug, even O.o
16:34.03``Erikbrlcad: any special approach to altering reference data? (quorum, s2 signoff, anything?)
16:34.57``Erikthis, the m35 torus intersecting geom for tires edge hit difference, mebbe re-normalizing vgr's to fix sphflake?
16:43.52n_reedso everyone's on the same page: in the old code, plastic {di .9 sp .5} becomes plastic {{di .9 sp .5} }
16:44.08n_reedthis doesn't parse correctly, and is the same as applying default plastic shader
16:44.47n_reedr47659 fixed this, causing the parameters to actually be applied, resulting in different/brighter/correct output
16:49.56``Erikout of curiosity, have you tried putting in a bu_log to display the actual values used before and after the change?
17:09.32CIA-59BRL-CAD: 03bob1961 * r47764 10/brlcad/trunk/src/libged/polyclip.cpp: Fix ged_export_polygon() and ged_import_polygon() to handle multiple contours.
17:11.40CIA-59BRL-CAD: 03bob1961 * r47765 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Update to_data_polygons() import sub-command to set the polygon color, line-width and line-style.
17:27.17*** join/#brlcad milamber_ (414f0e1c@gateway/web/freenode/ip.65.79.14.28)
17:27.26*** part/#brlcad milamber_ (414f0e1c@gateway/web/freenode/ip.65.79.14.28)
17:44.12n_reederik: I have now. Logs show that phong shader gets correct parameters before revert, and defaults after revert.
17:45.48n_reedfurthermore, rt log from post-revert shows error messages indicating the parsing failure and change to defaults
17:46.55n_reedlike: "ERROR mlib_setup(/all.g/rec.r) failed. material='plastic', parameters='{sp .4 di .9 re .1}'. Changing /all.g/rec.r material to default and retrying."
17:50.07n_reedit's actually interesting that the shaders-regress didn't fail
17:51.15n_reedthat test never uses the tcl-list syntax so it was unaffected, but maybe now it should
20:18.47``Erikiiiiinteresting: http://stevehanov.ca/blog/index.php?id=130 http://pnylab.com/pny/papers/vptree/vptree/
20:45.51starseeker``Erik: is that useful for your bot work?
20:55.32``Eriknah, there's too much invested in kd trees with tie... but it might be a good approach for the nurbs trimming, among other things
20:56.10``Erikit's neat stuff, though... always neat learning new data structures and all
21:05.06*** join/#brlcad merzo (~merzo@48-62-132-95.pool.ukrtel.net)
22:39.54CIA-59BRL-CAD: 03n_reed * r47766 10/brlcad/trunk/ (6 files in 3 dirs): initial cmake build logic for perplex
IRC log for #brlcad on 20111203

IRC log for #brlcad on 20111203

03:14.18*** join/#brlcad merzo (~merzo@51-61-132-95.pool.ukrtel.net)
06:15.42*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
09:29.24*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
12:06.05*** join/#brlcad merzo (~merzo@51-61-132-95.pool.ukrtel.net)
13:22.40*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
13:36.08*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
16:11.27*** join/#brlcad piksi (piksi@pi-xi.net)
16:17.23``Erikcl
16:20.42``Erikhm, aptera is over
16:33.59*** join/#brlcad piksi (piksi@pi-xi.net)
18:54.04*** join/#brlcad piksi (piksi@pi-xi.net)
19:13.16*** join/#brlcad piksi (piksi@pi-xi.net)
19:52.12*** join/#brlcad Forth (~Forth@92.242.118.253)
20:36.05*** join/#brlcad merzo (~merzo@120-176-132-95.pool.ukrtel.net)
22:12.47starseekermourns, but isn't really surprised
23:46.43*** join/#brlcad DarkCalff (DC@173.231.40.98)
IRC log for #brlcad on 20111205

IRC log for #brlcad on 20111205

02:43.27*** join/#brlcad ibot (~ibot@rikers.org)
02:43.27*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
05:33.42*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
05:58.31CIA-28BRL-CAD: 03brlcad * r47767 10/brlcad/trunk/src/mged/CMakeLists.txt: apparently doing seomthing wrong, so document the FIXME accordingly mged needs to depend on the tclscripts or it won't work for non default and make install target builds (e.g., make regress)
06:04.45brlcadwonders what he's doing wrong given that's what looks like the documented way to do it
06:06.15CIA-28BRL-CAD: 03brlcad * r47768 10/brlcad/trunk/src/tclscripts/mged/CMakeLists.txt: ws
12:00.51*** join/#brlcad merzo (~merzo@193.254.217.44)
15:22.33brlcadn_reed: it's not inconceivable that the solids test image is flawed, but would be a little bit surprising
15:24.00brlcadthe regression scripts used to use mater "plastic var=val var2=val2" prior to release 7.0 (open sourcing)
15:25.21brlcadthey were all yanked at 7.0 since a couple had problems (unrelated), but then later returned a few months later in their current form
15:26.12brlcadpresumably butler was specifically testing whether the mater "plastic {var val var2 val}" syntax worked as that was when that change was made
15:31.05n_reedI agree that the presence of the brace syntax suggests an intent to test said syntax
15:32.41n_reedstill, all my testing thus far suggests that the syntax, at least recently, has not worked as intended
15:34.02n_reedit could be that the ineffectiveness of the brace syntax simply went unnoticed because it didn't generate any obvious errors (the raytrace and test still succeed)
15:34.27n_reedof course i could be wrong, and would be happying to continue investigating
15:35.36n_reedbut honestly i think it's best if you look into it yourself, because if your not convinced one way or another, I'm not going to bother with any changes
15:37.42n_reeds/happying/happy/
15:37.59n_reeds/your/you're
15:38.38n_reedneed's more caffeine
15:41.10n_reedNEEDS more sleep too x/
15:46.54brlcadI just pulled up the "original" solids reference image from before it was tclified
15:47.25brlcadlooks like a bug
15:48.04brlcadOR he was intentionally testing to make sure {} syntax fails ;)
15:48.49brlcadthat there be funny
15:52.53brlcadI bet I see what happened.  he also added a new dsp primitive to the test, so the image already changed/needed to change
15:53.16brlcadso a pixdiff would have already been reporting changes, even more easy to overlook those four others that changed due to syntax
15:54.50brlcadn_reed: looks like you're good to un-revert your fix back in
15:54.58brlcadjust update the reference while you're at it ;)
15:55.38brlcadthe old one doesn't have a dsp or I'd just drop it in, needs a new reference
15:56.31brlcadcross-check it with a couple platforms to make sure you get no off-by errors ..
15:57.13brlcadwishes we had a simh vgr
15:58.30n_reedwhat is a simh vgr?
15:58.53brlcadvgr was the name of the original baseline reference computer
15:59.24brlcadthe numerics were stable and rather well-understood for "correctness"
16:00.39brlcadthe benchmark reference images were mostly all created on vgr, so then if you were on a different computer and got pixel values that were ever so slightly off, you could investigate
16:01.20brlcadoff by more than one rgb value, and you were looking at a bug (either in code, or compiler, or hardware ... all encountered over the years)
16:02.32brlcadsimh is the "simulation hardware" project where they simulate various legacy systems (including a couple systems very similar to vgr's hardware)
16:02.54brlcadbasically, it's a VM for really old hardware
16:03.39brlcadif we could simulate vgr, we could regenerate new baseline images with a fair amount of confidence that they're "correct"
16:04.32brlcadtwo of our benchmark images frequently results in a handful of off-by-one differences -- those were the two not generated on vgr
17:13.25*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
17:38.52CIA-28BRL-CAD: 03n_reed * r47769 10/brlcad/trunk/regress/solidspix.asc: changed solids-regress reference image to agree with change in output-pix caused by fix in r47659
17:47.07CIA-28BRL-CAD: 03n_reed * r47770 10/brlcad/trunk/src/libbu/parse.c: revert to previous revision
19:33.03*** join/#brlcad merzo (~merzo@131-179-132-95.pool.ukrtel.net)
19:50.00*** join/#brlcad Forth (~Forth@92.242.118.253)
20:10.54brlcadstarseeker: how do you rebuild a specific object file?
20:12.10brlcadI just modified vls.c, want to make sure it still compiles, but don't want to relink libbu or some other binary .. is there some/any way to do that?
20:12.49brlcadold school makefile would have been a simple "make vls.o"
20:22.42*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
20:24.19*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
20:28.45*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
21:45.35starseekerbrlcad: not sure you can :-(
22:03.34CIA-28BRL-CAD: 03n_reed * r47771 10/brlcad/trunk/src/other/perplex/scanner_template.c: allow name of lexer routine and app data parameter to be specified with defines
22:04.06CIA-28BRL-CAD: 03starseeker * r47772 10/brlcad/trunk/src/ (mged/CMakeLists.txt tclscripts/CMakeLists.txt): Make mged depend on all pkgIndex/tclIndex targets. Probably should do the same for archer...
22:05.02starseekerah HAH!
22:05.13starseekerbrlcad: try this:  make vls.c.o
22:05.58starseekerI think that'll do what you want
22:07.35starseekerscratch that - only need to do that for archer if we make archer into a binary target ala mged
22:08.12starseekerunless we fake an archer build target just to hang those dependencies off of...
22:08.14starseekerhmm...
22:16.58CIA-28BRL-CAD: 03starseeker * r47773 10/brlcad/trunk/src/archer/CMakeLists.txt: Make a stab at switching archer over to a real live build target instead of just a configure-time copy. Untested on Windows.
22:20.21CIA-28BRL-CAD: 03starseeker * r47774 10/brlcad/trunk/src/archer/CMakeLists.txt: Now that we have an archer target, hang the tclscript dependencies off of it.
22:21.15starseekerre-reads his channel comments and realizes they're a bit mixed - brlcad, in my testing the make vls.c.o worked
22:25.57CIA-28BRL-CAD: 03starseeker * r47775 10/brlcad/trunk/src/CMakeLists.txt: checking clean configure - need tclscripts target lists defined before archer and mged targets are defined so a one-shot configure gets the right information.
22:39.26CIA-28BRL-CAD: 03starseeker * r47776 10/brlcad/trunk/src/archer/CMakeLists.txt:
22:39.27CIA-28BRL-CAD: Archer needs some more dependencies called out (mostly tcl/tk packages it uses).
22:39.27CIA-28BRL-CAD: 'make archer' now does more or less what you expect - the only exception being
22:39.27CIA-28BRL-CAD: the Docbook man pages. Not sure whether to make those dependencies...
22:41.45brlcadstarseeker: hm, looks like that'll only work if I'm in the cmake subdir for that .o, yes?
22:41.48brlcadshould work
22:42.11brlcadlibbu/tcl.c.o would have been cool
22:44.10brlcadstarseeker: and what was wrong with my ADD_DEPENDENCIES() line?  from my reading of the target names, that should have at least gotten the top-level tclscripts/tclIndex and pkgIndex.tcl files
22:45.45starseekerI think there was a capitalization error somewhere... anyway, the new logic should get 'em all
22:46.05starseekertclindex vs tclIndex, I think...
22:46.05brlcadwouldn't it have given me an error about an unknown dep though?
22:46.32starseekerum.  not sure - let me do a quick test
22:47.08brlcadand for that same reason, I added the one for pkgindex too -- or did it also have some case problem?
22:47.27starseekernope - no error.  It's probably figuring it will be defined later or something...
22:48.11starseekernot sure - as soon as I saw what you were trying to do I knew something more... energetic would be needed, so I just dove into the macro logic
22:48.38brlcadI knew something more generic was needed
22:48.50starseekerwe *should* be good now
22:48.50brlcadmore questioning why that simple test wasn't working
22:49.15starseekerunless you want all the docbook man pages added as dependencies of archer/mged when they're turned on
22:49.20starseekerah
22:49.45starseekerlooks again...
22:49.49brlcadyeah, i wasn't just trying to get past it, trying to understand what was going on
22:49.53starseekeryeah, it was pkgindex not pkgIndex
22:49.57brlcadmakes sense if it's case sensitive
22:50.43brlcadmeans I DID understand everything, just a pedantic detail missing from the auto-target naming that the macro was doing
22:50.46starseekermust confess it's kinda cool to be able to do "make archer" and have it jsut work...
22:50.49starseekerright
22:50.57brlcadtest confirmed here
22:51.57brlcadmake regress from a new build was failing due to the scripts dep
22:52.45brlcada nice side effect now is that you can "make regress", have it compile everything the regress suite uses, then make and see what else is likely not being exercised by the testing
22:52.52starseekeryeah, make libbu/tcl.c.o doesn't work work...  at a guess, they didn't want to populate all the parent make files with all child targets...
22:55.34starseekeryeah, that makes sense - I was probably always running "make regress" *after* doing make all
22:55.45starseekeroops
22:55.56brlcadlikewise, I just happened to have a fresh build and was testing nick's discovery
22:56.06brlcads/build/checkout/
22:56.33starseekertalk about an oldie...
22:56.46brlcadthat's not old, less than 10 years ;)
22:57.05starseekerwell, true, but I mean as part of the regression logic/data
22:57.11starseekereeep
22:58.19starseekerbrlcad: how do you want me to handle it with the thrid party packages/options?  I can just document all 3rd party options in the file, or I can set it up to only document the subset that are already documented for configure.ac...
22:58.25starseekerthird even...
22:58.42starseekerinstructs fingers to get with the program...
23:12.49brlcadwhat do you mean?  options such as?
23:13.41brlcadwhat was documented by configure?  it autodocumented subconfigures and we didn't directly document anything that I'm aware of other than the enable/disable-build options
23:13.45starseekerwell, for example, right now there aren't any descriptions for re2c, lemon, tkhtml, tkpng, etc. in INSTALL
23:14.19brlcadthe documenting stopped when cmake docs were rolled in, those mostly all came after
23:14.23starseekerwe do have zlib, png, opennurbs, utahrle, etc.
23:14.32starseekerright - so what are my criteria for adding things?
23:14.34brlcadso more enable/disable options
23:14.52starseekervs. ignoreing 'em
23:15.25brlcadif they're significant enough to warrant a src/other building, they should be listed
23:15.40starseekeralrightie
23:15.59brlcadall the more reason to be cautious about adopting new deps, they have overhead to be consistent
23:16.34brlcadcan ignore any that are going away in the next 3-6 months (like jove)
23:17.33starseekerwon't be too bad once I get up and rolling, just wanted to be sure I wasn't wasting my time on things you didn't want documented
23:18.59brlcadcould put re2c, lemon, and perplex into their own subdir in src/other, all toggled off just one flag
23:19.34starseekerreally?  arrgh :-)  after all that nice find logic too...
23:19.58brlcaddon't have to
23:20.01brlcadit's fine separate
23:20.08brlcadit's if you wanted to consolidate logic
23:20.38starseekernods - worth keeping in mind for later, but right now I'd say leave it as-is, since it's functional
23:20.46brlcadsimilarly with hv3 under tkhtml, similarly minor
23:21.50starseekernods
23:22.14brlcadaside from hv3 being a versioned-dir tsker
23:22.35starseekershould bug bob about trying that shiny new accordian widget out on the new-improved help browser
23:27.39CIA-28BRL-CAD: 03starseeker * r47777 10/brlcad/trunk/src/tclscripts/CMakeLists.txt: mind the advanced markings...
23:28.03CIA-28BRL-CAD: 03starseeker * r47778 10/brlcad/trunk/CMakeLists.txt: Add some aliases for the strict flags.
23:43.52starseekerisn't entirely sure if he cares for the idea of enable/disable options for word size
23:46.20CIA-28BRL-CAD: 03brlcad * r47779 10/brlcad/trunk/src/libfb/fb_obj.c: reorder to avoid the need for forward declarations. make the command table internal to the function (yet still static so it persists).
23:52.40CIA-28BRL-CAD: 03starseeker * r47780 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: build the disable options list in a different way.
23:54.01CIA-28BRL-CAD: 03starseeker * r47781 10/brlcad/trunk/CMakeLists.txt: Add docs for 32/64 bit BRLCAD_WORD_SIZE
23:57.52brlcadthey don't really make sense for word size
23:58.16brlcadword size is just that, unless you change it back to configure's meaning being a flag for 64-bit on/off
IRC log for #brlcad on 20111206

IRC log for #brlcad on 20111206

00:35.02starseekerright now I've got the enable and disable 64bit vars setting to 32/64bit... fairly compatible with the old configure behavior
00:36.26starseekernot particularly attached to it though if you think it's a bad move - did it mainly for compatibility with old INSTALL doc...
01:19.02brlcadI think that since the variable isn't defined the same way that using the old names just makes it more confusing as to what the variable actually represents
01:19.50brlcadit's either a word size setting or it's a toggle to turn 64-bit on/off .. shouldn't be both
01:20.40brlcadeither makes sense
01:21.32brlcadthe build system is deprecated, we're not aiming for compatibility or we wouldn't have needed to deprecate
01:22.16brlcadthe goal should be clarity, simplicity, and as dead-obvious easy-to-use as we can make it
01:43.05starseekerworks for me
01:45.27CIA-28BRL-CAD: 03starseeker * r47782 10/brlcad/trunk/CMakeLists.txt: Nevermind - we have a different variable, so don't emulate the old system for 64 bit.
01:48.36CIA-28BRL-CAD: 03starseeker * r47783 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: begone debug printout
03:46.48*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
04:26.46*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
05:34.26*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
05:35.26*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
06:07.37*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
07:50.41brlcadaaaalmost done reworking the bu_cmd() interface to all be devoid of tcl and to update all callers accordingly...
10:31.58*** join/#brlcad yiyus (1242712427@je.je.je)
11:49.33CIA-28BRL-CAD: 03brlcad * r47784 10/brlcad/trunk/ (15 files in 2 dirs): make the file argument to if_open() const.
11:57.39CIA-28BRL-CAD: 03brlcad * r47785 10/brlcad/trunk/src/libfb/tcl.c: reorder to avoid forward decls, make cmdtab private to init func.
12:06.46CIA-28BRL-CAD: 03brlcad * r47786 10/brlcad/trunk/src/libtclcad/tclcad.c:
12:06.46CIA-28BRL-CAD: provide an alternative to bu_register_cmds() so we can make remove the bu func
12:06.46CIA-28BRL-CAD: as a minimally impacting API change. to do this, we need to wrap the bu_cmdtab
12:06.46CIA-28BRL-CAD: functions since they're similarly undergoing a signature change to eliminate the
12:06.46CIA-28BRL-CAD: tcl binding.
12:08.03CIA-28BRL-CAD: 03brlcad * r47787 10/brlcad/trunk/include/tclcad.h: declare/export the new tclcad_register_cmds() function so we can eliminate bu_register_cmds().
12:08.14CIA-28BRL-CAD: 03brlcad * r47788 10/brlcad/trunk/src/libtclcad/tclcad.c: remove extra semi
12:11.35CIA-28BRL-CAD: 03brlcad * r47789 10/brlcad/trunk/src/libfb/ (if_X24.c if_ogl.c if_wgl.c): propagate const to all of the argv of the various open_existing() functions
12:22.45CIA-28BRL-CAD: 03indianlarry * r47790 10/brlcad/trunk/src/other/step/src/clstepcore/sdaiString.h: Fixed asStr(), was broken in the scl_string -> std::string rework.
12:23.16CIA-28BRL-CAD: 03indianlarry * r47791 10/brlcad/trunk/src/other/step/src/clstepcore/STEPattribute.cc: Looks like possible debugging code left in during the scl_string -> std::string rework breaking STEPattribute::is_null() for STRING_TYPE and BINARY_TYPE, commented out for now.
14:03.20*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
14:16.59*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
15:05.28*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
16:03.35CIA-28BRL-CAD: 03n_reed * r47792 10/brlcad/trunk/src/other/perplex/scanner_template.c: readability
16:39.54CIA-28BRL-CAD: 03n_reed * r47793 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re): allow C comments in rules section
17:21.07CIA-28BRL-CAD: 03brlcad * r47794 10/brlcad/trunk/src/libged/ (vdraw.c view_obj.c wdb_vdraw.c): move the static command tables into the functions that use them
17:23.13CIA-28BRL-CAD: 03brlcad * r47795 10/brlcad/trunk/src/libged/dg_obj.c: move the static command table into the function that uses it
17:33.51CIA-28BRL-CAD: 03n_reed * r47796 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.h scanner.re): add support for re2c named-definitions syntax
17:44.07CIA-28BRL-CAD: 03brlcad * r47797 10/brlcad/trunk/src/libged/ (dg_obj.c wdb_nirt.c): massive reordering to eliminate forward declarations. moved dgo_pr_wait_status to nirt as pr_wait_status since that's the only place it's used.
17:54.16CIA-28BRL-CAD: 03brlcad * r47798 10/brlcad/trunk/src/libged/wdb_obj.c: more massive reordering to eliminate forward decls
18:08.07CIA-28BRL-CAD: 03starseeker * r47799 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: go full path on src/other executables, since if we're trying to build bundled and there is a system version of the exec present in path, the target name will end up calling the system binary when it trys to run.
18:35.54CIA-28BRL-CAD: 03n_reed * r47800 10/brlcad/trunk/src/other/perplex/parser.y: reduce code duplication
19:13.23CIA-28BRL-CAD: 03r_weiss * r47801 10/brlcad/trunk/src/libbu/pool.c: New code for memory pooling within libbu. This is a work is progress. Adding file "pool.c".
19:17.45CIA-28BRL-CAD: 03r_weiss * r47802 10/brlcad/trunk/src/libbu/Makefile.am: Update to "Makefile.am" to add file "pool.c" to libbu.
19:18.54CIA-28BRL-CAD: 03r_weiss * r47803 10/brlcad/trunk/src/libbu/CMakeLists.txt: Update to file "CMakeLists.txt" to add file "pool.c" to libbu.
19:26.05CIA-28BRL-CAD: 03brlcad * r47804 10/brlcad/trunk/src/conv/step/Axis2Placement3D.cpp: possibly unitialized, init with VINIT_ZERO
19:32.59CIA-28BRL-CAD: 03r_weiss * r47805 10/brlcad/trunk/include/bu.h: Update to include file "bu.h", adding definitions for memory pool functions "bu_get_elem_from_pool" and "bu_free_elem_pool".
19:37.55CIA-28BRL-CAD: 03n_reed * r47806 10/brlcad/trunk/src/other/perplex/parser.y: remove debug output
19:38.02CIA-28BRL-CAD: 03brlcad * r47807 10/brlcad/trunk/src/conv/step/ (169 files): indent
19:56.21CIA-28BRL-CAD: 03n_reed * r47808 10/brlcad/trunk/src/other/perplex/scanner.re: Testing cursor position to detect exhaustion of buffered input, so don't append null at EOI, which caused parsing failure in some cases, and put restrictions on patterns.
20:24.18CIA-28BRL-CAD: 03n_reed * r47809 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re scanner_template.c): have caller specify end of string input rather than testing for null
20:27.50CIA-28BRL-CAD: 03r_weiss * r47810 10/brlcad/trunk/include/nmg.h: Update to "nmg.h" to enable the new libbu memory pooling for nmg structures.
20:40.49CIA-28BRL-CAD: 03r_weiss * r47811 10/brlcad/trunk/src/librt/db5_io.c: Update to file "db5_io.c" for function "db5_get_raw_internal_fp" within librt to enable new libbu memory pooling.
20:42.15CIA-28BRL-CAD: 03r_weiss * r47812 10/brlcad/trunk/src/librt/db5_scan.c: Update to file "db5_scan.c" for function "db5_scan" within librt to enable the new libbu memory pooling.
21:45.57CIA-28BRL-CAD: 03n_reed * r47813 10/brlcad/trunk/src/other/perplex/scanner_template.c: sync r47808 changes to template
21:54.54CIA-28BRL-CAD: 03brlcad * r47814 10/brlcad/trunk/src/libged/view_obj.c: reorder to eliminate forward decls
21:55.43CIA-28BRL-CAD: 03brlcad * r47815 10/brlcad/trunk/src/libged/view_obj.c: indent
22:20.25CIA-28BRL-CAD: 03brlcad * r47816 10/brlcad/trunk/include/ (CMakeLists.txt Makefile.am ged.h obj.h): add new obj.h header with the remaining view_obj and ged_obj structures that are in ged.h; don't want or need them, especially for libged.
22:22.42CIA-28BRL-CAD: 03brlcad * r47817 10/brlcad/trunk/include/ged.h: need fbserv_obj.h for structure decls. another dependency that should be decoupled..
22:24.25CIA-28BRL-CAD: 03brlcad * r47818 10/brlcad/trunk/ (4 files in 2 dirs): propagate obj.h where necessary
22:27.45CIA-28BRL-CAD: 03starseeker * r47819 10/brlcad/trunk/ (4 files in 3 dirs): Make sure the executables are present before we try doing anything with them.
22:28.17CIA-28BRL-CAD: 03brlcad * r47820 10/brlcad/trunk/src/gtools/g_diff.c: looks like wdb objects are used here by g_diff.. need to remove dependency since code is going away.
22:32.41CIA-28BRL-CAD: 03n_reed * r47821 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.h scanner.re): fixed support of re2c state transition syntax, broken by r47796
22:49.37CIA-28BRL-CAD: 03brlcad * r47822 10/brlcad/trunk/include/obj.h: give the obj structures a tcl_index stash-point so their funcs don't need to pass it explicitly
IRC log for #brlcad on 20111207

IRC log for #brlcad on 20111207

00:40.23CIA-28BRL-CAD: 03brlcad * r47823 10/brlcad/trunk/ (include/raytrace.h src/librt/primitives/bot/bot.c): make rt_bot_smooth() bot name be const
01:20.53CIA-28BRL-CAD: 03brlcad * r47824 10/brlcad/trunk/TODO: deprecation statements added, progress underway to rework rtarea.
01:22.04CIA-28BRL-CAD: 03brlcad * r47825 10/brlcad/trunk/NEWS: given this is a minor bump and we're a week deep, release should be stabilized by the end of dec.
01:27.15CIA-28BRL-CAD: 03starseeker * r47826 10/brlcad/trunk/src/archer/CMakeLists.txt: Er, right - iwidgets isn't a build target...
01:28.04CIA-28BRL-CAD: 03brlcad * r47827 10/brlcad/trunk/src/libdm/dm_obj.c: reorder to eliminate forward decls. move command table into function scope. staticness of data shouldn't be marked with HIDDEN.
01:53.42brlcadoooooooow... to painful to de-tcl
01:53.49brlcads/to pain/so pain/
02:11.09brlcada nearly 8k loc patch, damn sucky
02:11.41brlcadand that's not even all of it, that's fixing just two (pervasive) functions
02:11.50louipc!
02:15.31brlcadof course fixing those two functions ended up affecting the signatures to about 2000 other functions
02:34.52brlcadgives his pinky a rest
02:35.13CIA-28BRL-CAD: 03brlcad * r47828 10/brlcad/trunk/ (32 files in 9 dirs): (log message trimmed)
02:35.13CIA-28BRL-CAD: De-tcl two rather intertwined libbu functions, bu_observer_cmd() and bu_cmd(),
02:35.14CIA-28BRL-CAD: along with all of the command history functions. Define bu_cmdtab callback
02:35.14CIA-28BRL-CAD: signature so we get proper type checking, but instead of clientdata+tclinterp,
02:35.14CIA-28BRL-CAD: make it a void* and make argv const. Those changes end up impacting nearly 8k
02:35.14CIA-28BRL-CAD: lines of caller code where we have to update the (mostly-but-not-all-deprecated)
02:35.15CIA-28BRL-CAD: various "tcl object" codes to pass their data around within the new observer and
04:00.18CIA-28BRL-CAD: 03starseeker * r47829 10/brlcad/trunk/ (185 files in 19 dirs): (log message trimmed)
04:00.19CIA-28BRL-CAD: Coming very close to building xsltproc cross-platform for guaranteed
04:00.19CIA-28BRL-CAD: docbook->html documentation generation. Only known problem is on Windows, and
04:00.19CIA-28BRL-CAD: that seems to be primarily related to the new catalog usage with the advanced
04:00.19CIA-28BRL-CAD: Docbook formatting (to the best of my knowledge, the new Docbook formatting
04:00.19CIA-28BRL-CAD: logic has never been tested on Windows before.) Setting environment variables
04:00.20CIA-28BRL-CAD: in the CMake COMMAND lines didn't go over well on Windows, so have shifted to a
04:14.59*** join/#brlcad kanzure (~kanzure@131.252.130.248)
06:52.47*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
09:57.49CIA-28BRL-CAD: 0394.122.66.247 07http://brlcad.org * r3249 10/wiki/Talk:Main_Page:
11:26.41*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
11:28.04*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
15:47.19*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
17:14.58CIA-28BRL-CAD: 03erikgreenwald * r47830 10/brlcad/trunk/include/ (CMakeLists.txt Makefile.am icv.h): add icv.h
17:20.36CIA-28BRL-CAD: 03starseeker * r47831 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: Don't automatically flag a BRLCAD_OPTION as advanced...
17:23.12CIA-28BRL-CAD: 03starseeker * r47832 10/brlcad/trunk/src/other/xsltproc/ (CMakeLists.txt libxml/CMakeLists.txt libxml/src/xmlIO.c): Tweaks to try improving build on Windows...
17:28.14CIA-28BRL-CAD: 03erikgreenwald * r47833 10/brlcad/trunk/ (5 files in 2 dirs): copy bu_image stuff into icv
17:32.50*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
17:33.50CIA-28BRL-CAD: 03erikgreenwald * r47834 10/brlcad/trunk/ (doc/deprecation.txt src/libbu/image.c): list bu_image_* as deprecated
17:57.05CIA-28BRL-CAD: 03erikgreenwald * r47835 10/brlcad/trunk/src/ (10 files in 3 dirs): bu_image -> icv_image
18:32.09CIA-28BRL-CAD: 03erikgreenwald * r47836 10/brlcad/trunk/src/libgcv/ (6 files): break moller triangle intersection stuff out into seperate file
18:33.13brlcad``Erik: nifty .. considered that myself a while back
18:33.26``Erikwhich? bu_image -> icv?
18:33.48brlcadyep
18:34.33brlcadfwiw, it's minimally impacting (meaning you can remove the bu_image* stuff) if caller code can be updated with a simple regex
18:34.34``ErikI doubt any third party stuff is using bu_image, but I'll wait before eradicating it (and removing the png dependancy of libbu) *shrug*
18:35.00``Erikwell, then... it's gone :D is that a NEWS item?
18:35.06brlcadnope
18:35.20brlcadregex goes into the bottom of doc/deprecation
18:36.34brlcadNEWS is only "user-visible", which is not extended to "developer users" .. just folks that run the binaries
18:37.06brlcadthe equivalent for devs is "the source is the documentation"
18:37.13brlcadand doc/deprecation.txt of course :)
18:37.13``Eriktest builds
18:37.50``Erikyeh, hadn't looked at the bottom of deprecation.txt ... and doubted the sed4 script was still right
18:38.55brlcadonly the first (oldest v4->v5 api) one is sed, the rest are perl
18:39.18brlcadperl -0777 -pi -e 'EXPRESSION' FILE
18:39.39brlcadshould work with most if not all of them
18:40.30brlcadmain diff is using \( \) to capture \1 \2 \3 matches, () match literal
18:42.51CIA-28BRL-CAD: 03brlcad * r47837 10/brlcad/trunk/TODO:
18:42.51CIA-28BRL-CAD: others may work on annotations, so dump core. provide all the nitty gritty
18:42.51CIA-28BRL-CAD: details for what is needed from a GD&T perspective. focus is fully generalized
18:42.51CIA-28BRL-CAD: compact binary on-disk form specified via user-friendly command-line interface.
18:42.52CIA-28BRL-CAD: include references as there are standard conventions (iso and asme) expected on
18:42.52CIA-28BRL-CAD: how they're presented. initial stab implementation should focus on text and
18:42.53CIA-28BRL-CAD: leader annotations..
18:44.35CIA-28BRL-CAD: 03erikgreenwald * r47838 10/brlcad/trunk/ (4 files in 3 dirs): eradicate bu_image. s/bu_image/icv_image/g;s/BU_IMAGE/ICV_IMAGE/g (and link libicv) to migrate.
18:48.52CIA-28BRL-CAD: 03brlcad * r47839 10/brlcad/trunk/TODO: the radius 'R' has come before the value since 1982. get it right.
18:53.40``Erikneat, link breakage
19:08.55CIA-28BRL-CAD: 03erikgreenwald * r47840 10/brlcad/trunk/src/libicv/CMakeLists.txt: Fix link error. Apparently cmake uses arg ordering, not the duck method.
19:31.49CIA-28BRL-CAD: 03erikgreenwald * r47841 10/brlcad/trunk/src/ (fb/CMakeLists.txt util/CMakeLists.txt): add PNG_LIBRARY to programs needs libpng (was getting it from libbu before)
19:36.15CIA-28BRL-CAD: 03erikgreenwald * r47842 10/brlcad/trunk/src/libbu/CMakeLists.txt: add math lib
20:05.59brlcadthat mean you removed libpng from libbu?
20:08.39``Erikyeah
20:22.08starseekerhmm... another new opennurbs is out
20:31.14CIA-28BRL-CAD: 03brlcad * r47843 10/brlcad/trunk/src/libbu/tcl.c: bu_cmdtab callbacks take a void*
20:39.46CIA-28BRL-CAD: 03brlcad * r47844 10/brlcad/trunk/src/libbu/tcl.c:
20:39.46CIA-28BRL-CAD: fix the first of hopefully few bugs injected with the de-tcl'ing of libbu. in
20:39.46CIA-28BRL-CAD: order for these script callbacks to return a tcl value, they need to be set as
20:39.46CIA-28BRL-CAD: the result. noticed the '?' command no longer working in mged due to
20:39.46CIA-28BRL-CAD: bu_brlcad_data printing but not returning the path.
21:06.30CIA-28BRL-CAD: 03starseeker * r47845 10/brlcad/trunk/src/other/xsltproc/libxslt/CMakeLists.txt: no default path for win32 platforms
21:24.11brlcadwoot distcheck succeeds
21:24.17brlcader, regress rather
23:46.47CIA-28BRL-CAD: 03brlcad * r47846 10/brlcad/trunk/ (10 files in 5 dirs):
23:46.48CIA-28BRL-CAD: make a minimally impacting change to bu_cmd()'s signature swapping the arguments
23:46.48CIA-28BRL-CAD: so they are inputs followed by outputs convention. add a new result parameter
23:46.48CIA-28BRL-CAD: so we can distinguish between commands that don't exist and commands that fail.
23:46.48CIA-28BRL-CAD: the return value now indicates existence only while the result parameter will
23:46.48CIA-28BRL-CAD: contain the command's return value. this allows us to fix a few caller
23:46.49CIA-28BRL-CAD: instances that needed to distinguish the two.
23:49.05CIA-28BRL-CAD: 03brlcad * r47847 10/brlcad/trunk/doc/deprecation.txt:
23:49.05CIA-28BRL-CAD: document the minimally impacting change to bu_cmd() and (hopefully, untested)
23:49.05CIA-28BRL-CAD: fix several other minimally impacting regexes that escaped ()'s incorrectly.
23:49.05CIA-28BRL-CAD: perl captures matches with () and matches literals with \(\). logic was
23:49.05CIA-28BRL-CAD: reversed.
23:52.20CIA-28BRL-CAD: 03brlcad * r47848 10/brlcad/trunk/src/libged/dg_obj.c: potential crasher due to bad decl. wdb_print_node() no longer takes an interp.
IRC log for #brlcad on 20111208

IRC log for #brlcad on 20111208

00:15.54CIA-28BRL-CAD: 03r_weiss * r47849 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Update to function nmg_crackshells in file 'nmg_inter.c'. Improved bounding box checking to determine which faces will be intersected. This improves the speed of boolean operations on nmg objects.
00:18.39CIA-28BRL-CAD: 03r_weiss * r47850 10/brlcad/trunk/include/vmath.h: Updated include file 'vmath.h' adding the macro 'V3RPP_DISJOINT_TOL'.
00:24.06*** join/#brlcad cjdevlin (~devlin@d118-75-244-176.try.wideopenwest.com)
00:50.48CIA-28BRL-CAD: 03brlcad * r47851 10/brlcad/trunk/ (13 files in 4 dirs): (log message trimmed)
00:50.48CIA-28BRL-CAD: avoid the assumption that tol is a bn_tol. since they all just call the
00:50.48CIA-28BRL-CAD: distance tolerance, leave it up to the caller to provide the value so as an API
00:50.48CIA-28BRL-CAD: call, it only needs to be a tolerance value instead of a struct. propagate
00:50.48CIA-28BRL-CAD: accordingly throughout nmg. also leave FIXME notes for three macros that are
00:50.49CIA-28BRL-CAD: apparently using >= and <= comparisons with floating point values where the '='
00:50.50CIA-28BRL-CAD: case is not guaranteed to give stable behavior. the testing interval must be an
00:51.24brlcadopen interval
00:55.06CIA-28BRL-CAD: 03brlcad * r47852 10/brlcad/trunk/src/libfb/fb_obj.c: oops, libfb dir slipped through the cracks. apply bu_cmd() signature change.
01:05.08CIA-28BRL-CAD: 03brlcad * r47853 10/brlcad/trunk/doc/deprecation.txt: V3*_TOL() macros in vmath used to assume a structure with a ->dist element, which is kinda silly from an API standpoint. made them be a simple tolerance value.
01:05.23CIA-28BRL-CAD: 03brlcad * r47854 10/brlcad/trunk/src/libbu/Makefile.am: image.c is no more here, he go home now
01:09.39CIA-28BRL-CAD: 03brlcad * r47855 10/brlcad/trunk/src/libgcv/CMakeLists.txt: soup.h and tri_intersect.h missing from decls
01:10.03brlcad../../src/libged/.libs/libged.so: undefined reference to `icv_image_save_open'
01:10.27brlcadtools build, missing some libs decls
02:22.42CIA-28BRL-CAD: 03starseeker * r47856 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt books/en/CMakeLists.txt):
02:22.42CIA-28BRL-CAD: Well, the downloadable Windows xsltproc isn't succeeding either, and at least
02:22.42CIA-28BRL-CAD: some of the failure signature looks similar. Time to figure out why. Also,
02:22.42CIA-28BRL-CAD: need some fixes to executable calls - quite in docbook logic to allow for spaces
02:22.43CIA-28BRL-CAD: in pathnames (there'll probably be a lot more of this needed later on...) Still
02:22.43CIA-28BRL-CAD: need to rework the third party exec macro somewhat to allow for manual
02:22.44CIA-28BRL-CAD: specification of the executable path.
02:30.18*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
03:56.34*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
04:28.51*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
04:50.02*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
05:17.05*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
05:28.55CIA-28BRL-CAD: 03Sean 07http://brlcad.org * r3250 10/wiki/Talk:Main_Page: Reverted edits by [[Special:Contributions/94.122.66.247|94.122.66.247]] ([[User talk:94.122.66.247|Talk]]); changed back to last version by [[User:Sean|Sean]]
05:29.03CIA-28BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:94.122.66.247]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
06:03.15*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
06:22.18CIA-28BRL-CAD: 03brlcad * r47857 10/brlcad/trunk/include/bu.h:
06:22.19CIA-28BRL-CAD: create corollary macros for BU_GETSTRUCT(), BU_GETUNION(), and BU_GETTYPE()
06:22.19CIA-28BRL-CAD: named BU_PUTSTRUCT(), BU_PUTUNION(), and BU_PUTTYPE() respectively. regardless,
06:22.19CIA-28BRL-CAD: deprecate at least the struct/union macros in favor of the single type-agnostic
06:22.19CIA-28BRL-CAD: macro (though a better name might be simply BU_GET() and BU_PUT() to avoid the
06:22.19CIA-28BRL-CAD: klunky TT-name)
06:31.53CIA-28BRL-CAD: 03brlcad * r47858 10/brlcad/trunk/src/libbu/pool.c: ws indent consistency cleanup
06:34.56*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
07:04.31CIA-28BRL-CAD: 03brlcad * r47859 10/brlcad/trunk/ (5 files in 3 dirs): (log message trimmed)
07:04.31CIA-28BRL-CAD: rename the new libbu pool routines to be consistent with the existing libbu api.
07:04.31CIA-28BRL-CAD: groups functions are bu_GROUP prefix, so rename bu_get_elem_from_pool() to
07:04.31CIA-28BRL-CAD: bu_pool_get() and bu_free_elem_pool() to bu_pool_put() respectively. rename all
07:04.31CIA-28BRL-CAD: of the non-public implementation functions with a non-'bu_' and simpler 'pool_'
07:04.31CIA-28BRL-CAD: prefix. update existing callers accordingly. added notes on a few show-stopper
07:04.32CIA-28BRL-CAD: issues in the implementation, namely semaphore locking issues and not building
09:58.08*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
14:17.46*** join/#brlcad piksi (~piksi@pi-xi.net)
14:49.50*** join/#brlcad piksi (piksi@pi-xi.net)
15:17.22brlcadhowdy d_rossberg, ltns
15:34.00d_rossbergwriting reports as every year's end
16:13.27brlcadfun fun, sorry :)
16:13.41CIA-28BRL-CAD: 03brlcad * r47860 10/brlcad/trunk/include/bu.h:
16:13.41CIA-28BRL-CAD: implement more generalized BU_GET() and BU_PUT() macros intended to replace
16:13.41CIA-28BRL-CAD: BU_GETSTRUCT(), BU_GETUNION(), and BU_GETTYPE(). these versions should provided
16:13.41CIA-28BRL-CAD: added application security by guaranteeing zero-init and sanity cleanup when
16:13.41CIA-28BRL-CAD: released/put. used appropriately, they become convenient places to hook in a
16:13.41CIA-28BRL-CAD: pool allocator given the allocations are intrinsically small and defined as
16:13.42CIA-28BRL-CAD: dynamic.
16:36.56CIA-28BRL-CAD: 03starseeker * r47861 10/brlcad/trunk/doc/docbook/ (5 files in 2 dirs):
16:36.57CIA-28BRL-CAD: Rework the docbook logic again, to not use the catalog file - as near as I can
16:36.57CIA-28BRL-CAD: tell, it's just using the catalog file to all 'abbreviated' paths in a couple
16:36.57CIA-28BRL-CAD: other style files. Rather than do that, we can just make them .in files and
16:36.57CIA-28BRL-CAD: have CMake fill in the paths directly. Hopefully will put less strain on
16:36.57CIA-28BRL-CAD: xsltproc...
16:38.32CIA-28BRL-CAD: 03starseeker * r47862 10/brlcad/trunk/doc/docbook/resources/brlcad/ (9 files): Clear out files not needed by the CMake build (may have to put 'em back for autotools, so doing this as a separate commit to be easily reverted if need be.)
17:10.13``Erikheh, forget DRY, let's do WET (write everything twice)! :D
18:14.21CIA-28BRL-CAD: 03r_weiss * r47863 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Cleanup of function 'nmg_crackshells' in file 'nmg_inter.c'.
18:52.52brlcad``Erik: heh
18:53.22CIA-28BRL-CAD: 03r_weiss * r47864 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Update to function 'nmg_crackshells' to be consistent with macro changes.
18:53.57brlcadthis will be valuable to us: http://www.itworld.com/software/231515/usenix-dartmouth-expanding-diff-grep-unix-tools
18:54.18brlcadnot exactly what I had in mind for GS diffing, but it would probably work just as well
19:16.23CIA-28BRL-CAD: 03brlcad * r47865 10/brlcad/trunk/ (194 files in 57 dirs):
19:16.23CIA-28BRL-CAD: convert instances of the ol' BU_GETSTRUCT() macro over to the new BU_GET()
19:16.24CIA-28BRL-CAD: macro. callers now have to specify the full type (gasp, have to type struct ..
19:16.24CIA-28BRL-CAD: which they still had to type with bu_getSTRUCT...) which should help reduce
19:16.28CIA-28BRL-CAD: obfuscation for new devs (and reduces 3 API macros to 1).
19:20.54starseekerwww.cs.dartmouth.edu/reports/TR2011-705.pdf
19:22.31starseekerno code yet, I take it
19:22.35CIA-28BRL-CAD: 03brlcad * r47866 10/brlcad/trunk/ (34 files in 14 dirs): convert instances of the ol' BU_GETUNION() macro over to the new BU_GET() macro. callers now have to specify the full type which should help reduce obfuscation for new devs.
19:26.30starseekerwas plotting to look into libxdiff at some point... http://www.xmailserver.org/xdiff-lib.html
19:29.58CIA-28BRL-CAD: 03brlcad * r47867 10/brlcad/trunk/src/ (2 files in 2 dirs): last one, only a couple BU_GETTYPE() callers
19:36.07CIA-28BRL-CAD: 03starseeker * r47868 10/brlcad/trunk/doc/docbook/resources/brlcad/ (3 files): go from file:// to file:/// in xsl files, per suggestion from xml/xslt devs - unix doesn't seem to care, but on Windows it appears to matter... reindent as well
19:50.32CIA-28BRL-CAD: 03r_weiss * r47869 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Update to function 'nmg_crackshells' in file 'nmg_inter.c' to quiet compiler warnings of signed/unsighed compares.
20:02.06CIA-28BRL-CAD: 03starseeker * r47870 10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-man-stylesheet.xsl.in: fully qualify center-table-print path
20:40.41CIA-28BRL-CAD: 03r_weiss * r47871 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: Updated function 'nmg_bool' in file 'nmg_bool.c'. Removed unnecessary checking for dangling faces. This will improve the speed of nmg boolean operations.
21:22.54CIA-28BRL-CAD: 03starseeker * r47872 10/brlcad/trunk/src/other/xsltproc/ (libxml/CMakeLists.txt libxslt/CMakeLists.txt): Modules aren't behaving well on Windows for some reason, and we don't seem to need them anyway - disable
21:24.38CIA-28BRL-CAD: 03brlcad * r47873 10/brlcad/trunk/src/remrt/remrt.c: BU_GETSTRUCT->BU_GET
21:25.34CIA-28BRL-CAD: 03brlcad * r47874 10/brlcad/trunk/ (doc/deprecation.txt include/bu.h): replacement of BU_GETSTRUCT/UNION/TYPE with BU_GET are all minimally impacting, so go ahead and remove them now
21:41.52CIA-28BRL-CAD: 03starseeker * r47875 10/brlcad/trunk/doc/docbook/ (5 files in 3 dirs):
21:41.52CIA-28BRL-CAD: Take the 'write a cmake script file' to its logical conclusion and have a
21:41.52CIA-28BRL-CAD: template that is configured for each target. Simplifies the 'in CMakeLists.txt'
21:41.52CIA-28BRL-CAD: logic and avoids duplication, and if we need more tweakage on running xsltproc
21:41.52CIA-28BRL-CAD: or fop it's a lot simpler.
22:00.11CIA-28BRL-CAD: 03starseeker * r47876 10/brlcad/trunk/src/libged/dg_obj.c: Fix some stuff in ifdef win32 code related to the bu tcl changes
22:03.11CIA-28BRL-CAD: 03bob1961 * r47877 10/brlcad/trunk/src/libbu/tcl.c: Changed free() back to Tcl_Free().
22:22.34CIA-28BRL-CAD: 03brlcad * r47878 10/brlcad/trunk/ (4 files in 2 dirs): remove the obsolete libbu.3 manual page that has fallen significantly out of sync with the library API. migrate the (still useful) documentation bits into the bu.h header as doxygen comments for future doc purposing.
22:27.47CIA-28BRL-CAD: 03starseeker * r47879 10/brlcad/trunk/src/other/perplex/CMakeLists.txt: Don't assume the math library - bad assumption on Windows
22:56.07CIA-28BRL-CAD: 03brlcad * r47880 10/brlcad/trunk/ (7 files in 7 dirs): prefix the cmd.h defines with BU_ since they are part of the libbu api
22:56.33brlcadnote to self, check on archer drawing geometry: bu_get_value_by_keyword messages
23:13.43*** join/#brlcad piksi (piksi@pi-xi.net)
23:18.17CIA-28BRL-CAD: 03brlcad * r47881 10/brlcad/trunk/src/libdm/dm-rtgl.c: crash reported by Peter Machon ( muhala ) via sf bu report 3454338 that detected a bad magic failure on segs from rtgl's hit callback (finding a bu_list instead of a seg). it's not used so just don't perform that check.
IRC log for #brlcad on 20111209

IRC log for #brlcad on 20111209

00:50.20CIA-28BRL-CAD: 03starseeker * r47882 10/brlcad/trunk/ (7 files in 5 dirs): Make another stab at reworking the third party executable logic - idea is to support specifying the full path to an executable from the command line and have 'the right thing' happen.
01:16.03CIA-28BRL-CAD: 03starseeker * r47883 10/brlcad/trunk/src/libged/dg_obj.c: argc is int and i is size_t...
01:28.13CIA-28BRL-CAD: 03starseeker * r47884 10/brlcad/trunk/src/archer/archer: Tweak wording
01:47.32CIA-28BRL-CAD: 03starseeker * r47885 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: whoops - mark as advanced
02:01.20CIA-28BRL-CAD: 03starseeker * r47886 10/brlcad/trunk/CMakeLists.txt:
02:01.20CIA-28BRL-CAD: Slightly alter the pdf options logic, to avoid unexpected behavior. By default,
02:01.20CIA-28BRL-CAD: when enabling PDF building, ALL pdfs are now built. The PDF_MAN option still
02:01.20CIA-28BRL-CAD: appears after PDF is enabled, but it defaults to on rather than off to avoid
02:01.20CIA-28BRL-CAD: surprises - avoids the 'why didn't the man page pdfs get built even though I
02:01.20CIA-28BRL-CAD: enabled pdf?' question.
02:05.40starseekerah, FINALLY - a successful generation of an html man page on Windows
02:05.56starseekerwill try the full build later to see what's still busted
04:13.12CIA-28BRL-CAD: 03starseeker * r47887 10/brlcad/trunk/src/other/openNURBS/CMakeLists.txt: Do as the parent does when building static/shared libraries, opennurbs
04:38.09starseekerlearns another nifty vim trick - gq for dealing with long lines :-)
05:23.48starseekerwatches bemusedly as KDevelop tries to slug it out with BRL-CAD's toplevel CMakeLists.txt file...
07:07.34*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
07:26.55starseekernote to self - do for html and man what has already been done for pdf - allow enable/disable of the formats and set some sane defaults based on conditions
07:27.42starseekerno point in doing man pages when building with MSVC, and html is questionable when build is non-graphical...
07:28.19starseekeralso need to review the re2c/lemon dep callouts some more
07:41.10starseekeralso saw a warning about read being undefined in util/lowp.c (IIRC) - probably need bio.h or some other win32 headers in there somewhere...
07:42.42starseekerall that said, I present the first Windows exe installer generated using Visual Studio Express from trunk without any manual additions - CMake -> MSVC -> NSIS package
07:43.52starseekerhttp://brlcad.org/~starseeker/BRL-CAD_7.21.0_x86.exe
07:44.51starseekermore properly, first installer including documentation without manual additions
07:45.02starseekerzzz
12:46.55*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
17:24.58CIA-28BRL-CAD: 03bob1961 * r47888 10/brlcad/trunk/src/librt/wdb.c: Needs \!dp_curr instead of dp_curr.
19:05.38CIA-28BRL-CAD: 03bob1961 * r47889 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Remove temporary code.
19:07.05CIA-28BRL-CAD: 03bob1961 * r47890 10/brlcad/trunk/include/tclcad.h: Declare Cho_Init().
19:07.54CIA-28BRL-CAD: 03bob1961 * r47891 10/brlcad/trunk/src/bwish/main.c: Call Cho_Init().
19:10.23CIA-28BRL-CAD: 03starseeker * r47892 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: (hopefully) fix some third_party_executable issues
20:56.59CIA-28BRL-CAD: 03brlcad * r47893 10/brlcad/trunk/src/libbu/cmdhist.c: printing the commands via bu_log is kinda pointless since they need to be passed back as values. rely on the fact that they're set in chop->cho_curr, so no need to print them (except for the 'history' case
20:58.28CIA-28BRL-CAD: 03brlcad * r47894 10/brlcad/trunk/src/libtclcad/cmdhist_obj.c: capture the command set by libbu as the curr/prev/next command and feed it to Tcl_AppendResult so archer can do something with the strings. better than having the command sent to stderr...
21:05.34CIA-28BRL-CAD: 03starseeker * r47895 10/brlcad/trunk/ (3 files in 3 dirs): Add some more options to the Docbook building, and improve reporting for Itcl/Itk building.
21:08.13CIA-28BRL-CAD: 03starseeker * r47896 10/brlcad/trunk/src/ (13 files in 4 dirs): Tweaks to get things building with the (admittedly rare) case of disabling Tk.
21:18.43CIA-28BRL-CAD: 03brlcad * r47897 10/brlcad/trunk/src/libbu/tcl.c: Tcl_SplitList() returns TCL_OK/TCL_ERROR, not BRLCAD_OK... not equivalent
21:22.27CIA-28BRL-CAD: 03starseeker * r47898 10/brlcad/trunk/doc/docbook/CMakeLists.txt: Make sure we've got the cmake.in files listed
21:26.05CIA-28BRL-CAD: 03brlcad * r47899 10/brlcad/trunk/src/libbu/tcl.c: don't print a message if we can't find the object in a list, let the error return take over
21:35.27CIA-28BRL-CAD: 03starseeker * r47900 10/brlcad/trunk/src/other/re2c/CMakeLists.txt: make sure re2c depends on the lemon build target, if there is one.
21:47.23starseekerhmm... mged appears to be unhappy
21:48.03starseekeror more specifically, wdb_open is unhappy - "invalid command name"
22:13.56CIA-28BRL-CAD: 03starseeker * r47901 10/brlcad/trunk/src/util/lowp.c: Add bio.h to lowp.c
22:23.40brlcadstarseeker: undoubtedly recent tcl changes, when do you see the error?
22:23.45brlcadalso:
22:23.46brlcad[ 15%] [LEMON][ExpParser] Building parser with LEMON_EXECUTABLE-NOTFOUND
22:23.46brlcad/bin/sh: LEMON_EXECUTABLE-NOTFOUND: command not found
22:23.46brlcad[ 15%] [LEMON][ExpParser] Building parser with LEMON_EXECUTABLE-NOTFOUND
22:23.46brlcad/bin/sh: LEMON_EXECUTABLE-NOTFOUND: command not found
22:23.55brlcadrecent rebuild
22:24.11brlcadin src/other/step/src/express/expparse.c
22:42.47starseekerany time I'm trying to do an opendb in MGED
22:42.50starseeker(not archer)
22:42.54starseekerurm
22:46.14starseekerwhat build options are you using?
22:46.42starseekerI'd try with a clean cache and the latest... there have been a couple changes recently that might not deal well with an intermediate cache state
22:55.59starseekerboth auto and bundled seem to succeed here...
23:06.04CIA-28BRL-CAD: 03starseeker * r47902 10/brlcad/trunk/CMakeLists.txt: add spacer
23:07.14starseekerhello...
23:08.12starseekerblinks - wait, just saw something...
23:12.18starseekerbrlcad: OK, I'm seeing it
23:12.26starseekeror something related, at any rate
23:30.28CIA-28BRL-CAD: 03starseeker * r47903 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: Don't cache the build target path.
23:31.03starseekerok, I think that's got it - I tried repeated configures with bundled/auto settings and I'm not seeing any surprises
IRC log for #brlcad on 20111210

IRC log for #brlcad on 20111210

00:14.57CIA-28BRL-CAD: 03n_reed * r47904 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner.re): redesigning parser to address readability and robustness
00:32.46CIA-28BRL-CAD: 03n_reed * r47905 10/brlcad/trunk/src/other/perplex/parser.y: generate default code for rules that specify none
02:10.38*** part/#brlcad milamber (~devlin@d118-75-244-176.try.wideopenwest.com)
03:40.10*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
05:37.51starseekerhmm... should probably take a look at the Point Cloud Library's kdtree and octree stuff...
11:47.24*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
19:38.58*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20111211

IRC log for #brlcad on 20111211

06:05.56*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
07:40.11*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
07:49.54*** join/#brlcad abhi2011 (~chatzilla@117.200.86.131)
12:18.57*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
15:27.42*** join/#brlcad juan_man (~quassel@unaffiliated/juanman)
15:31.55*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
16:35.04*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
17:09.18*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
22:05.33*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
22:18.02*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
22:19.23*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
22:19.42*** join/#brlcad cvds_ (~leila@h111030.upc-h.chello.nl)
22:19.45*** join/#brlcad brlcad (~sean@63.246.136.16)
22:19.48*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
22:20.08*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
22:20.08*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
22:20.10*** join/#brlcad starseeker (~starseeke@63.246.136.16)
22:20.10*** join/#brlcad piksi (piksi@pi-xi.net)
22:20.56*** join/#brlcad alex_joni (~alex_joni@81.196.65.201)
22:20.57*** join/#brlcad louipc (~louipc@archlinux/fellow/louipc)
22:21.32*** join/#brlcad DarkCalff (DC@173.231.40.98)
22:23.08*** join/#brlcad ibot (~ibot@rikers.org)
22:23.08*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
22:25.33*** join/#brlcad CIA-28 (~CIA@cia.atheme.org)
22:25.48*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
22:57.12*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
IRC log for #brlcad on 20111212

IRC log for #brlcad on 20111212

00:57.35*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
02:02.47*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
02:15.56*** join/#brlcad abhi2011 (~chatzilla@117.200.84.253)
02:23.58*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
03:00.15*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
04:06.07*** join/#brlcad abhi2011 (~chatzilla@117.200.88.218)
04:35.44*** join/#brlcad abhi2011 (~chatzilla@117.200.88.43)
04:36.52abhi2011Hi, I am getting these errors related to _vsnprintf in the windows build
04:36.57abhi2011http://bin.cakephp.org/view/250238996
04:37.38abhi2011its in the xml project
07:29.49*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
09:05.44*** join/#brlcad abhi2011 (~chatzilla@117.200.86.190)
09:36.15*** join/#brlcad abhi2011 (~chatzilla@117.200.87.190)
10:46.07*** join/#brlcad abhi2011 (~chatzilla@117.200.94.106)
10:58.26*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
13:14.41*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
13:19.03CIA-28BRL-CAD: 03d_rossberg * r47906 10/brlcad/trunk/src/other/xsltproc/ (libexslt/src/exslt.c libxml/include/libxml.h xsltproc.c): MSVC-build: the _vsnprintf declaring stdio.h has to be included before the config.h whith its vsnprintf define
13:19.11CIA-28BRL-CAD: 03Tbrowder 07http://brlcad.org * r3251 10/wiki/Continuous_Integration: add links to more buildbot info
13:21.23CIA-28BRL-CAD: 03Tbrowder 07http://brlcad.org * r3252 10/wiki/Continuous_Integration:
13:26.06CIA-28BRL-CAD: 03Tbrowder 07http://brlcad.org * r3253 10/wiki/Main_Page: /* Getting started */
14:03.05*** join/#brlcad abhi2011 (~chatzilla@117.200.82.193)
14:33.25abhi2011starseeker. thanks, that fixed it
14:34.49abhi2011getting an error while opening files: http://imageshack.us/f/841/forcel.png/
14:35.46abhi2011invalid command name  wdp_open ,hmmm
14:42.07abhi2011incorrect command generated in event_check() in mged.c i think
14:46.24starseekerabhi2011: that was d_rossberg fixing it :-)
14:46.55abhi2011woops, ok  :)
14:47.08abhi2011any idea about the wdb_open bug though
14:47.23abhi2011I am not that good with the Tcl/Tk event management thing
14:47.26abhi2011:P
14:48.45starseekerI'm seeing it myself, but I'm not sure what to do about it
14:50.00abhi2011I ll check the mged.c changes recently
14:58.46d_rossbergsrc/mged/setup.c +line 445: Wdb_Init(INTERP);
14:59.29d_rossberg(just a thought)
15:15.07abhi2011wow, that was it
15:15.27abhi2011so the Tcl interface for libwdb was not added
15:19.00CIA-28BRL-CAD: 03abhi2011 * r47907 10/brlcad/trunk/src/mged/setup.c: Added a line to create the Tcl command for wdb_open.
15:20.11d_rossberg:)
15:33.15n_reedthe only thing with Wdb_Init is that it has been listed as deprecated in include/obj.h
15:37.27abhi2011yes, so what would be the alternative to adding the command
15:38.54abhi2011it seems to be simply a Tcl_CreateCommand() call
15:39.16abhi2011wonder why it has been depreciated
15:39.34n_reedme too
15:42.16n_reedwdb_open doesn't appear to be used by archer
15:42.50n_reedit only appears in a deprecated widget
15:43.28n_reedcould be that wdb_open itself is deprecated, and its use at mged.c:2906 needs to go away
15:43.44abhi2011yeah, that could be it
15:48.49abhi2011I wonder if there is an alternate command to open DB files in Tcl
16:24.20CIA-28BRL-CAD: 03n_reed * r47908 10/brlcad/trunk/src/other/perplex/perplex.cpp: reformat error string
16:29.48CIA-28BRL-CAD: 03n_reed * r47909 10/brlcad/trunk/src/other/perplex/parser.y: fix typo causing segfault when using empty condition
17:01.17*** join/#brlcad abhi2011 (~chatzilla@117.200.84.243)
17:46.35CIA-28BRL-CAD: 03abhi2011 * r47910 10/brlcad/trunk/src/libged/simulate/simrt.c: Corrected crash during air gap calculations due to a wrong index being used.
18:58.49*** join/#brlcad abhi2011_ (~chatzilla@117.200.82.176)
20:01.35CIA-28BRL-CAD: 03n_reed * r47911 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner.re): put support for condition scopes back in
20:12.33CIA-28BRL-CAD: 03r_weiss * r47912 10/brlcad/trunk/src/libbn/plane.c: Update to the libbn function 'bn_pt3_pt3_equal' in file 'plane.c'. This change was to improve performance.
20:31.22CIA-28BRL-CAD: 03r_weiss * r47913 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: Updated function 'nmg_model_break_e_on_v' in file 'nmg_fuse.c'. Added bounding box testing to improve performance.
20:51.12CIA-28BRL-CAD: 03r_weiss * r47914 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c:
20:51.12CIA-28BRL-CAD: Update to function 'nmg_isect_eu_eu' in file 'nmg_inter.c'. Added bounding box
20:51.12CIA-28BRL-CAD: testing, removed excessive magic checks, fixed some float zero compares. The
20:51.12CIA-28BRL-CAD: bounding box and magic check changes were to improve performance.
20:52.53CIA-28BRL-CAD: 03n_reed * r47915 10/brlcad/trunk/src/other/perplex/scanner.re: fix pattern for matching condition list
21:13.38CIA-28BRL-CAD: 03n_reed * r47916 10/brlcad/trunk/src/other/perplex/ (parser.y scanner.re): put support for re2c-style named definitions back in
21:15.16*** join/#brlcad abhi2011_ (~chatzilla@117.200.81.218)
21:49.27CIA-28BRL-CAD: 03r_weiss * r47917 10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c: Updated function 'nmg_2edgeuse_g_coincident' in file 'nmg_info.c'. Removed an unnecessary parallel test and excessive magic tests. These changes were to improve performance.
23:14.35CIA-28BRL-CAD: 03starseeker * r47918 10/brlcad/trunk/src/other/Makefile.am: Add xsltproc dir and dist file to Makefile.am EXTRA_DIST
23:51.49CIA-28BRL-CAD: 03starseeker * r47919 10/brlcad/trunk/src/libbu/Makefile.am: uce-dirent.h is back in libbu - let autotools know about it.
IRC log for #brlcad on 20111213

IRC log for #brlcad on 20111213

00:01.17CIA-28BRL-CAD: 03starseeker * r47920 10/brlcad/trunk/misc/Makefile.am: Hmm, another Makefile.am list out of date...
00:24.38starseekerhmm... apparently OCE has jabbed the OpenCascade guys into some more energetic activity... http://dev.opencascade.org/
00:25.03starseekercan't help thinking the requirement for a "Contributor License Agreement" will be a non-starter...
00:26.15CIA-28BRL-CAD: 03n_reed * r47921 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner.re): should only look for named definitions outside of rule actions
01:16.17CIA-28BRL-CAD: 03r_weiss * r47922 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c: Updated functions 'nmg_crackshells' and 'nmg_isect_two_generic_faces'. Added function 'nmg_no_isect_fu_pl' which compares a face to a plane and determines if there is no intersection.
01:19.56CIA-28BRL-CAD: 03starseeker * r47923 10/brlcad/trunk/ (5 files in 5 dirs): I *think* this turns off the Docbook building for Autotools, which is no longer expected to be fully working... getting icv errors when building rt, so can't so a full distcheck yet.
01:20.29starseekers/can't so/can't do/
02:11.45*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
07:53.05*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
09:26.57*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
09:28.47*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
09:29.18*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
09:39.36*** join/#brlcad cvds_ (~leila@e255180.upc-e.chello.nl)
12:41.14*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
12:42.32*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
12:45.49*** join/#brlcad brlcad (~sean@63.246.136.16)
17:00.45*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
17:10.40CIA-28BRL-CAD: 03n_reed * r47924 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp scanner.re): change matching of named definitions to not conflict with matching of condition changes
17:17.48*** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net)
17:32.45*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
17:36.35*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
17:49.51*** join/#brlcad starseek1r (~starseeke@BZ.BZFLAG.BZ)
17:53.23*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
17:54.53*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
18:02.12*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
18:25.50starseekerhmm... fun connection today
19:16.57CIA-28BRL-CAD: 03starseeker * r47925 10/brlcad/trunk/src/other/ (6 files in 5 dirs): Add the license information and a brief README to xsltproc
20:36.19CIA-28BRL-CAD: 03starseeker * r47926 10/brlcad/trunk/src/rt/Makefile.am: Add ICV to rt Makefile.am
20:44.33CIA-28BRL-CAD: 03starseeker * r47927 10/brlcad/trunk/src/ (Makefile.am remrt/Makefile.am): Couple more icv tweaks
21:18.05starseekerwoot - autotools distcheck passes again
21:46.45CIA-28BRL-CAD: 03r_weiss * r47928 10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c: Updated function 'nmg_2edgeuse_g_coincident' in file 'nmg_info.c'. Removed unnecessary tests to improve performance.
23:26.11CIA-28BRL-CAD: 03n_reed * r47929 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp perplex.h scanner.re): improvements to named definition matching and input buffering
IRC log for #brlcad on 20111214

IRC log for #brlcad on 20111214

00:11.13*** join/#brlcad b0ef (~b0ef@78.58.34.95.customer.cdi.no)
01:13.42CIA-28BRL-CAD: 03n_reed * r47930 10/brlcad/trunk/src/other/perplex/scanner.re: cleanup of buffering routines
01:37.13*** join/#brlcad louipc (~louipc@archlinux/fellow/louipc)
02:53.55*** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net)
03:08.36CIA-28BRL-CAD: 03starseeker * r47931 10/brlcad/trunk/ (61 files in 12 dirs): Make a stab at adding an xml validation step to the build. Looks like xml/xslt upgrades are needed, and even then the results are... a little confusing.
03:23.16starseekerHmm... the rnv results actually look more promising/useful...
08:13.22*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
12:34.33CIA-28BRL-CAD: 03125.62.202.148 07http://brlcad.org * r3254 10/wiki/User:Abhijit:
14:15.23*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
14:21.51*** join/#brlcad n_reed (~nicholas@c-68-55-142-136.hsd1.md.comcast.net)
14:37.37CIA-28BRL-CAD: 03starseeker * r47932 10/brlcad/trunk/doc/docbook/ (DB_VALIDATE.cmake xmllint.cmake.in):
14:37.38CIA-28BRL-CAD: Don't use the rng schema with xmllint, per advice from the libxml list -
14:37.38CIA-28BRL-CAD: fortunately, we can also use a more standard schema. Also, rather than defining
14:37.38CIA-28BRL-CAD: the flags somewhere other than the 'command' file, make it self contained - in
14:37.38CIA-28BRL-CAD: prinicple, that should make swapping in a different validator as simple as
14:37.38CIA-28BRL-CAD: defining a .cmake.in file for that command and setting a toplevel setting. Need
14:37.39CIA-28BRL-CAD: to experiment a little.
14:39.51CIA-28BRL-CAD: 03starseeker * r47933 10/brlcad/trunk/doc/docbook/lessons/en/ (4 files): Few tweaks to lesson files from xmllint testing... undoubtedly more needed in the various docbook files.
14:44.13CIA-28BRL-CAD: 03starseeker * r47934 10/brlcad/trunk/doc/docbook/books/en/ (2 files): Some tweaks to the book files - volume IV looks like a bit more work...
15:17.36CIA-28BRL-CAD: 03starseeker * r47935 10/brlcad/trunk/ (5 files in 2 dirs): Reorganize Docbook build logic - try to keep command-specific stuff in the command files.
15:19.27CIA-28BRL-CAD: 03starseeker * r47936 10/brlcad/trunk/doc/docbook/ (21 files in 11 dirs): Docbook is off in autotools, so the Makefile.am files aren't needed anymore. Scrub.
15:34.17CIA-28BRL-CAD: 03starseeker * r47937 10/brlcad/trunk/ (doc/docbook/CMakeLists.txt misc/CMake/Docbook.cmake): Move the Docbook target macros to Docbook.cmake
16:32.34CIA-28BRL-CAD: 03starseeker * r47938 10/brlcad/trunk/ (9 files in 2 dirs): Modularize the DocBook processing - can now specify custom tools, so long as a misc/CMake/tool.cmake.in file is written to tell CMake how to run the tool. Add rnv as a validation example.
16:41.20*** join/#brlcad abhi2011 (~chatzilla@117.200.85.163)
16:54.30brlcadabhi2011: hello!  ltns..
16:54.46abhi2011hello brlcad :)
16:55.13brlcadhow are classes going?
16:55.23CIA-28BRL-CAD: 03n_reed * r47939 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp scanner.re): make named definitions look like rules to simplify grammar and avoid confusing parser
16:58.18brlcadmm, classes are probably over actually.
17:39.32CIA-28BRL-CAD: 03starseeker * r47940 10/brlcad/trunk/ (8 files in 4 dirs):
17:39.32CIA-28BRL-CAD: Make a stab at supporting multiple executables in one subdir with
17:39.32CIA-28BRL-CAD: THIRD_PARTY_EXECUTABLE. Move xsltproc dir to xmltools since it is no longer
17:39.32CIA-28BRL-CAD: just about xsltproc. Validation xml targets should now properly depend on the
17:39.33CIA-28BRL-CAD: xmllint target.
17:47.14CIA-28BRL-CAD: 03starseeker * r47941 10/brlcad/trunk/src/other/CMakeLists.txt: CMake can be run multiple times...
17:53.49CIA-28BRL-CAD: 03starseeker * r47942 10/brlcad/trunk/CMakeLists.txt: Comment tweaks
18:05.49CIA-28BRL-CAD: 03n_reed * r47943 10/brlcad/trunk/src/other/perplex/scanner.re: need to include null element when copying buffer
18:13.19CIA-28BRL-CAD: 03starseeker * r47944 10/brlcad/trunk/misc/CMake/Docbook.cmake: Make the generation targets depend on the validation targets for docbook, if they are enabled.
18:19.25CIA-28BRL-CAD: 03n_reed * r47945 10/brlcad/trunk/src/other/perplex/scanner.re: address compiler warnings
18:22.06CIA-28BRL-CAD: 03n_reed * r47946 10/brlcad/trunk/src/other/perplex/scanner_template.c: sync scanner buffer routine changes to template
19:29.41CIA-28BRL-CAD: 03n_reed * r47947 10/brlcad/trunk/src/other/perplex/scanner_template.c: add macro at scanner entrance for user entrance code
20:27.00CIA-28BRL-CAD: 03r_weiss * r47948 10/brlcad/trunk/include/nmg.h: Update to file 'nmg.h' to add a pointer to a manifolds list within the nmg 'model' structure. This is necesary to globally track the current manifolds in the nmg model.
20:32.59CIA-28BRL-CAD: 03r_weiss * r47949 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mk.c: Update to file 'nmg_mk.c' modifying functions 'nmg_mm' (nmg make model) and 'nmg_km' (nmg kill model) to support the addition of the 'manifolds' pointer to the model structure.
20:37.23CIA-28BRL-CAD: 03r_weiss * r47950 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c:
20:37.24CIA-28BRL-CAD: Update to file 'nmg_bool.c' function 'nmg_bool'. Moved the execution of function
20:37.24CIA-28BRL-CAD: 'nmg_manifolds' (which creates the manifolds list) from a lower level to
20:37.24CIA-28BRL-CAD: 'nmg_bool' so it is only executed once per boolean operation. Previously is was
20:37.24CIA-28BRL-CAD: executed for every ray that was shot during the classification of the nmg
20:37.24CIA-28BRL-CAD: objects.
20:42.21CIA-28BRL-CAD: 03r_weiss * r47951 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: Updated file 'nmg_rt_isect.c' function 'nmg_class_ray_vs_shell' so that it will use an existing manifold list, if one is available. Also to not free the manifold list if it was not created in this function.
20:45.28CIA-28BRL-CAD: 03r_weiss * r47952 10/brlcad/trunk/src/librt/primitives/nmg/nmg_index.c: Update to file 'nmg_index.c' function 'nmg_merge_models' to support the addition of the 'manifolds' pointer to the model structure. When models are merged, any manifold lists will be invalid so free them.
20:46.26CIA-28BRL-CAD: 03brlcad * r47953 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: NULL for sanity
20:47.22CIA-28BRL-CAD: 03starseeker * r47954 10/brlcad/trunk/doc/ecosystem.dot: graphviz, not docbook
20:53.24CIA-28BRL-CAD: 03brlcad * r47955 10/brlcad/trunk/src/librt/primitives/nmg/nmg.c: rename 'new' variable to 'newdata' so it won't conflict with c++ compilation. also null out our stp->st_specific after releasing it for good measure.
20:57.14CIA-28BRL-CAD: 03brlcad * r47956 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: hitmiss is local data, so no sanity offered by nulling; but rt.manifolds is misleading as the actual pointer is in rd.rd_m that we want to free and unset.
21:21.06CIA-28BRL-CAD: 03r_weiss * r47957 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: Updated file 'nmg_fuse.c' function 'nmg_ptbl_vfuse' and added function 'x_comp'. Improved the performance of vertex fusing during nmg boolean operations. The new function 'x_comp' supports the 'nmg_ptbl_vfuse' function.
21:55.09CIA-28BRL-CAD: 03brlcad * r47958 10/brlcad/trunk/src/libbu/ (11 files): _bu_ prefix on statics was a bad idea. use filename/group as prefix instead. in most cases, simplifies names and improves readability.
21:59.33CIA-28BRL-CAD: 03brlcad * r47959 10/brlcad/trunk/src/libbu/ (hist.c log.c malloc.c parallel.c tcl.c): remove _ B U _ from comments too, update names
22:01.21CIA-28BRL-CAD: 03brlcad * r47960 10/brlcad/trunk/src/libbu/ (cmd.c observer.c): these files no longer require tcl.h
22:03.37CIA-28BRL-CAD: 03brlcad * r47961 10/brlcad/trunk/src/libbu/parse.c: parse_tcl_list_length() is not a public function, rename to parse_list_length()
22:20.22CIA-28BRL-CAD: 03brlcad * r47962 10/brlcad/trunk/ (8 files in 6 dirs): renaming bu_shader_to_tcl_list() to bu_shader_to_list() as the function applies to any list in {} form, tcl or otherwise. part of making libbu be entirely tcl-agnostic.
22:37.54CIA-28BRL-CAD: 03brlcad * r47963 10/brlcad/trunk/src/libbu/ (globals.c log.c): bu_log_hook_list doesn't need to be global as accessor functions exist. move it into log.c and make it static.
22:40.34CIA-28BRL-CAD: 03brlcad * r47964 10/brlcad/trunk/src/libbu/log.c: simplify, consistency. rename the static variables sans bu_ prefix since they're not public api.
22:49.06CIA-28BRL-CAD: 03brlcad * r47965 10/brlcad/trunk/ (4 files in 3 dirs):
22:49.06CIA-28BRL-CAD: add a new bu_bomb_add_hook_list() function similar to bu_log_add_hook_list() so
22:49.06CIA-28BRL-CAD: that we can eliminate the bu_bomb_hook_list from global API visibility/use.
22:49.06CIA-28BRL-CAD: since mged is sole use, presently no means to remove or inspect hooks is being
22:49.06CIA-28BRL-CAD: added.
22:56.15CIA-28BRL-CAD: 03brlcad * r47966 10/brlcad/trunk/ (4 files in 2 dirs): rename the hook function callbacks to be consistent with other parts of libbu api using bu_hook_ as the function prefix. minimally impacting change.
22:59.13CIA-28BRL-CAD: 03starseeker * r47967 10/brlcad/trunk/ (5 files in 4 dirs): Group distcheck file ignoring macros, fix a couple distcheck items.
23:03.22CIA-28BRL-CAD: 03starseeker * r47968 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CMakeFiles.cmake): There's no particular reason the subbuild logic or distcheck macros need to be BRL-CAD specific.
23:09.03CIA-28BRL-CAD: 03brlcad * r47969 10/brlcad/trunk/src/libged/wdb_obj.c:
23:09.03CIA-28BRL-CAD: register a bu_log() hook with the wdb command object so we don't get libbu
23:09.03CIA-28BRL-CAD: blather about not finding a valid command. this fixes obtuse misleading output
23:09.03CIA-28BRL-CAD: from g_diff since it unfortunately uses the wdb object interface to get/compare
23:09.03CIA-28BRL-CAD: attributes.
23:10.47CIA-28BRL-CAD: 03starseeker * r47970 10/brlcad/trunk/ (3 files in 2 dirs): Split the option macros into their own file - BRLCAD_Util is too long. Need to organize better.
23:16.50CIA-28BRL-CAD: 03brlcad * r47971 10/brlcad/trunk/src/rt/view.c: fix a structparse crash in rt if you tried to set ambSlow=1. the offset was off-by-one indexing the wrong parse entry so ambSlow's field was never initialized (causing a NULL dereference).
23:29.08CIA-28BRL-CAD: 03starseeker * r47972 10/brlcad/trunk/ (3 files in 2 dirs): Do some more option macro reworking.
23:29.57CIA-28BRL-CAD: 03brlcad * r47973 10/brlcad/trunk/src/libbu/parse.c: prevent a segfault if we encounter an uninitialized bu_structparse table entry. it implies there is an outright bug in that table's entry definition/setup. bomb so we can get a stacktrace to fix it.
IRC log for #brlcad on 20111215

IRC log for #brlcad on 20111215

00:12.59CIA-28BRL-CAD: 03starseeker * r47974 10/brlcad/trunk/ (3 files in 2 dirs): At long last, begin integrating the option documentation mechanism into the 3rd party macro system. This handles only the libraries at the moment, not the executables and tcl/tk packages.
00:28.04CIA-28BRL-CAD: 03starseeker * r47975 10/brlcad/trunk/ (doc/docbook/books/en/CMakeLists.txt misc/CMake/Docbook.cmake): Oops - fix couple of issues that crept into docbook pdf logic.
00:36.47CIA-28BRL-CAD: 03starseeker * r47976 10/brlcad/trunk/doc/docbook/ (CMakeLists.txt ElNode.pm README validate.pl): Perl is no longer needed in doc/docbook. Should test out xslt tools other than xsltproc - if they work, provide example(s) for those too, not just rnv validation tool.
00:39.29CIA-28BRL-CAD: 03starseeker * r47977 10/brlcad/trunk/doc/docbook/README: Call out necessary config options for rnv usage.
03:28.03starseekergrins at the IRC history - now that's a good commit density :-)
03:42.20*** join/#brlcad abhi2011 (~chatzilla@117.200.86.134)
03:52.19CIA-28BRL-CAD: 03starseeker * r47978 10/brlcad/trunk/ (doc/docbook/README misc/CMake/msv.cmake.in): Add an msv example for docbook validation with CMake (the original recommended tool - it just uses java, so not available by default...) also, correct the documentation configuration example.
04:04.48CIA-28BRL-CAD: 03starseeker * r47979 10/brlcad/trunk/ (3 files in 2 dirs): Add documentation and aliases for the third party executables. Last up, the tcl libs...
04:06.11starseekerhmm, I see why msv is recommended...
04:06.25starseekerdoggone it, why do all the best DocBook tools have to be in Java...
04:12.14*** join/#brlcad abhi2011 (~chatzilla@117.200.85.83)
04:46.32CIA-28BRL-CAD: 03Sean 07http://brlcad.org * r3255 10/wiki/User:Abhijit: Reverted edits by [[Special:Contributions/125.62.202.148|125.62.202.148]] ([[User talk:125.62.202.148|Talk]]); changed back to last version by [[User:Abhi2011|Abhi2011]]
04:46.34CIA-28BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:125.62.202.148]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites
04:58.30CIA-28BRL-CAD: 03starseeker * r47980 10/brlcad/trunk/ (misc/CMake/ThirdParty_TCL.cmake src/other/CMakeLists.txt):
04:58.30CIA-28BRL-CAD: Have the THIRD_PARTY_TCL_PACKAGE macro handle the question of what to do when Tk
04:58.30CIA-28BRL-CAD: is required and disabled - we're going to want the option defined regardless so
04:58.30CIA-28BRL-CAD: we get the documentation, once we turn those features on. Still need to rework
04:58.30CIA-28BRL-CAD: the itcl/itk logic so it doesn't have to double-call the macro.
05:48.20brlcadstarseeker: because java is xml-happy
05:50.44brlcadstupid kdc not responding
06:54.13*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
14:23.07starseekerbrlcad: bomb.c:84: warning: implicit declaration of function ‘bu_hook_add’
14:35.35starseekerguessing a bu.h update missed getting committed?
14:40.31CIA-28BRL-CAD: 03d_rossberg * r47981 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: just a thought (probable a typing error)
15:00.31CIA-28BRL-CAD: 03starseeker * r47982 10/brlcad/trunk/ (include/bu.h src/other/CMakeLists.txt): Don't double-call THIRD_PARTY_TCL_PACKAGE - getting set to add documentation to this macro
15:17.05*** join/#brlcad n_reed_ (~molto_cre@BZ.BZFLAG.BZ)
15:23.36CIA-28BRL-CAD: 03starseeker * r47983 10/brlcad/trunk/include/bu.h: Whoops, didn't mean to commit that - wait for Sean's solution.
15:36.18brlcadstarseeker: yeah, sorry -- fixing
15:37.00brlcadwas working on a bu bug late into last night
15:49.42CIA-28BRL-CAD: 03brlcad * r47984 10/brlcad/trunk/include/bu.h: update the bu_hook_* decls
16:05.27CIA-28BRL-CAD: 03brlcad * r47985 10/brlcad/trunk/src/libbu/backtrace.c: waiting for 60 seconds for a debugger to attach seems a little too long. needs to be just long enough to run top/ps and gdb --attach. reduce wait to 45 seconds.
17:15.09CIA-28BRL-CAD: 03r_weiss * r47986 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: Updated functions 'nmg_two_face_fuse', 'nmg_model_face_fuse' and 'nmg_edge_g_fuse' in file 'nmg_fuse.c'. Removed magic checks reducing performance. Also simplified/changed logic to improve performance.
17:18.04CIA-28BRL-CAD: 03r_weiss * r47987 10/brlcad/trunk/src/librt/primitives/nmg/nmg_extrude.c: Updated function 'nmg_find_vertex_in_lu' in file 'nmg_extrude.c'. Removed magic checks reducing performance. Changed 'eu' to a register variable.
17:22.27CIA-28BRL-CAD: 03r_weiss * r47988 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c:
17:22.28CIA-28BRL-CAD: Updated functions 'nmg_bool' and 'nmg_kill_anti_loops' in file 'nmg_bool.c'.
17:22.28CIA-28BRL-CAD: Removed magic checks reducing performance. Removed the input parameter 'tol'
17:22.28CIA-28BRL-CAD: from function 'nmg_kill_anti_loops' since it was unused. Changed many variable
17:22.29CIA-28BRL-CAD: to register variables in function 'nmg_kill_anti_loops'.
17:26.27CIA-28BRL-CAD: 03r_weiss * r47989 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: Updated function 'nmg_shell_coplanar_face_merge' in file 'nmg_mod.c'. Removed magic tests which were reducing performance. Modified logic to improve performance. Did code cleanup.
18:29.11*** join/#brlcad dli (~dli@66.49.253.83)
18:29.36dli7.20.4 building error: ld: ../../lib/librttherm.a(main.c.o): undefined reference to symbol 'fb_open'
18:38.58brlcaddli: I believe that is already fixed
18:39.13brlcaddli: can you try an svn checkout build to confirm?
18:39.25dlibrlcad, one moment
18:46.47CIA-28BRL-CAD: 03n_reed * r47990 10/brlcad/trunk/src/other/perplex/scanner_template.c: need to provide default macro definition
18:51.30CIA-28BRL-CAD: 03brlcad * r47991 10/brlcad/trunk/src/librt/constraint.c: BU_VLS_IS_INITIALIZED() is evil, avoid. don't need the structparse table to be public too.
18:53.25CIA-28BRL-CAD: 03starseeker * r47992 10/brlcad/trunk/misc/CMake/FindPERPLEX.cmake: Make a stab at macros for perplex targets
18:55.58CIA-28BRL-CAD: 03brlcad * r47993 10/brlcad/trunk/src/libwdb/constraint.c: always init the vls
19:01.43CIA-28BRL-CAD: 03brlcad * r47994 10/brlcad/trunk/src/rt/reshoot.c: always initialize vls members
19:03.13CIA-28BRL-CAD: 03brlcad * r47995 10/brlcad/trunk/src/rt/viewedge.c: always init bu_vls, especially if they're going to be used in a structparse table.
19:06.52CIA-28BRL-CAD: 03brlcad * r47996 10/brlcad/trunk/src/ (11 files in 3 dirs): (log message trimmed)
19:06.52CIA-28BRL-CAD: structparse refactoring to fix a couple long outstanding issues. structparse
19:06.52CIA-28BRL-CAD: tables chained together via %p no longer stash the address in sp_count, instead
19:06.52CIA-28BRL-CAD: using sp_offset just like everything else. update all callers accordingly.
19:06.52CIA-28BRL-CAD: also, update the %V bu_vls handlers to not do their own thing merely because
19:06.52CIA-28BRL-CAD: callers weren't initializing their vls before calling a structparse function.
19:06.53CIA-28BRL-CAD: require init and make all callers initialize beforehand (e.g., via
19:26.33CIA-28BRL-CAD: 03starseeker * r47997 10/brlcad/trunk/ (misc/CMake/ThirdParty_TCL.cmake src/other/CMakeLists.txt): Make the 'don't build this tcl/tk extension because of X mechanism a bit more general. Also, try to handle Togl a bit more like the other Tcl/Tk packages.
19:30.21dlierror: variable ‘m’ set but not used [-Werror=unused-but-set-variable]
19:30.32dli-DBRLCAD-ENABLE_STRICT=OFF
19:30.55brlcadneed the line preceeding
19:31.24brlcaddli: also, all of the BRLCAD- variables are now uniformly BRLCAD_
19:31.59dlibrlcad, so, -DBRLCAD_ENABLE_STRICT=OFF
19:32.08brlcadyep
19:33.02brlcadthough getting a list of those error/warnings is useful too .. should be clean and passing with strict enabled
19:33.57brlcadbeen compiling with the very latest gcc, so anything that comes up should be very recent issue in the last day or so
19:36.54dlibrlcad, also, building fails with "g++ -std=c++0x ", I suppose it should be c++11 compatible eventually
19:57.10CIA-28BRL-CAD: 03starseeker * r47998 10/brlcad/trunk/ (misc/CMake/ThirdParty_TCL.cmake src/other/CMakeLists.txt):
19:57.10CIA-28BRL-CAD: Add documentation and aliases for Tcl/Tk packages. Most of the way there
19:57.10CIA-28BRL-CAD: (although the documentation blurbs undoubtedly need work) - remaining issues are
19:57.10CIA-28BRL-CAD: options that can be completely conditionalized away (termlib, scl) - need to
19:57.10CIA-28BRL-CAD: make sure the options are called to generate the doc strings, may need to extend
19:57.11CIA-28BRL-CAD: the 'required vars' mechanism in used for Tcl/Tk packages to THIRD_PARTY itself.
20:09.28CIA-28BRL-CAD: 03starseeker * r47999 10/brlcad/trunk/ (misc/CMake/ThirdParty.cmake src/other/CMakeLists.txt): add the required vars mechanism to THIRD_PARTY, update src/other/CMakeLists.txt
20:16.45CIA-28BRL-CAD: 03brlcad * r48000 10/brlcad/trunk/src/librt/columnparse.c: looks like struct attr_obj isn't used anywhere, so get rid of it. convert to BU_VLS_INIT_ZERO
21:05.39CIA-28BRL-CAD: 03starseeker * r48001 10/brlcad/trunk/ (CMakeLists.txt INSTALL.cmake): (log message trimmed)
21:05.40CIA-28BRL-CAD: And now, the final piece of the configuration options documentation.
21:05.40CIA-28BRL-CAD: Automatically update the INSTALL file (currently pulling INSTALL.cmake, but that
21:05.40CIA-28BRL-CAD: will change later) with changes in BRL-CAD options and aliases. In keeping with
21:05.40CIA-28BRL-CAD: the principle of not touching the source directory the original INSTALL file is
21:05.40CIA-28BRL-CAD: not altered - instead, a new file is generated (INSTALL.new) and a warning is
21:05.40CIA-28BRL-CAD: printed at the end of the configure process notifying the developer of the
21:07.55starseekerheh 48000
21:07.57starseekernice
21:09.33brlcaddli: failing with a c++ compiler is known, regardless of c++0x
21:10.10brlcadthere is a to-do item to attempt to get a complete build with g++-only, but nobody has tackled it in a long time
21:16.27CIA-28BRL-CAD: 03brlcad * r48002 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: looks like 'm'odel is set but not used, so eliminate it. presumes nmg_find_model() has no side effects
21:16.58brlcadthat should fix that earlier strict warning
21:36.28CIA-28BRL-CAD: 03brlcad * r48003 10/brlcad/trunk/src/ (113 files in 36 dirs):
21:36.28CIA-28BRL-CAD: conversion from bu_vls_init() to BU_VLS_INIT_ZERO initialization. this
21:36.28CIA-28BRL-CAD: performance tune avoids a function call and memory allocation if the string is
21:36.28CIA-28BRL-CAD: never used but, more importantly, simplifies the code and makes it less
21:36.28CIA-28BRL-CAD: error-prone in the situations where we only conditionally initialized or
21:36.29CIA-28BRL-CAD: initialized much later in the logic. this commit covers approximately 45% of
21:36.37CIA-28BRL-CAD: the bu_vls_init() calls. woot: +366 -718.
22:19.24*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
22:50.27CIA-28BRL-CAD: 03starseeker * r48004 10/brlcad/trunk/CMakeLists.txt: Print the summary unless told not to - let a parent build turn it off if it doesn't want it, but the default is on.
23:22.47CIA-28BRL-CAD: 03starseeker * r48005 10/brlcad/trunk/HACKING.cmake: Sync HACKING.cmake with HACKING, make a few updates.
IRC log for #brlcad on 20111216

IRC log for #brlcad on 20111216

00:08.46CIA-28BRL-CAD: 03starseeker * r48006 10/brlcad/trunk/CMakeLists.txt: Need to do the 32/64 bit check earlier in the game, before we try to find anything at all.
00:09.41CIA-28BRL-CAD: 03n_reed * r48007 10/brlcad/trunk/src/other/perplex/ (scanner.re scanner_template.c): Comparing disparate pointers is undefined. Don't do it.
00:37.42CIA-28BRL-CAD: 03n_reed * r48008 10/brlcad/trunk/src/other/perplex/ (scanner.re scanner_template.c): need to update input markers if input buffer is reallocated
01:55.12CIA-28BRL-CAD: 03starseeker * r48009 10/brlcad/trunk/ (10 files in 2 dirs): Slew of documentation updates. Not claiming final form yet, but closer.
02:07.49CIA-28BRL-CAD: 03starseeker * r48010 10/brlcad/trunk/doc/README.Windows: Start reworking the Windows docs for CMake.
02:13.23CIA-28BRL-CAD: 03starseeker * r48011 10/brlcad/trunk/ (8 files): Move the CMake versions of doc files into place.
02:19.18dlisvn version building error: http://pastebin.com/HUC6ibBc
02:23.58CIA-28BRL-CAD: 03starseeker * r48012 10/brlcad/trunk/ (INSTALL src/other/CMakeLists.txt): Copy/paste strikes again
02:33.51CIA-28BRL-CAD: 03starseeker * r48013 10/brlcad/trunk/configure.cmake.sh: Add a bunch more of the options to the configure script. Looking more like it will be possible to simply autogenerate the verbose part of this. Also points out there are a few toplevel options that still need docs.
02:34.39starseekerdli: can you paste it using the mozilla pastebin?
02:34.52dlistarseeker, ok
02:35.40dlistarseeker, http://pastebin.mozilla.org/1407174
02:39.59starseekerum... not sure what's going on - I just got a clean build from latest trunk here...  what were your configure options?
02:41.58dlistarseeker, one moment
02:45.05dlistarseeker, http://pastebin.mozilla.org/1407179
02:45.58dlistarseeker, reported from cmake: http://pastebin.mozilla.org/1407180
02:46.34starseekerholy bleep
02:46.43starseekerare you building it as part of a packaging system?
02:46.56dlistarseeker, yes, in gentoo
02:46.59starseekeroh, I see gentoo
02:47.21starseekerwell, for one thing, a lot of the options are incorrect for trunk
02:48.23starseekerand they shouldn't be trying to turn off scl or utahrle, unless they've got ebuilds of our own src/other srcs
02:48.39starseekerdli: where did you get that ebuild from?
02:48.43starseekeris that an overlay?
02:48.48dlistarseeker, yes
02:48.53starseekerwhich one?
02:49.06dlistarseeker, science-overlay
02:49.50starseekerhmm.  I'd have to take a look, but it looks like someone either isn't maintaining that ebuild or isn't paying close enough attention
02:50.09dlistarseeker, very old ebuilds
02:54.30starseekeryeah, this needs a total overhaul
02:54.36starseekerwho's maintaining it?
02:55.37starseekerhe DISABLED opengl??
02:56.03starseekerand did it wrong to boot - it's -DBRLCAD_ENABLE_OPENGL=OFF, not -BRLCAD_ENABLE_OPENGL=OFF
02:56.06dlistarseeker, I disabled opengl, because builds fails with opengl
02:56.35starseekerO.o - why?
02:57.17starseekerdli: can you do me a favor?  Just grab a trunk checkout and build it "stand-alone" without the ebuild?
02:57.35starseekercmake .. -DBRLCAD_BUNDLED_LIBS=ON and see what happens?
02:57.50dlistarseeker, sure
03:00.17starseekerall the BRLCAD_BUILD_LOCAL variables are obsolete and not doing anything
03:00.49dlistarseeker, reported from cmake: http://pastebin.mozilla.org/1407198
03:00.58starseekerto achieve what it looks like he's after, all he had to do was -DBRLCAD_BUNDLED_LIBS=System , but that doesn't stand a good chance of working...
03:01.18starseekerdli: try building once
03:01.40dlistarseeker, it's building
03:02.25dlistarseeker, /var/tmp/portage/media-gfx/brlcad-9999/work/brlcad-9999/include/sysv.h:61:26: error: conflicting types for ‘strchr’
03:02.58dlistarseeker, that's from cmake  -DBRLCAD_BUNDLED_LIBS=ON .
03:04.58starseekerwhat's the full error?
03:05.10starseekerprevious definition?
03:06.17dlistarseeker, that's all I got: http://pastebin.mozilla.org/1407203
03:06.32starseekeralso, you're still using the gentoo brlcad-9999 sources?
03:07.41dlistarseeker, should not be, I run cmake in the source folder, gentoo builds it in a different folder
03:07.56dlistarseeker, I can try to copy the source and try again
03:09.20starseekerdli: I'd suggest starting totally clean, if you can
03:09.34dlistarseeker, no problem
03:10.09starseekerin your home directory: svn co https://brlcad.svn.sf.net/svnroot/brlcad/brlcad/trunk brlcad && mkdir brlcad-build && cd brlcad-build && cmake ../brlcad -DBRLCAD_BUNDLED_LIBS=ON && make
03:10.38starseekerclearly turning off opengl in CMake is causing some... unexpected issues, I'll have to look into it
03:11.59dlistarseeker, trying again
03:17.49dlistarseeker, better, that error doesn't show up
03:19.07CIA-28BRL-CAD: 03starseeker * r48014 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: Correct a few gross errors in ThirdParty.cmake, but still not clear how disabling opengl is messing with everything.
03:19.41starseekerI gotta go - dli, post how that turns out.  Clearly I've got a bug to fix, but that ebuild is hopelessly out of date
03:20.03dlistarseeker, ok
04:43.57CIA-28BRL-CAD: 03starseeker * r48015 10/brlcad/trunk/misc/CMake/ (ThirdParty.cmake ThirdParty_TCL.cmake): Er, right, macros. Reset a conditional variable before using it again...
05:01.34starseekerdli: did it build?
05:03.12dlistarseeker, it builds in a fresh folder
05:03.25dlistarseeker, but still couldn't get it build in ebuild
05:05.30starseekerthat ebuild's settings are way too aggressive
06:11.59CIA-28BRL-CAD: 03starseeker * r48016 10/brlcad/trunk/ (3 files in 3 dirs):
06:12.01CIA-28BRL-CAD: Do more work to make BRLCAD_BUNDLED_LIBS=System do what it claims to do. Also
06:12.01CIA-28BRL-CAD: make Tcl packages respect it, unless BRLCAD_TCL is overridden locally - then
06:12.01CIA-28BRL-CAD: respect the local Tcl setting rather than BUNDLED_LIBS. Still needs some
06:12.01CIA-28BRL-CAD: testing - not a terribly useful setting for us, but the Linux distributions will
06:12.01CIA-28BRL-CAD: probably want it so we should shake it out and make it behave.
06:12.40CIA-28BRL-CAD: 03starseeker * r48017 10/brlcad/trunk/INSTALL: Doing Tk as a Tcl extension, so docs are generated for it - add 'em.
06:48.24*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
10:33.02*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
11:54.46*** join/#brlcad ``Erik (~erik@BRLCAD.ORG)
14:12.25*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
16:22.42CIA-28BRL-CAD: 03starseeker * r48018 10/brlcad/trunk/src/other/CMakeLists.txt: Needing the C library from a Tcl/Tk package is compilcating things... however, a bit of a pattern is emerging...
16:27.11dlistarseeker, I updated ebuilds in gentoo science overlay. Noticed building failures due to: LDFLAGS "--as-needed", BRLCAD_ENABLE_RTSERVER=ON, and CXXFLAGS="-std=c++0x"
16:32.28starseekerhmm.  yeah, rtserver's build can be a bit finicky
16:32.44starseekerthat's the java bit - I doubt most people would miss it
16:33.11starseekerhehe - this is awesome:
16:33.23starseeker'"Computer scientists" don't write code, they write books explaining why all existing implementations are wrong.'
16:34.58dlistarseeker, still, gentoo wants features be specified by USE flags, not but auto-detection, so, it's not encouraged to use BRLCAD_BUNDLED_LIBS=AUTO
16:42.23starseekerdli: yeah, I know - one of the longer active bugs in the history of the gentoo bug database was the "here's a BRL-CAD ebuild" discussion arguing about things like autodetection and default installation location
16:43.11dlistarseeker, default location settled down to /usr/brlcad/, iirc
16:43.16starseekerThe commits last night were working to fix the "System" setting for BRLCAD_BUNDLED_LIBS.  That's what distributions *should* set in the future if they don't want any of our bundled libs
16:44.04starseekerIt will still annoy them because System won't disable opennurbs, scl, and one or two other src/other libraries
16:44.32starseekerthe reason for that, however, is those are *locally modified* copies - a system version, at least at the moment, would not be expected to work correctly
16:45.39starseekerwe *could* stick those local "forks" into our own source tree and avoid the issue, but the point/hope is to eventually establish those as separate projects - progress is already being made in that regard with scl
16:46.10starseekersrc/other libraries and tools tend to have more uses than just BRL-CAD, so there is a reasonable hope they will attract other interest
16:46.47starseekerthe odds of that go up if it's easy to build the library "in isolation"
16:47.38starseekerso we maintain our build system in such a way that those libraries are seaprate projects, even though we're the only users/source for those particular versions
16:47.51starseekers/seaprate/separate/g
16:50.28starseekerscl (the Step Class Libraries) is showing activity on a github project, and once we get things to the point where their build and auto-generated output work for us and support our step-g convertor, we'll be able to use a hypothetical system SCL install
16:51.10dlistarseeker, setting to System fails with svn: http://pastebin.mozilla.org/1408136
16:51.54starseekerdli: do you have itcl and itk installed?
16:52.38dlistarseeker, yes: Installed versions:  3.4_beta1, Installed versions:  3.4_pre20090417-r1
16:53.05starseekerwhere is libitcl located?
16:53.11starseekerand libitk?
16:53.39dlistarseeker, /usr/lib64/itcl3.4/libitcl3.4.so
16:53.53dli/usr/lib64/itk3.4/libitk3.4.so
16:54.23starseekeralright... let me see if I can tell why the find_library calls aren't seeing those
16:56.13starseekeroh, by the way - unless gentoo's lemon package puts lempar.c in /usr/bin/, lemon isn't going to work
16:59.45CIA-28BRL-CAD: 03starseeker * r48019 10/brlcad/trunk/src/other/CMakeLists.txt: We need the ITCL version set for find_library... since we aren't testing for it when we're going whole-hog system, set it to 3.4 if it's not defined.
17:00.44starseekerneed to think about that one... ideally, even if we're forcing system we'd still want the version installed if there is one...
17:01.10starseekerjeez, this business of using Tcl/Tk package C libraries is a nightmare
17:07.58starseekeractually, gentoo doesn't even have its own lemon package - must be part of sqlite
17:09.33starseekeraaand the installed one doesn't like something
17:09.39starseekereven with lempar.c present
17:14.31starseekerdli: you have re2c installed?
17:14.52starseekerdev-util/re2c-0.13.5 is what I've got here...
17:15.03dlistarseeker, yes,  Installed versions:  0.13.5
17:15.07starseekerok
17:15.24starseekerthat looks like it should work, but the system lemon is a disaster
17:15.35starseekerit's not even versioned on its own
17:16.21starseekerand I can't stick lempar.c in /usr/bin even if this version HAD worked... talk about your sandbox violations
17:16.47starseekerperplex is written by one of our own developers to wrap re2c, so there won't be a package for that one
17:16.51starseekerone sec...
17:19.25CIA-28BRL-CAD: 03starseeker * r48020 10/brlcad/trunk/ (misc/CMake/ThirdParty.cmake src/other/CMakeLists.txt): (log message trimmed)
17:19.25CIA-28BRL-CAD: Extend the NOSYS mechanism to tools as well. Perplex is our own tool, so even a
17:19.25CIA-28BRL-CAD: SYSTEM install isn't going to have it available (it's our own code, just being
17:19.25CIA-28BRL-CAD: treated as a separate project) and trying to use a system version of lemon is...
17:19.25CIA-28BRL-CAD: problematic, to say the very least. lempar.c isn't likely to be present, and
17:19.25CIA-28BRL-CAD: even when our copy is placed in /usr/bin problems occurred. lemon isn't
17:19.25CIA-28BRL-CAD: packaged by itself, so it's hard to know what to do about that... suggest
17:22.06CIA-28BRL-CAD: 03starseeker * r48021 10/brlcad/trunk/src/libged/simulate/simrt.c: shadowed variable warning...
17:29.48*** join/#brlcad Elrohir (~kvirc@p579F0159.dip.t-dialin.net)
17:33.32dlistarseeker, it works now, with System
17:34.08starseekerThere's a lemon ebuild in an overlay:  http://gpo.zugaina.org/dev-util/lemon/euscan
17:37.55CIA-28BRL-CAD: 03n_reed * r48022 10/brlcad/trunk/src/other/perplex/ (scanner.re scanner_template.c): cleanup
17:38.09starseekerthat DOES work, if I re-work the FindLEMON logic a bit
17:38.25starseekerhttp://gentoo-overlays.zugaina.org/gentoo-zh/portage/dev-util/lemon/
17:38.49starseekerthat would be a good one to advocate for in the main gentoo trunk, to help a system BRL-CAD build work
17:39.06starseekerhe's patched lemon so the template file can live in /usr/share
17:52.49CIA-28BRL-CAD: 03starseeker * r48023 10/brlcad/trunk/ (misc/CMake/FindLEMON.cmake src/other/CMakeLists.txt): Redo the handling of lemon a bit, since there does exist at least one working path for a viable system lemon installation.
17:54.18starseekerhah - there's a redhat package too, that apparently does the same thing
17:54.20starseekersweet
17:54.28starseekerhttp://rpm.pbone.net/index.php3/stat/4/idpl/15156214/dir/redhat_el_5/com/lemon-3.6.20-1.el5.i386.rpm.html
18:00.11starseekerand it looks like FreeBSD does something sane
18:00.18starseekerlooks like Gentoo is behind the curve
18:00.24starseekerembarassing on a dev tool
18:03.18CIA-28BRL-CAD: 03starseeker * r48024 10/brlcad/trunk/src/other/CMakeLists.txt: Rework explanatory text for lemon
18:04.51starseekerdli: it should still work with Gentoo, but you'll probably need that overlay ebuild install of lemon
18:05.04starseekeror specify -DBRLCAD_LEMON=Bundled
18:09.28starseekerand there's no tkhtml ebuild that I can see, so out of the box archer won't work...
18:18.25CIA-28BRL-CAD: 03starseeker * r48025 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: Add a note about another refactor needed to allow local enabling - right now can't set SYSTEM and then turn on just Tkhtml
19:39.56CIA-28BRL-CAD: 03bob1961 * r48026 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Allow empty polygons.
19:45.46CIA-28BRL-CAD: 03bob1961 * r48027 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Add callbacks for polygon creation.
21:50.30CIA-28BRL-CAD: 03n_reed * r48028 10/brlcad/trunk/misc/CMake/FindPERPLEX.cmake: Corrected perplex and re2c options. Basing re2c intermediate name on output name, not output path.
22:46.09CIA-28BRL-CAD: 03n_reed * r48029 10/brlcad/trunk/src/libgcv/wfobj/tri_face.c: s/BU_GET/bu_pool_get/ so that freeing with standard nmg routines doesn't cause bomb.
IRC log for #brlcad on 20111217

IRC log for #brlcad on 20111217

00:06.22CIA-28BRL-CAD: 03starseeker * r48030 10/brlcad/trunk/misc/CMake/FindPERPLEX.cmake: remove FindPERPLEX template logic - as an integral part of BRL-CAD we don't need it, and if it becomes more general later we can plug in a variation of the updated TEMPLATE variable setting just added to FindLEMON.
00:26.53CIA-28BRL-CAD: 03n_reed * r48031 10/brlcad/trunk/src/libgcv/wfobj/tri_face.c: Use the NMG macros instead of bu_pool_get. NMG memory scheme may change, but allocation macros should always be compatible with nmg_k* routines.
05:32.25CIA-28BRL-CAD: 03starseeker * r48032 10/brlcad/trunk/misc/CMake/ (ThirdParty_TCL2.cmake tcltest.tcl.in): Checkpoint a work-in-progress rewrite of the Tcl 3rd party extension macro. Not working yet, but far enough along I'd hate to lose it so get what is written into the tree.
05:37.28CIA-28BRL-CAD: 03starseeker * r48033 10/brlcad/trunk/src/other/ (re2c/CMake/FindLEMON.cmake step/CMake/FindLEMON.cmake): Update the other FindLEMON files
08:03.21*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
18:34.05CIA-28BRL-CAD: 03Watchmoviesonlinestream 07http://brlcad.org * r3256 10/wiki/User:Watchmoviesonlinestream: New page: This is a review on the movie Sherlock Holmes: A Game of Shadows. The sequel to 2009's "Sherlock Holmes" carries the subtitle "A Game of Shadows." What that means, exactly, is anyone's ...
18:34.12CIA-28BRL-CAD: 03Watchmoviesonlinestream 07http://brlcad.org * r3257 10/wiki/User:Watchmoviesonlinestream:
19:00.44*** join/#brlcad ``Erik_ (erik@c-69-140-109-104.hsd1.md.comcast.net)
20:53.08CIA-28BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:Watchmoviesonlinestream]]": Spamming content
20:55.58CIA-28BRL-CAD: 03Starseeker 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Watchmoviesonlinestream]] with an expiry time of infinite (account creation disabled): Inserting nonsense/gibberish into pages
IRC log for #brlcad on 20111218

IRC log for #brlcad on 20111218

03:49.53*** join/#brlcad louipc (~louipc@archlinux/fellow/louipc)
05:26.55CIA-28BRL-CAD: 03starseeker * r48034 10/brlcad/trunk/misc/CMake/BRLCAD_Options.cmake: Add a disabled option to BUNDLED_OPTIONS
05:53.55*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:07.14*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
15:21.34``Erikel chalupacabra strikes again :/
17:20.35starseekerpokes CIA
17:21.47starseekercrosses fingers - hopefully that'll solve the Tcl/Tk system package issues
17:21.54starseeker(phew)
19:39.38*** join/#brlcad merzo (~merzo@50-178-133-95.pool.ukrtel.net)
23:52.54CIA-28BRL-CAD: 03starseeker * r48035 10/brlcad/trunk/misc/CMake/ThirdParty_TCL2.cmake: More work on the Tcl/Tk 3rd party macro rewrite
IRC log for #brlcad on 20111219

IRC log for #brlcad on 20111219

00:01.03CIA-28BRL-CAD: 03starseeker * r48036 10/brlcad/trunk/ (5 files in 3 dirs):
00:01.04CIA-28BRL-CAD: Swap in the new Tcl macro system. Needs debugging, but this will hopefully be a
00:01.04CIA-28BRL-CAD: more organized framework within which to find the bugs. Also added one
00:01.04CIA-28BRL-CAD: additional feature to the summary - if a component is disabled that is to be
00:01.04CIA-28BRL-CAD: reported in the summary, and a system version was NOT found, put an exclamation
00:01.04CIA-28BRL-CAD: point after the OFF to indicate potential trouble.
00:21.13CIA-28BRL-CAD: 03tbrowder2 * r48037 10/brlcad/trunk/src/libged/tables.c: correcting type coercion on matrices fixes bug 3392558 (soilds and regions commands cause core dump)
00:24.22CIA-28BRL-CAD: 03tbrowder2 * r48038 10/brlcad/trunk/src/libged/tables.c: fixed some ws formatting
03:33.44CIA-28BRL-CAD: 03starseeker * r48039 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: try a little harder to reset the library variable for proper searching. also ended up reindenting.
03:39.07CIA-28BRL-CAD: 03starseeker * r48040 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: Stray debug print statement
03:47.53CIA-28BRL-CAD: 03starseeker * r48041 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: tweak for generic ThirdParty macro to fix handling of cached build targets...
03:55.18starseekeralmost there...
07:29.26*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:32.35*** join/#brlcad piksi (piksi@pi-xi.net)
09:44.40*** join/#brlcad merzo (~merzo@173-242-132-95.pool.ukrtel.net)
12:23.51*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:52.44*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
12:58.22*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
12:58.35*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
13:00.08*** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ)
16:05.28*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
16:32.18CIA-28BRL-CAD: 03n_reed * r48042 10/brlcad/trunk/src/other/perplex/ (scanner.re scanner_template.c): add missing malloc casts
16:41.45CIA-28BRL-CAD: 03n_reed * r48043 10/brlcad/trunk/src/other/perplex/ (scanner.re scanner_template.c): need array notation to quell const char warning
16:51.28CIA-28BRL-CAD: 03n_reed * r48044 10/brlcad/trunk/src/other/perplex/scanner_template.c: typo
17:13.41brlcadshould make the fmt strings const too n_reed_
17:47.30CIA-28BRL-CAD: 03tbrowder2 * r48045 10/brlcad/trunk/doc/docbook/presentations/en/intro-to-tcltk.xml: correct error in result of 'lindex' command; amplify lead-in text
17:48.57CIA-28BRL-CAD: 03n_reed * r48046 10/brlcad/trunk/src/other/perplex/ (scanner.re scanner_template.c): more type corrections
17:49.37CIA-28BRL-CAD: 03r_weiss * r48047 10/brlcad/trunk/src/librt/primitives/nmg/nmg_rt_isect.c: Updated function 'nmg_class_ray_vs_shell' in file 'nmg_rt_isect.c'. Corrected a bug with the manifolds creating and freeing. Added some comments.
17:55.23CIA-28BRL-CAD: 03r_weiss * r48048 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mod.c: Updated function 'nmg_gluefaces' in file 'nmg_mod.c'. Removed magic checks to improve performance. Changed a variable to a register variable to improve performance.
17:58.27CIA-28BRL-CAD: 03r_weiss * r48049 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c:
17:58.27CIA-28BRL-CAD: Rewrote function 'nmg_model_edge_fuse' and added function 'v_ptr_comp' to file
17:58.27CIA-28BRL-CAD: 'nmg_fuse.c'. These changes were to improve the performance of edge fusing for
17:58.27CIA-28BRL-CAD: nmg objects. This change reduces the time to perform nmg boolean operations.
18:51.15CIA-28BRL-CAD: 03r_weiss * r48050 10/brlcad/trunk/src/librt/primitives/nmg/nmg_mesh.c: Updated function 'nmg_mesh_two_faces' in file 'nmg_mesh.c'. Removed magic tests to improve performance.
19:47.17CIA-28BRL-CAD: 03brlcad * r48051 10/brlcad/trunk/src/libgcv/wfobj/obj_rules.re: looks like the memset parameters are transposed. was setting 0 bytes.
20:13.13CIA-28BRL-CAD: 03brlcad * r48052 10/brlcad/trunk/src/librt/comb/comb.c: increase buffer to 1024 to minimize risk of (bogus or valid) user-input encountering the limit. don't perform an isupper() test .. tolower() already has to.
20:21.39CIA-28BRL-CAD: 03brlcad * r48053 10/brlcad/trunk/src/librt/ (comb/comb.c db_tree.c search.c vlist.c): 'new' is a terrible non-descript name for a variable and causes compilation problems for c++ compilers. rename.
22:55.50CIA-28BRL-CAD: 03r_weiss * r48054 10/brlcad/trunk/src/librt/primitives/nmg/nmg_fuse.c: Updated function 'nmg_break_all_es_on_v' in file 'nmg_fuse.c'. Removed unnecessary logic and removed magic checks. These changes were to improve performance.
22:57.55CIA-28BRL-CAD: 03r_weiss * r48055 10/brlcad/trunk/src/librt/primitives/nmg/nmg_inter.c:
22:57.56CIA-28BRL-CAD: Updated functions 'nmg_isect_two_face2p_jra' and 'nmg_isect_eu_fu' in file
22:57.56CIA-28BRL-CAD: 'nmg_inter.c'. Reduced the number of edges to process when calling the function
22:57.56CIA-28BRL-CAD: 'nmg_break_all_es_on_v'. These changes were to improve performance.
23:01.22CIA-28BRL-CAD: 03n_reed * r48056 10/brlcad/trunk/src/other/perplex/ (perplex.cpp scanner.re): remove debug output
23:10.32CIA-28BRL-CAD: 03r_weiss * r48057 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c:
23:10.32CIA-28BRL-CAD: Updated function 'nmg_triangulate_rm_degen_loopuse' in file 'nmg_tri.c'. Changed
23:10.32CIA-28BRL-CAD: the logic for the status messages so that debug must be enabled for the messages
23:10.32CIA-28BRL-CAD: to be displayed. The reason is the messages are not useful to the user and
23:10.32CIA-28BRL-CAD: clutter the display during triangulation of nmg objects.
23:11.49CIA-28BRL-CAD: 03n_reed * r48058 10/brlcad/trunk/src/libgcv/wfobj/ (10 files): replaced obj re2c scanner with perplex scanner
23:27.39CIA-28BRL-CAD: 03starseeker * r48059 10/brlcad/trunk/ (16 files in 6 dirs): Rework the non-tcl 3rd party logic as well. Split the build target macros for code generators into their own files, so we don't have to load the Find*.cmake files in all situations.
23:34.34CIA-28BRL-CAD: 03starseeker * r48060 10/brlcad/trunk/INSTALL: Add tweak to documentation string.
23:37.54starseekern_reed_: sweet!
23:54.57CIA-28BRL-CAD: 03brlcad * r48061 10/brlcad/trunk/src/libbu/str.c: file name changed
23:56.53CIA-28BRL-CAD: 03starseeker * r48062 10/brlcad/trunk/src/librt/db_tree.c: Um... why are we bu_bombing when we call this? asc2g isn't happy when building the db targets...
IRC log for #brlcad on 20111220

IRC log for #brlcad on 20111220

00:15.25CIA-28BRL-CAD: 03starseeker * r48063 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: oops - zigging when we need to zag. no turning things on when we have SYSTEM settings.
00:21.17brlcadwhaaa .... when did that file get committed???
00:21.36brlcadah, r48053
00:34.59CIA-28BRL-CAD: 03starseeker * r48064 10/brlcad/trunk/ (misc/CMake/ThirdParty_TCL.cmake src/other/CMakeLists.txt): Few more tweaks for that annoying 'system only even though there's nothing installed on it that I need' case...
00:38.17CIA-28BRL-CAD: 03starseeker * r48065 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: No need to double warn
00:52.51CIA-28BRL-CAD: 03starseeker * r48066 10/brlcad/trunk/misc/CMake/ (ThirdParty.cmake ThirdParty_TCL.cmake): Don't show disabled 3rd party opts, and make sure to show them if they become enabled.
00:56.07CIA-28BRL-CAD: 03starseeker * r48067 10/brlcad/trunk/misc/CMake/xsltproc.cmake.in: Note why it's important to make the directory first when running xsltproc
01:02.51CIA-28BRL-CAD: 03starseeker * r48068 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: Oops - just because we've already added the subdirectory, that doesn't mean we don't need to set the executable variable for the second executable...
01:04.09CIA-28BRL-CAD: 03starseeker * r48069 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: in fact, the exe var setting is only conditional on the build setting.
01:07.18CIA-28BRL-CAD: 03starseeker * r48070 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeI.xml: fix xmllint error
01:07.43starseekerwhat's the LOTR line...
01:07.51starseeker"but that is only a few leaves in a forest"
01:08.27starseekerisn't feeling OCD enough to tackle 'em all right now...
01:09.16starseekerLooks like the on/off behavior of the CMake logic is improved considerably - will have to ask dli to give it a go when comes back
02:15.43CIA-28BRL-CAD: 03starseeker * r48071 10/brlcad/trunk/ (8 files in 2 dirs): Woo hoo! autogenerate the guts of the configure rosetta script right along with the docs.
02:17.05starseeker"I object to doing things that computers can do." - Olin Shivers
04:33.01CIA-28BRL-CAD: 03starseeker * r48072 10/brlcad/trunk/src/tclscripts/archer/BotUtility.tcl: use bu_brlcad_root to find libbu.<whatever> - wasn't working from build directory
04:54.22starseekerholds his breath... do I actually have it fully working now?
08:08.13*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:00.36starseekerhmm http://pastebin.mozilla.org/1413600
13:01.29starseekerclang 2.9
13:01.36starseekertries 3.0
13:44.55starseeker/src/libbu/simd.c:33:5: error: extension used [-Werror,-pedantic,-Wlanguage-extension-token] asm volatile("cpuid":"=b"(b),"=c"(c),"=d"(d):"a"(0x1)); ^
13:45.11starseekerapparently asm isn't standard ANSI C?
13:54.32starseekerwell... it builds a working archer with the strict flag off at least
14:28.32brlcadlooks like a valid bug it detected with the [Z] indexing past the end of the array
14:30.22brlcadasm isn't ansi, it's gcc
14:30.35brlcadcould try changing it to __asm__ which gcc also supports
14:32.06brlcadotherwise, that logic can have another strict define added to keep clang from entering
14:32.44brlcadyeah, from clang manual: The parser recognizes "asm" and "typeof" as keywords in gnu* modes; the variants "__asm__" and "__typeof__" are recognized in all modes
14:32.53brlcadso it might not consider it an extension as __
14:33.03``Erikor break the func out to a .s file (which is probably the strict ansi permissible approach, but not exactly portable)
14:47.48*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
14:48.06starseeker``Erik: why is that not portable?
14:48.29starseeker(sure you're right, just wondering what the reasons would be)
14:52.16``Erika unix system will expect an at&t format .s file, windows will expect an intel format .asm file
14:52.35``Eriklinux will depend on whether you're using nasm or gas or yasm or ...
14:52.51starseekerah - so embedding it in C code lets the C compiler translate it?
14:53.17``Eriknah, but it lets the precompiler choose the code path
14:53.53``Erikhm, I thought I put the winderz one in simd.c, guess I only did *nix
14:53.58``Erik(gcc specific, even)
14:55.06starseekerso we'd have to conditionalize in CMake, looks like:  http://www.cmake.org/Wiki/CMake/Assembler
14:55.33starseekerdoable
14:55.42``Erikand maintain parallel versions, unfortunately... I believe bullet has cross platform detection, so if that becomes a core part, we can let them handle that detail
14:57.56starseeker``Erik: iirc, wasn't the simd stuff in bullet nicely contained in its own little bit of code?
14:59.12starseekerah, right
14:59.16starseekerhttp://bullet.svn.sourceforge.net/viewvc/bullet/trunk/Extras/simdmathlibrary/
15:00.24starseekerany reason not to just use that?
15:01.30starseekerbemusedly notes we could just use that instead of looking for the "m" library, assuming it actually supported all the platforms we're interested in...
15:01.42starseeker"a SIMDized version of the
15:01.44starseeker7 C99 standard math library (libm)"
15:02.04starseeker"a SIMDized version of the C99 standard math library (libm)" rather
15:09.10starseekerah, phooey - looks like it's only for PowerPC and Cell
15:14.16starseekeroh, I see - they've got it in vectormath, I think... http://code.google.com/p/bullet/source/browse/trunk/src/vectormath/
15:22.20starseekerhumph
15:22.49starseekerwhy can't someone just do a straight-up simd-libm under BSD license somewhere...
15:23.49starseekerptview guy has one that looks close, but it's GPL3
15:26.49starseekeroh, here's the bullet overview:  http://bulletphysics.com/ftp/pub/test/physics/demos/Vector_Math_Library-Overview.pdf
15:39.28starseekerah... looks like the benefits of simd manifest more at the higher vector level operations...  could be the libm implementations for those platforms are because they needed 'em there...
15:41.46starseekershakes head - ``Erik, I leave it to you :-)
16:29.08CIA-28BRL-CAD: 03tbrowder2 * r48073 10/brlcad/trunk/src/tclscripts/mged/botedit.tcl: need manual dependency to define BotEditor' this fixes bug number 3392650
16:31.44CIA-28BRL-CAD: 03tbrowder2 * r48075 10/brlcad/trunk/NEWS: shameless credit for two bug fixes
16:31.44CIA-28BRL-CAD: 03tbrowder2 * r48074 10/brlcad/trunk/src/tclscripts/boteditor/botTools.tcl: correct typo in menu
16:56.15CIA-28BRL-CAD: 03starseeker * r48076 10/brlcad/trunk/src/other/step/src/express/expprint.c: Not really sure what's going on with printScope here...
17:31.03brlcadsimd calls for just a few ops is utterly ridiculous
17:31.25brlcadyou get a benefit when you can push your data into the simd pipeline AND KEEP IT THERE
17:31.48brlcadso a low-level simdified-libm isn't really feasible unless you overhaul all math
17:34.07brlcadas for the original elephant in the room, fixing that clang error is trivial and amounts to probably a 1-line tweak to the cpp logic
17:36.07brlcadmoving the asm conditionalization from cppland to cmake wouldn't actually fix anything (and it'd be worse imho)
18:23.15starseekerbrlcad: so Sony probably did it just to have a libm api for those platforms.  Probably why bullet stuck it in extra
18:28.18CIA-28BRL-CAD: 03starseeker * r48077 10/brlcad/trunk/src/libbu/simd.c: asm -> __asm__
18:37.25brlcadthat looks like the right fix :)
18:39.01brlcadstarseeker: I meant feasible for our use -- a libm where your data is already in simd entities wouldn't be a bad idea
18:39.38brlcadheck, even something like gpm using simd under the hood would probably be a (modest) benefit (to us)
18:46.28CIA-28BRL-CAD: 03n_reed * r48078 10/brlcad/trunk/src/other/perplex/scanner.re: fixed patterns that sometimes skipped quote characters, causing bad parsing of quoted text
19:26.11CIA-28BRL-CAD: 03tbrowder2 * r48079 10/brlcad/trunk/regress/mged.sh: add more detailed regression tests for the mged solids and regions commands
19:35.54CIA-28BRL-CAD: 03n_reed * r48080 10/brlcad/trunk/src/other/perplex/scanner.re: need to update scope flag at end of condition scope
20:15.53CIA-28BRL-CAD: 03bob1961 * r48081 10/brlcad/trunk/ (3 files in 3 dirs): Added the ability to move a data object (i.e. line, arrow, polygon) or point. Previously only data points could be moved.
20:59.55CIA-28BRL-CAD: 03erikgreenwald * r48082 10/brlcad/trunk/src/libgcv/test_bottess.c: add some meat
21:13.22*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
21:32.30CIA-28BRL-CAD: 03brlcad * r48083 10/brlcad/trunk/src/libbu/str.c: mark a few more of the expressions that result in logging as UNLIKELY
22:15.19CIA-28BRL-CAD: 03brlcad * r48084 10/brlcad/trunk/ (4 files in 2 dirs):
22:15.20CIA-28BRL-CAD: add a new bu_str_escape() function for escaping string characters with
22:15.20CIA-28BRL-CAD: backslashes. supports static and dynamic memory models as well as overlapping
22:15.20CIA-28BRL-CAD: or same input/output buffers. should be threadsafe and re-entrant as long as
22:15.20CIA-28BRL-CAD: the inputs are.
22:55.26CIA-28BRL-CAD: 03brlcad * r48085 10/brlcad/trunk/ (include/bu.h src/libbu/escape.c):
22:55.27CIA-28BRL-CAD: add a new bu_str_unescape() function for removing backslash characters from
22:55.27CIA-28BRL-CAD: strings. simpler to implement since the output is always less than or equal in
22:55.27CIA-28BRL-CAD: size to the input. otherwise,similar to bu_str_escape() in that it supports
22:55.27CIA-28BRL-CAD: static and dynamic memory models as well as overlapping or same input/output
22:55.27CIA-28BRL-CAD: buffers and should be threadsafe and re-entrant as long as the inputs are. make
22:55.28CIA-28BRL-CAD: sure we null-terminate.
23:06.31CIA-28BRL-CAD: 03n_reed * r48086 10/brlcad/trunk/src/other/perplex/ (CMakeLists.txt scanner_template.c): lose libm dependency
23:16.51CIA-28BRL-CAD: 03brlcad * r48087 10/brlcad/trunk/src/libbu/test_quote.c: doesn't actually use stdarg or stdlib
23:17.12CIA-28BRL-CAD: 03tbrowder2 * r48088 10/brlcad/trunk/regress/mged.sh: document reason for new special tests
23:39.23CIA-28BRL-CAD: 03brlcad * r48089 10/brlcad/trunk/src/libbu/escape.c: don't call strlen() before we know whether input is NULL
23:49.20CIA-28BRL-CAD: 03brlcad * r48090 10/brlcad/trunk/src/libbu/test_escape.c: add an initial stab at a unit test for the new escape/unescape routines
23:49.36CIA-28BRL-CAD: 03brlcad * r48091 10/brlcad/trunk/src/libbu/ (CMakeLists.txt Makefile.am): hook test_escape into the build
IRC log for #brlcad on 20111221

IRC log for #brlcad on 20111221

00:16.57CIA-28BRL-CAD: 03brlcad * r48092 10/brlcad/trunk/src/libbu/test_escape.c: simplify testing, generalizing for bu_str_escape() cases
00:32.28CIA-28BRL-CAD: 03brlcad * r48093 10/brlcad/trunk/src/libbu/test_escape.c: add escape test cases
00:46.24CIA-28BRL-CAD: 03starseeker * r48094 10/brlcad/trunk/regress/repository.sh: remove the INSTALL check, doesn't apply in this form and its breaking distcheck. Leave the Makefile.am check until there aren't any more Makefile.am files...
01:06.57CIA-28BRL-CAD: 03brlcad * r48095 10/brlcad/trunk/src/libbu/escape.c: yay for unit testing doing its job. if there's a slash at the end, we might run past the buffer end so make sure we don't.
01:07.46CIA-28BRL-CAD: 03brlcad * r48096 10/brlcad/trunk/src/libbu/test_escape.c: a few more enhanced tests to check for round-trip behavior
01:48.34*** join/#brlcad scooby (~Robert@host-92-21-209-117.as13285.net)
02:22.41*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
05:05.26brlcadstarseeker: did you sync the doc files before moving the .cmake files into place?
05:10.51brlcadjust a double-check since there've been a lot of edits since they were first added
05:13.07brlcada build system functionality assertion came to mind earlier today, making sure the build still works and runs correctly on a non-X11 build
05:13.43starseekerbrlcad: yeah - did a diff on them, synced a fair bit of stuff
05:13.44brlcadtemporarily renaming/moving Xlib.h or libX11.so should do the trick
05:13.48brlcadawesome
05:14.23starseekerfigured you'd want to do a read-through anyhow - I've been doing the CMake stuff so long I'm not the best guy for an intro anymore
05:14.43brlcadI do/am/will, but wanted to check on that status before I get dirty
05:14.45starseekerupdated all the platform readme's at the same time
05:14.50starseekernods
05:15.40starseekerI tried disabling X11, I think... haven't done a full "move the X11 lib and header" test though
05:15.54brlcadfwiw, the src/other/step/express declaration you added masked a bug
05:16.03starseekeryeah, was afraid of that...
05:16.15brlcadthat function is called with two args and three args
05:16.43starseekerhas no clue why gcc wasn't barfing...
05:16.59brlcadthere's nothing wrong if the types happen to be coercable
05:17.08brlcadC allows feeding too few
05:17.10starseekeris betting most of the changes needed for a non-Tk build apply to the non-X11 build...
05:17.33brlcadnot an important issue, just noteworthy
05:18.01brlcadI wouldn't look into it myself until nick is done and we're merged with the git branch
05:18.04starseekernods - didn't want to dig too hard into it, since we've got to sync with the github version at some point and I think that's diverged pretty significantly
05:18.08starseekerer, yeay :-)
05:18.26brlcadmental check for later though, as that's a crasher
05:18.35brlcador rather, a memory corruption
05:18.54starseekeris of the opinion that codebase needs a thorough housecleaning
05:19.51starseekerhopefully the github work will help some, but I must admit that "we yanked frees to avoid crashes and the memory usage exploded" wasn't particularly reassuring
05:20.34brlcadgrain of salt
05:20.54brlcadthere's a couple weeks of reviewing each commit one by one ahead
05:21.16brlcadpreceeded by a week or two setting up regression tests for step-g
05:21.27brlcader, s/week/day/
05:21.42starseekerwinces... that'll be fun (in a pulling teeth kinda way...)
05:22.31starseekerdoes want to check out the ctest setup they have for testing
05:22.48brlcadmeh
05:25.10CIA-28BRL-CAD: 03starseeker * r48097 10/brlcad/trunk/src/other/CMakeLists.txt: only look for tk.h if we actually want Tk...
05:38.55CIA-28BRL-CAD: 03starseeker * r48098 10/brlcad/trunk/misc/CMake/BRLCAD_Options.cmake: If it walks like a bool and quacks like a bool, call it a bool
06:07.29CIA-28BRL-CAD: 03starseeker * r48099 10/brlcad/trunk/ (CMakeLists.txt src/libfb/tcl.c src/mged/doevent.c): These tweaks get things building without X11 headers on Gentoo linux...
06:20.39starseekerwoo-hoo!  make regress passed on an X11-disabled build (after the above changes)
06:21.02starseekerbuild with the X11 headers and /usr/lib64/libX11.so moved
06:21.06starseekers/build/built
06:21.37starseekerwonders how long it's been since that config was tested... or the non-Tk one, for that matter... lot of the changes were C code...
06:22.22brlcadthey were all strict issues, which wasn't in place before this year
06:22.58brlcadmy last non-x build was probably 2 years ago
06:23.08brlcadmged works?
06:23.21brlcadmged test.g ... should kick off classic iirc
06:26.42starseekeruh... it launches mged with the nu display manager
06:26.55brlcadright, good
06:27.07brlcadnu = null
06:27.11starseekerdoes prompt first, which is a bit silly when nu is the only option
06:31.51CIA-28BRL-CAD: 03starseeker * r48100 10/brlcad/trunk/CMakeLists.txt: Disable opengl like we mean it if the required criteria aren't met
06:32.29starseekeractually didn't expect all of regress to pass - figured the gui or loadtk commands would have an issue
06:33.34starseekerwell, another checkbox ticked :-)
06:33.36starseekerzzzzz
06:40.36*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
07:03.12brlcadit's worked in the past so even if it didn't work, wouldn't likely have been anything significant -- usually just code creep from that mode not getting exercised regularly
07:03.43brlcadnice to have that baseline confirmed working again, though and in strict nonetheless
07:04.11brlcadthough those fb funcs shouldn't exist public (missing fb callbacks)
08:55.24brlcadcalls it, wanders
10:16.53*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
14:12.11``Erikheh http://brlcad.org/~erik/brlcad.svg
14:16.02archivistmonitor not wide enough error at line one
14:21.22``Erikheh, it's a mess, and it's the cleanest one from the base graphviz algorithm set
15:16.33brlcad``Erik: funny but more useful would be seeing just one tool instead of 400 .. that's most of the complexity
15:17.21brlcadthere's approximately 25 base libraries, so one tool is going to have somewhere around that many lines anyways
15:17.26brlcad~400 * 25
15:17.26ibot10000
15:21.24``ErikI don't see any obvious way to do that, this was just "cmake --graphviz=brlcad.dot /path/to/brlcad"
15:22.21``Erikthey may be add-on generators to cmake *shrug*
15:28.31starseekeryawns
15:49.48CIA-28BRL-CAD: 03starseeker * r48101 10/brlcad/trunk/src/other/step/src/express/ (CMakeLists.txt expprint.c): Nick says he created this for debugging purposes and it can go.
15:55.19CIA-28BRL-CAD: 03starseeker * r48102 10/brlcad/trunk/ (3 files in 3 dirs):
15:55.19CIA-28BRL-CAD: Do a little rework on the lemon target macro - saw an error: Error renaming from
15:55.19CIA-28BRL-CAD: 'expparse.c' to 'expparse.c': No such file or directory - this might happen if
15:55.19CIA-28BRL-CAD: lemon does something wrong, but it could also mean lemon isn't done and the copy
15:55.19CIA-28BRL-CAD: command tries to proceed anyway, so split out the steps to make intermediate
15:55.20CIA-28BRL-CAD: file dependencies explicit - may help.
15:56.25kanzurehello world
16:17.19CIA-28BRL-CAD: 03n_reed * r48103 10/brlcad/trunk/src/other/perplex/scanner_template.c: better to create string scanner from pointer and length
16:26.23brlcadhello kanzure
16:37.35CIA-28BRL-CAD: 03n_reed * r48104 10/brlcad/trunk/src/other/perplex/scanner_template.c: copy input string to buffer so it can be modified if necessary
16:37.47CIA-28BRL-CAD: 03brlcad * r48105 10/brlcad/trunk/regress/mged.sh: don't need two tests just to make sure mged will receive commands. keep the more complex example since it creates geometry.
16:39.11CIA-28BRL-CAD: 03r_weiss * r48106 10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c: Updated function 'nmg_find_pt_in_lu' in file 'nmg_info.c'. Made changes to improve performance.
16:42.43CIA-28BRL-CAD: 03n_reed * r48107 10/brlcad/trunk/src/other/perplex/scanner_template.c: avoid mixing code and declarations
16:45.43CIA-28BRL-CAD: 03r_weiss * r48108 10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c: Updated function 'nmg_find_pt_in_face' in file 'nmg_info.c'. Made changes to improve performance.
16:48.27CIA-28BRL-CAD: 03tbrowder2 * r48109 10/brlcad/trunk/regress/mged.sh: only one test tgm now
17:03.35CIA-28BRL-CAD: 03n_reed * r48110 10/brlcad/trunk/src/other/perplex/scanner_template.c: added an unput routine similar to lex unput
18:49.03CIA-28BRL-CAD: 03n_reed * r48111 10/brlcad/trunk/src/other/perplex/scanner_template.c: add missing prototype
18:57.12CIA-28BRL-CAD: 03brlcad * r48112 10/brlcad/trunk/regress/mged.sh: readd an even simpler test that makes sure mged will run and exit before we start piping in commands
19:24.25CIA-28BRL-CAD: 03brlcad * r48113 10/brlcad/trunk/src/librt/primitives/nmg/nmg_info.c: (log message trimmed)
19:24.25CIA-28BRL-CAD: magic number checking overhaul. remove most of the interior loop and interior
19:24.25CIA-28BRL-CAD: logic magic number checking. it's important to perform magic number checks as
19:24.25CIA-28BRL-CAD: part of input validation (akin to assert()) but need not be part of ongoing
19:24.25CIA-28BRL-CAD: calculations. checking inputs insures that we'll at least narrow in on memory
19:24.26CIA-28BRL-CAD: corruption to a function scope, which is usually good enough. technically, this
19:24.26CIA-28BRL-CAD: may introduce a logic change if there is some nasty code relying on a bu_bomb()
20:27.44CIA-28BRL-CAD: 03brlcad * r48114 10/brlcad/trunk/src/other/perplex/mbo_getopt.cpp: make the mbo_getopt replacement func return -1 like getopt(3), not EOF
20:28.57CIA-28BRL-CAD: 03brlcad * r48115 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp scanner.re scanner_template.c): fgetc() returns an int, not a char so capture the EOF return value being cast through unsigned char as an int instead of a char (255)
20:36.38*** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni)
20:42.38CIA-28BRL-CAD: 03starseeker * r48116 10/brlcad/trunk/regress/weight.sh:
20:42.38CIA-28BRL-CAD: Add a (commented out, for now) additional test for rtweight that feeds it a
20:42.38CIA-28BRL-CAD: more... quirky density file. As rtweight's parsing of density files is
20:42.38CIA-28BRL-CAD: currently set up, this will infinite loop (and fill up your hard drive) but
20:42.38CIA-28BRL-CAD: after rtweight is improved enable this test (will need to replace the current
20:42.39CIA-28BRL-CAD: 'results text' for weight2 with the correct output.
21:00.43CIA-28BRL-CAD: 03brlcad * r48117 10/brlcad/trunk/src/librt/prcomb.c: file is unused
21:06.25CIA-28BRL-CAD: 03brlcad * r48118 10/brlcad/trunk/src/libicv/Makefile.am: manually include the png dirs
21:36.48starseekerbrlcad: does the Clarified Artistic License pose any problems for us?  http://www.ncftp.com/ncftp/doc/LICENSE.txt
21:55.22brlcadstarseeker: given it's a license we don't presently use or have to manage, absolutely .. it'd be yet another with potential incompatibility subtleties
21:55.47brlcadreading the history, the license is an improvmement but was later replaced by the artistic 2.0 license
21:55.56brlcadcurrently the osi-recommended one to use
21:56.31brlcadstill, I'd be leary simply because it's "yet another" .. something would have to be darn worthy and that .. seems unlikely
22:04.54starseekerOK, kinda figured...
22:06.21starseekernuts
22:06.32brlcadfrom my quick layman reading..
22:06.40brlcadit seems to me like it's entirely gpl-comaptible
22:06.50brlcadbut not necessarily lgpl compatible
22:08.17starseekeralrightie.  Not terribly critical - the elvis clone of Vi has a Win32 port and uses that license.  
22:08.28brlcadhehe
22:08.57starseeker?
22:09.11brlcadnothing :)
22:09.17brlcadI'd just agree
22:09.23brlcadnot terribly critical :P
22:09.37starseekerah
22:11.53starseekerjust thought I'd ask - jove is ever more glaring on the "thorns in the side of the Windows port" list
22:12.26CIA-28BRL-CAD: 03bob1961 * r48119 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Modified the signature of the polygon callback. Added calls to polygon callback in end_poly_move.
22:12.56brlcadhttp://developer.qt.nokia.com/doc/qt-4.8/widgets-codeeditor.html
22:13.18brlcador even http://developer.qt.nokia.com/doc/qt-4.8/qtextedit.html#id-2c12966c-5a94-46ac-a1ef-dc375be82992
22:14.48CIA-28BRL-CAD: 03bob1961 * r48120 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Added functionality to get/set the polygon list in view coordinates.
22:52.53CIA-28BRL-CAD: 03n_reed * r48121 10/brlcad/trunk/src/other/ (10 files in 3 dirs): initial build of step express parser using perplex scanner
23:26.42CIA-28BRL-CAD: 03starseeker * r48122 10/brlcad/trunk/TODO: Add note to work on rtweight/density file parsing.
23:42.02CIA-28BRL-CAD: 03Tbrowder 07http://brlcad.org * r3258 10/wiki/Contributor_Quickies: correct typo
IRC log for #brlcad on 20111222

IRC log for #brlcad on 20111222

00:06.45*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
00:07.04*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
00:53.38CIA-28BRL-CAD: 03tbrowder2 * r48123 10/brlcad/trunk/src/librt/primitives/bot/bot.c: ws cleanup
01:02.22CIA-28BRL-CAD: 03Tbrowder 07http://brlcad.org * r3259 10/wiki/Contributor_Quickies: correct name of mged command (bb, not bbox); correct typo
02:16.32CIA-28BRL-CAD: 03tbrowder2 * r48124 10/brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: ws format
02:54.29*** join/#brlcad IriX64 (~kvirc@64.229.226.37)
05:09.49CIA-28BRL-CAD: 03Sean 07http://brlcad.org * r3260 10/wiki/Contributor_Quickies: better
07:46.58*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
07:51.19*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:22.56*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
12:36.23*** join/#brlcad cvds_ (~leila@e255180.upc-e.chello.nl)
13:31.27CIA-28BRL-CAD: 03tbrowder2 * r48125 10/brlcad/trunk/TODO: expand list of missing man pages so it can be easily viewed
13:50.58CIA-28BRL-CAD: 03tbrowder2 * r48126 10/brlcad/trunk/src/libged/bb.c: correct file name in intro comment
13:52.27CIA-28BRL-CAD: 03tbrowder2 * r48127 10/brlcad/trunk/regress/main.sh: correct typo
13:53.08CIA-28BRL-CAD: 03tbrowder2 * r48128 10/brlcad/trunk/INSTALL: correct typo
13:55.11*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
13:55.17pawleeqhello
13:56.15pawleeqI published another popular article about modeling in brlcad, it can be found here: http://www.abclinuxu.cz/clanky/brl-cad-zaklady-modelovani
13:56.28pawleeqit is in czech
13:58.18brlcadpawleeq: awesome!
13:58.43brlcadI was reading that earlier today :)
14:00.00brlcadwell not "reading" per-se, but skimming over the article and looking at the BRL-CAD portions I recognized ;)
14:01.03pawleeqI will continue with this and deeper I will go, the more I could use your help
15:02.13CIA-28BRL-CAD: 03tbrowder2 * r48129 10/brlcad/trunk/t.c: adding temp file to test ssh access
15:03.08CIA-28BRL-CAD: 03tbrowder2 * r48130 10/brlcad/trunk/t.c: modding temp file to test ssh access
15:15.58CIA-28BRL-CAD: 03tbrowder2 * r48131 10/brlcad/trunk/t.c: modding temp file to test ssh access
15:16.25CIA-28BRL-CAD: 03tbrowder2 * r48132 10/brlcad/trunk/t.c: modding temp file to test ssh access
15:17.41*** join/#brlcad yiyus (1242712427@je.je.je)
15:23.52CIA-28BRL-CAD: 03tbrowder2 * r48133 10/brlcad/trunk/t.c: modding temp file to test ssh access
15:24.29CIA-28BRL-CAD: 03tbrowder2 * r48134 10/brlcad/trunk/t.c: modding temp file to test ssh access
15:37.59CIA-28BRL-CAD: 03tbrowder2 * r48135 10/brlcad/trunk/t.c: modding temp file to check ssh access
15:50.16CIA-28BRL-CAD: 03tbrowder2 * r48136 10/brlcad/trunk/t.c: test ssh access
15:53.19CIA-28BRL-CAD: 03tbrowder2 * r48137 10/brlcad/trunk/t.c: test ssh access
15:54.06CIA-28BRL-CAD: 03tbrowder2 * r48138 10/brlcad/trunk/t.c: testing ssh access
16:09.40*** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net)
16:12.19CIA-28BRL-CAD: 03bob1961 * r48139 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Tweak cadwidgets::Ged::pane_mouse_3dpoint to also use polygon points.
16:15.57CIA-28BRL-CAD: 03tbrowder2 * r48140 10/brlcad/trunk/t.c: test ssh access
16:16.27CIA-28BRL-CAD: 03tbrowder2 * r48141 10/brlcad/trunk/t.c: testing ssh access
16:19.49CIA-28BRL-CAD: 03tbrowder2 * r48142 10/brlcad/trunk/t.c: testing ssh access
17:55.42CIA-28BRL-CAD: 03brlcad * r48143 10/brlcad/trunk/include/bu.h:
17:55.42CIA-28BRL-CAD: document the extensively expaned support being added to bu_str_escape() to make
17:55.42CIA-28BRL-CAD: the previous 'chars' parameter actually represent a full-fledged regular bracket
17:55.42CIA-28BRL-CAD: expression. this includes support for negative (^) expressions and named
17:55.42CIA-28BRL-CAD: character classes.
18:00.26CIA-28BRL-CAD: 03brlcad * r48144 10/brlcad/trunk/src/libbu/escape.c: stub in initial function for expanding the previous 'chars' input into an expanded list of chars to match
18:05.29CIA-28BRL-CAD: 03starseeker * r48145 10/brlcad/trunk/misc/CMake/ThirdParty.cmake: we want full path for this binary...
18:19.45*** join/#brlcad DarkCalf (DC@173.231.40.98)
18:27.45CIA-28BRL-CAD: 03tbrowder2 * r48146 10/brlcad/trunk/src/tclscripts/mged/help.tcl: add mged 'bb' command help
18:57.17CIA-28BRL-CAD: 03n_reed * r48147 10/brlcad/trunk/src/other/step/src/express/ (expparse.y expscan.l): fixed a few typos
18:58.14CIA-28BRL-CAD: 03tbrowder2 * r48148 10/brlcad/trunk/doc/docbook/system/mann/en/bb.xml: correct typo
19:08.09CIA-28BRL-CAD: 03brlcad * r48149 10/brlcad/trunk/src/libbu/test_escape.c: some clarify on the escape test output
19:08.58CIA-28BRL-CAD: 03brlcad * r48150 10/brlcad/trunk/src/libbu/escape.c: add support for negative expressions (start with circumflex/carat '^').
20:09.54CIA-28BRL-CAD: 03brlcad * r48151 10/brlcad/trunk/src/libbu/vls.c:
20:09.54CIA-28BRL-CAD: prevent crashing after bu_vls_strgrab() if the vls was never initialized.
20:09.54CIA-28BRL-CAD: bu_vls_addr() will return the address to a static buffer if it's empty, so care
20:09.54CIA-28BRL-CAD: must be taken to not return that as the char* from bu_vls_strgrab().
20:26.23CIA-28BRL-CAD: 03brlcad * r48152 10/brlcad/trunk/src/libbu/escape.c: fix/add support for negative expressions specified with ^ where we needed to iterate over all chars to make sure none match before escaping
20:26.31CIA-28BRL-CAD: 03brlcad * r48153 10/brlcad/trunk/src/libbu/test_escape.c: Add some not-cases to the testing
21:59.58CIA-28BRL-CAD: 03starseeker * r48154 10/brlcad/trunk/t.c: clear stray file from ssh testing...
22:07.04CIA-28BRL-CAD: 03starseeker * r48155 10/brlcad/trunk/CMakeLists.txt: Oops - put the DATA_DIR prefix in the MAN_DIR variable
22:14.45CIA-28BRL-CAD: 03tbrowder2 * r48156 10/brlcad/trunk/regress/mged.sh: redfine 'tgms'
22:18.54CIA-28BRL-CAD: 03tbrowder2 * r48157 10/brlcad/trunk/src/libged/analyze.c: fix typo
22:21.17CIA-28BRL-CAD: 03tbrowder2 * r48158 10/brlcad/trunk/src/libged/bb.c: remove extra blank line
23:36.00CIA-28BRL-CAD: 03starseeker * r48159 10/brlcad/trunk/misc/CMake/Docbook.cmake: copy-paste fix in error messages for Docbook tools
IRC log for #brlcad on 20111223

IRC log for #brlcad on 20111223

04:07.45CIA-28BRL-CAD: 03starseeker * r48160 10/brlcad/trunk/misc/CMake/Docbook.cmake: Docbook.cmake is logic (one of the reasons for breaking it out here) so put the header on it.
04:09.30CIA-28BRL-CAD: 03starseeker * r48161 10/brlcad/trunk/ (3 files in 2 dirs): Might as well match the spelling for DocBook that docbook.org is using.
04:18.16CIA-28BRL-CAD: 03starseeker * r48162 10/brlcad/trunk/ (CMakeLists.txt src/other/CMakeLists.txt): go for consistency
09:01.58*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
09:32.13*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
09:33.16*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
18:04.24CIA-28BRL-CAD: 03erikgreenwald * r48163 10/brlcad/trunk/src/libgcv/test_bottess.c: macro up the test harness for simple triangle intersection (obfuscate to clarify)
19:12.18CIA-28BRL-CAD: 03n_reed * r48164 10/brlcad/trunk/src/libgcv/wfobj/ (CMakeLists.txt Makefile.sample): remove unused makefile
19:34.00*** join/#brlcad fosburg (~steve@or-67-238-28-16.dhcp.embarqhsd.net)
19:36.26CIA-28BRL-CAD: 03n_reed * r48165 10/brlcad/trunk/src/libgcv/wfobj/ (obj_grammar.yy obj_parser.cpp obj_rules.h obj_rules.l): Renaming to distinguish extra type and state type. Remember to free extra.
19:51.55CIA-28BRL-CAD: 03n_reed * r48166 10/brlcad/trunk/src/other/perplex/ (parser.y perplex.cpp): initialize conditions string, close output file, and free special-op strings
19:56.31*** part/#brlcad fosburg (~steve@or-67-238-28-16.dhcp.embarqhsd.net)
22:02.35CIA-28BRL-CAD: 03n_reed * r48167 10/brlcad/trunk/src/libbu/escape.c: don't declare variable in for's init expression
22:37.25*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
22:50.31CIA-28BRL-CAD: 03n_reed * r48168 10/brlcad/trunk/src/libgcv/wfobj/obj_token_type.h: avoid comparison between bool and unsigned char
22:51.34*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
23:15.02*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
IRC log for #brlcad on 20111224

IRC log for #brlcad on 20111224

03:23.50CIA-28BRL-CAD: 03Starseeker 07http://brlcad.org * r3261 10/wiki/Lexer_Parser: Update lexer/parser page with actual outcome, mention Nick's work with perplex
03:43.24*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
03:54.37*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
04:15.57*** join/#brlcad n_reed_ (~molto_cre@BZ.BZFLAG.BZ)
04:16.39*** join/#brlcad DarkCalf (DC@173.231.40.98)
04:21.28*** join/#brlcad DarkCalff (DC@173.231.40.98)
08:26.46*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
16:28.52*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
21:55.51*** join/#brlcad kanzure (~kanzure@131.252.130.248)
23:44.45*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
IRC log for #brlcad on 20111225

IRC log for #brlcad on 20111225

00:16.38*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
04:38.11*** join/#brlcad DarkCalfz (DC@173.231.40.98)
07:02.47*** join/#brlcad merzo (~merzo@152-186-133-95.pool.ukrtel.net)
09:30.32*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:39.36*** join/#brlcad merzo (~merzo@98-66-132-95.pool.ukrtel.net)
IRC log for #brlcad on 20111226

IRC log for #brlcad on 20111226

00:23.36*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
03:50.06*** join/#brlcad Sparxz (~mark@213-94-252-200-dynamic.b-ras1.dbn.dublin.eircom.net)
04:01.56*** part/#brlcad Sparxz (~mark@213-94-252-200-dynamic.b-ras1.dbn.dublin.eircom.net)
11:05.39*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
13:40.25*** join/#brlcad merzo (~merzo@141-81-200-46.pool.ukrtel.net)
16:10.18*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
17:15.32*** join/#brlcad xFirex_ (75c19b3e@gateway/web/freenode/ip.117.193.155.62)
17:16.22xFirex_Hello Everyone, I have a problem with BRLCad brlcad-7.20.4-0.fedora.i386.rpm in Fedora 16
17:16.55xFirex_Getting this error when trying to start it "/usr/brlcad/bin/mged: error while loading shared libraries: libtclcad.so.19: cannot open shared object file: No such file or directory "
17:23.51*** part/#brlcad xFirex_ (75c19b3e@gateway/web/freenode/ip.117.193.155.62)
17:25.52*** join/#brlcad N0Nick (75c19b3e@gateway/web/freenode/ip.117.193.155.62)
17:28.09*** join/#brlcad Konopen (75c19b3e@gateway/web/freenode/ip.117.193.155.62)
17:32.15*** part/#brlcad Konopen (75c19b3e@gateway/web/freenode/ip.117.193.155.62)
17:34.27*** join/#brlcad Konopen (75c19b3e@gateway/web/freenode/ip.117.193.155.62)
17:35.11KonopenHello Everyone, I have problem running brlcad 7.20.4-0 in fedora 16
17:40.23*** part/#brlcad Konopen (75c19b3e@gateway/web/freenode/ip.117.193.155.62)
17:42.06*** join/#brlcad konopen (~nawin@117.193.155.62)
17:46.24konopenHello
17:52.29*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
17:57.04konopenIs anyone available to help me with an issue in brlcad
18:02.58*** part/#brlcad konopen (~nawin@117.193.155.62)
18:14.46*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
22:50.43*** join/#brlcad ibot_ (~ibot@rikers.org)
22:50.43*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
IRC log for #brlcad on 20111227

IRC log for #brlcad on 20111227

05:46.56*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
06:02.12*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
06:05.18*** join/#brlcad cadnewbie (cadnewbie@ool-4a58d269.dyn.optonline.net)
07:41.56*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:03.19*** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net)
11:32.08CIA-28BRL-CAD: 03Kides 07http://brlcad.org * r3262 10/wiki/FullHostList:
11:32.16CIA-28BRL-CAD: 03Kides 07http://brlcad.org * r3263 10/wiki/FullHostList:
13:40.55*** join/#brlcad merzo (~merzo@31-143-201-46.pool.ukrtel.net)
16:41.05CIA-28BRL-CAD: 03n_reed * r48169 10/brlcad/trunk/src/other/perplex/ (perplex.h scanner.re): remove unused member from scanner data struct
17:15.15CIA-28BRL-CAD: 03erikgreenwald * r48170 10/brlcad/trunk/src/libgcv/CMakeLists.txt: disable test prog on win32 (dll export/import issue)
18:23.30*** join/#brlcad Stattrav (u3131@gateway/web/irccloud.com/x-jchpvqokxrprekcq)
19:20.24CIA-28BRL-CAD: 03Sean 07http://brlcad.org * r3264 10/wiki/FullHostList: Reverted edits by [[Special:Contributions/Kides|Kides]] ([[User talk:Kides|Talk]]); changed back to last version by [[User:Dloman|Dloman]]
19:20.27CIA-28BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Kides]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
20:22.06CIA-28BRL-CAD: 03n_reed * r48171 10/brlcad/trunk/src/other/perplex/scanner.re: typo
20:22.40CIA-28BRL-CAD: 03n_reed * r48172 10/brlcad/trunk/src/other/perplex/ (parser.y token_type.h): add header and footer
20:41.41CIA-28BRL-CAD: 03n_reed * r48173 10/brlcad/trunk/src/other/perplex/README.txt: initial documentation
22:43.36CIA-28BRL-CAD: 03n_reed * r48174 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Per-vertex colors are a non-standard extension, but may be found in Meshlab OBJ exports. Accept but ignore them.
23:46.00brlcadjordisayol: presume you saw those rpm failure reports? .. any ideas on what the issue is?
23:46.27jordisayolbrlcad: nop :-/
23:46.39jordisayolI did not see
23:48.24jordisayolbrlcad: where are those reports?
IRC log for #brlcad on 20111228

IRC log for #brlcad on 20111228

00:03.39jordisayolbrlcad: can you please give me some info about rpm failure reports?
00:38.26jordisayolI have to go
00:38.42jordisayolbrlcad: bye bye
00:38.49brlcadok
00:38.52brlcadsorry, got distracted
00:38.56brlcadthe reports were here
00:39.05brlcad12:16 < xFirex_> Hello Everyone, I have a problem with BRLCad brlcad-7.20.4-0.fedora.i386.rpm in Fedora 16
00:39.08brlcad12:16 < xFirex_> Getting this error when trying to start it "/usr/brlcad/bin/mged: error while loading shared libraries: libtclcad.so.19: cannot open shared object file: No such file or directory "
00:39.31brlcadthen another individual a little while later12:35 < Konopen> Hello Everyone, I have problem running brlcad 7.20.4-0 in fedora 16
00:42.23jordisayolbrlcad: do you know if they re-login after install?
00:42.32brlcadonope
00:42.40brlcadill ask if they come back
00:42.54jordisayolbrlcad: paths need re-login to be loaded
00:43.00brlcaddo you modify ldconfig or something?
00:43.41jordisayolnop, i just modify the path and manpath env variables
00:44.08brlcadhm, interesting
00:44.52brlcadokay, well if someone else reports same error we'll see if that does the trick :)
00:45.00brlcadgood to know, thanks
00:45.18brlcadwould be good note for the release notes if it wasn't included
00:45.19jordisayolwait a moment....
00:49.37jordisayolbrlcad: the script executed during the installation is: brlcad/misc/debian/brlcad.postinst and when removed brlcad/misc/debian/brlcad.postrm , that's all
00:49.46brlcadk
00:51.03brlcadunder traditional gnu ld behavior, that shouldn't affect a runtime error loading shared libraries
00:51.24brlcadbut I know there have apparently been some major changes to the behavior of ld recently on linux
00:52.44jordisayoltomorrow I'll create a virtual machine with fedora 16 . is important the bit, 32 or 64?
00:52.56brlcadno idea, they weren't specific
00:53.28jordisayolwell, I don't think so
00:54.17jordisayolok, tomorrow i'll tell you something about
00:55.12jordisayolbrlcad: goog night for me :-) near 2 o'clock here
00:55.19brlcadcya :)
00:55.24jordisayolbye
07:07.43*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
07:12.13*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
08:14.34*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
12:57.12*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:15.22jordisayolbrlcad: ping
15:18.14``ErikO.o
15:19.16``Erikjordisayol: personal, or something that someone else can help with?
15:19.46jordisayol``Erik: hello!
15:20.31``Erikthis laptop isn't letting me scroll up right, you're doing something with a debain leenewx variant?
15:20.43``Erikdebian, even :)
15:21.16``Erikand something about fedora, even... but still linux
15:21.19jordisayolNo, is just that yesterday brlcad toll me that some fedora 16 users experienced problems with our rmp packages
15:21.48``ErikI vagually recall something about some sigill stuff, is that it
15:22.27jordisayolwell, he says something about the shared libraries
15:22.41jordisayolmissing for mged command
15:23.19``Erikhm, you'll have to help me help you... the typical issue is requiring dev libs (.so) instead of user libs (.so.0.0)
15:23.26``Erikin the link stage
15:23.40``Erik(linux uses .so, right?)
15:24.17jordisayolyes, but this problem do not happen on fedora 15 and previous releases
15:24.25``Erikif you do, um, the command to show link deps on the mged binary, that'll tell you a lot
15:25.07jordisayolthe case is that today I've installed fedora 16 (64-bit)  on a virtualbox, and in this clean linux, the mged properly works without problems
15:25.48``Erikand 64b is the issue they complain about? or 32b?
15:25.55brlcad``Erik: you read up on the penny arcade lashing?  hilarious
15:26.00brlcadjordisayol: pong :0
15:26.03jordisayolbrlcad don't know
15:26.08``Erikbrlcad: ocean marketing? yeah...
15:26.13jordisayolhello brlcad
15:26.14brlcadhehe
15:26.22``Eriktalk about putting a foot in ones mouth
15:26.33``Erik"bah, I can get into pax, who is this gabe guy?
15:26.50jordisayolhmmm, I already take lunch today....
15:27.22``Erikbrlcad: bz->crit ?
15:27.42brlcadgood idea actually
15:28.07brlcadbeen catching up on mails and commits, but this would be a good time
15:28.22``Erikover a year coming
15:28.52``ErikI put up an ssl httpd on crit, that might... complicate things.
15:28.59jordisayolbrlcad: I've installed rpm for fedora on a fresh installed fedora 16 in virtualbox, and there is not any problem, even without re-login, just typing the full path /usr/brlcad/bin/mged
15:29.29brlcadjordisayol: okay, that's all that can be done for now then
15:29.44jordisayolbrlcad: yes
15:29.49``Erikjordisayol: can you pastebin ldd path/to/mged to see if there's an dev vs user lib issue?
15:29.51brlcadif it can't be reproduced and the person isn't here, we'll just have to wait for a follow-up report if any
15:30.15``Erik(it's ldd, right? so used to otool -L)
15:30.19jordisayolok, just a moment
15:30.49jordisayolyes, it is
15:32.27brlcadwhat I suspect is happening is there's some incompatible library already installed on their fedora system
15:32.45brlcadthat or it was a partial/failed rpm download
15:33.10brlcadfrom the report, libtclcad.so.19 fails to load
15:33.23``Erikif this is the sigill, it's a damaged binary, damaged cpu, or cpu spec'd for a different arch (686 vs 586 using 686 only opcodes)
15:33.29brlcadthat may simply be the first library attempting to be loaded
15:33.33``Erikillegal instruction and all
15:34.11brlcadit wasn't getting that farb
15:34.17brlcadfar even
15:34.22brlcad12:16 < xFirex_> Getting this error when trying to start it "/usr/brlcad/bin/mged: error while loading shared libraries: libtclcad.so.19: cannot open shared object file: No such file or directory "
15:34.54``Erikah, my bad, thought I saw a sigill convo and this was pertinant... this laptop won't let me page up to read backlog :)
15:36.33``Erikbrlcad: I took the day off, I want crit to get to 'stable' asap, I don't want to be responsible for other biz's and such, but will aid how I can... lets DO THI! YEAH! </joeswansonfromfamilyguy>
15:38.38jordisayolbrlcad: here you have it: http://paste.debian.net/150390/
15:40.28jordisayolbrlcad: partial/failed is very unprovable because as rpm are compresses gz files, they cannot uncompress.
15:41.22brlcadyeah, so libtclcad is the first lib listed there
15:41.54``Erikmy guess would be that the issue is because someone installed to somewhere other than /usrbrlcad
15:42.05brlcadthat could be
15:42.31brlcadwhew, that mystery is solved
15:43.11jordisayolwell, i can test this, by installing one by one on the system and testing mged. but this requires some time
15:43.26``Erikcan it be scripted?
15:43.29brlcadjordisayol: if you like, but I wouldn't worry about it
15:43.43``Erikmachine time is cheap, human time is expensive :)
15:44.00brlcadit's all speculation without that user -- more time effective to just wait for someone else to report an issue since it can't be easily reproduced
15:44.07jordisayolbrlcad: can you make a "short" list of the probably libraries from the list?
15:44.29brlcadit seemed like more than that given two people reported a failure within a couple hours for fed16 but could have just been coincidence
15:44.47brlcadstill all speculation though
15:44.55jordisayolor just the same user loget with different nicks
15:45.17jordisayolloed*
15:45.35jordisayolarggg! "logged"
15:45.59``Eriksmells like someone thought they were smarter than they were and screwed up being "clever"
15:46.12brlcadjordisayol: looks like they were the same person, same ip
15:46.21jordisayolhehe
15:46.23brlcadso yeah, don't worrya bout it ;)
15:48.56jordisayolwell, if this "schizophrenic" user re-login, then we can continue the research
15:49.18``Erikbrlcad: bz lacks modssl and modproxy, which is why i'm reliant on crit. I'm using app servers behind modproxy, thus my interest in migration :) think we can knock it out before the newyear?
15:49.56brlcadpossibly
15:50.05brlcadquite likely even
15:51.03``Erikjordisayol: yeah, I'd call it pebcak, awesome that you're so aggressive in making it right :)
15:52.43jordisayolwell, I don't know what "pebcak" is, but thank you :-)
15:53.52``Erik"problem exists between computer and keyboard"
15:54.46jordisayolwow! i'll keep this sentence, hehe
15:55.26brlcad~pebcak
15:55.26ibotmethinks pebcak is Problem Exists Between Chair And Keyboard
15:55.28``Erik<-- marks jordisayol down as a hero of open source software maintenance O.o :)
15:55.35``Eriker, chair and keyboard, my bad
15:55.55jordisayolI think ``Erik is right :-/
15:55.58brlcadusb isn't likely the problem ;)
15:56.08``Erikdin5, beeyotch
15:56.18``Eriksometimes ps2
15:57.58``Erikbrlcad: ponder... ssh tunnel for 3306 to new machine, migrate mysqldb, test on various hosted sites, then start moving sites?
15:58.21``Erik(or is there an acceptable downtime window?)
15:59.15brlcaddowntime is acceptable if it's less than a few hours
15:59.21brlcadtunnel would work too
16:00.46``ErikI don't know the write rates of the variou sites, so I can't plot optimal migration
16:01.29``Erikbut I do want you to stop paying for that old clunker ;)
16:02.22brlcadthis biggest one should be no longer active  (bzflag's list service)
16:03.41``Erikpersonally, I'd bias impact based on $$'s... a free service can take several hours downtime... a day or two, even
16:03.43brlcadI'll get working on moving our site today, that should at least get things going again
16:04.00``Erikit's those $'s that scare me
16:04.01brlcadwhen was the last fs sync?
16:04.10``Erikiuhho
16:04.25``ErikI don't know if this machine has ever been synced
16:05.16``Erikya starting one up?
16:05.19brlcad.bz is technically a free service to those $$ users, so that's why a few hours is still acceptable .. just within reason shouldn't be more than a couple hours tops and that's with things going horribly wrong
16:05.47brlcadi'll check on it, don't want to migrate everything but user data is a good one to start with
16:06.04``ErikI'm an rsync newb, so if you know it, I'll step back
16:06.15``Erikotherwise, I'll pull up tutorial sites and start, let me know
16:06.51``ErikI had some c&p scripts on the old crit, but no understanding
16:09.16``Erikhttp://www.solitechgmbh.com/2010/03/06/using-rsync-for-quick-server-migartion/ seems useful
16:09.20brlcadyou can sync the passwd/group files
16:12.55``Erikdone
16:13.05brlcadgettings an fs manifest, I'll sync user data
16:13.37brlcadis the sslified apache from ports or custom install?
16:14.57``Erikports
16:15.07brlcadgreat
16:15.12``Eriklacks a primary, is all for vhost
16:15.43``Erikwell, it has a self-signed for primary, rather
16:16.10``Erik"namecheap" was offering a free year of ssl for one name, so I grabbed one for elfga.com
16:16.26brlcadthat's fine, nothing else using ssl obviously :)
16:16.40``Erikthey're also offering discounts and donations to eff for people who move from godaddy after the sopa mess
16:16.55``Erik$10/yr for a basic cert
16:17.01``Erikor so
16:17.41brlcadanother task you could take up, setting up intrusion detection/monitoring and stats
16:18.18``ErikI'm not sure what all you have set up, I've been manually setting the ipfw rules
16:18.26brlcadmy manual scripts are rather old school now .. I'd imagine there has to be some better tools in ports that could be set up
16:18.34brlcador even just migrating what's there, but that's not needed
16:19.27brlcadbasically "figure something out" so some measure is in place, ideally something that firewalls based on some profile of bad actvitivity
16:19.43``Erikwe're not running telnetd, so there's no remote issue... I really don't know heh :(
16:19.56``Erikwhat's the, uh, auto-ipfw deny script on bz?
16:20.02``ErikI'll migrate it as a first stage
16:20.19``Erikand we can todo a better solution
16:21.22``Erik(I mean, no default accounts, no simple pw's, I don't think the risk profile is that high righ tnow)
16:21.47``Erikack, lappy assploded
16:22.44``Erikdefcon slides say "don't be stupid with setup"
16:22.58brlcad/etc/sbin and /etc/crontab have the juicy details
16:23.23brlcadbut you'll have to go through each crontab one at a time to make sure it still is applicable for crit
16:23.41brlcadpotential path and tool changes, safeguard changes, etc
16:23.51brlcadnothing terribly complicated, should be obvious
16:24.03``Erikoh, your logging stuff, I've no idea what's up with that stuff
16:24.07``Erikgo set that up
16:24.22brlcadthat can be later
16:24.33``Erikok, crit has been unlogged so far, fwiw
16:24.47brlcadknows
16:24.49``Erikpheer my botnets
16:25.05brlcadso that's why you're logged in 15 times
16:26.47``Erikdon't make me slap your fro
16:27.42``Erik(I believe this is the first time I've seen bz below 1.0 load)
16:29.24brlcadhttp://www.zazzle.com/dont_tease_my_fro_tshirt-235666363645812532
16:34.02``Erikhttp:/crit.brlcad.org:3000
16:37.16brlcaddon't know what to make of that
16:38.55``Erikdid it not work?
16:40.07brlcadI get a page, but have no idea what "Advertising Testes" are .. sounds sticky
16:40.52``Erikthat's bottom goop, it's basically a 'todo' list on steroids, or a project management suite stripped down
16:41.15``Erikadd locations, add tasks to locations, ...
16:41.37brlcadwhat about locationless tasks? :)
16:41.51``Eriklocation called "anywhere" ;) I have one called "internet"
16:42.47``Erik(seriosuly, tell me what sucks, obviously the landing page pitch sucks... but learn and adjust, right?)
16:44.01brlcadhaving to add a location sucks :)
16:44.35``Erik"better default settings", roger
16:45.06``Erikhome and work, big honkin' delete buttons, yeh
16:46.37brlcadafter I created a location, I could add a task but then I can't get back to that page if I merely start over .. back to creating a location
16:46.43brlcadi.e, better navigation
16:47.34``Erikhroger, I've been unhappy with the default rails navigation myself
16:47.37brlcadwhen I recreated the same location, now it lists twice on the tasks page (along with a handful of other locations I didn't add)
16:47.45``Erikuniq opt, ok
16:48.04``Erikbah, other locs/
16:48.18``Erikok, hold up... is the basic premise something you might use
16:48.21``Erik?
16:49.32brlcaddunno
16:49.39brlcadutility of task tracking software is mostly dependant on usability (and some on flexibility)
16:50.03``Erikthe idea is a todo list with deps, so things that are not readt are not listed
16:50.06brlcadit's hard to get that usability down to dead-simple obvious and still be flexible enough for a given purpose
16:50.41``Erik(this is a throw-away to help me learn rails, btw)
16:52.29``Erikyeah, actually, I wrote this to help me, and I haven't used it... imma call it :)
16:52.49brlcadheh
17:58.34brlcadwoot, transfer underway
18:32.08CIA-28BRL-CAD: 03n_reed * r48175 10/brlcad/trunk/src/tclscripts/boteditor/botTools.tcl: rename some labels to increase clarity
22:03.45*** join/#brlcad b0ef (~b0ef@241.194.251.212.customer.cdi.no)
22:07.51CIA-28BRL-CAD: 03n_reed * r48176 10/brlcad/trunk/src/tclscripts/boteditor/ (botEditor.tcl botPropertyBox.tcl): allow setting bot mode and orientation from gui
22:23.42*** join/#brlcad ibot (~ibot@rikers.org)
22:23.42*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
23:34.10*** join/#brlcad kunigami (~kunigami@201.53.198.241)
23:35.32*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
IRC log for #brlcad on 20111229

IRC log for #brlcad on 20111229

00:12.46*** join/#brlcad ibot (~ibot@rikers.org)
00:12.46*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
00:25.08*** join/#brlcad ibot (~ibot@rikers.org)
00:25.08*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
00:27.39*** join/#brlcad ibot (~ibot@rikers.org)
00:27.39*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space!
08:49.08*** join/#brlcad DarkCalfz (DC@173.231.40.98)
08:49.09*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
09:39.23*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:34.41*** join/#brlcad kunigami (~kunigami@201.53.198.241)
17:33.12CIA-28BRL-CAD: 03n_reed * r48177 10/brlcad/trunk/src/ (5 files in 2 dirs): handle app data more opaquely
19:08.04*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
21:59.15*** join/#brlcad kunigami (~kunigami@201.53.198.241)
23:32.17CIA-28BRL-CAD: 03n_reed * r48178 10/brlcad/trunk/include/dm.h: update drawLines3D macro prototype to agree with r47494
IRC log for #brlcad on 20111230

IRC log for #brlcad on 20111230

01:37.12*** join/#brlcad kunigami (~kunigami@201.53.198.241)
03:19.12*** join/#brlcad jarray52 (~bigbear@unaffiliated/jarray52)
04:23.25jarray52Is it possible to create parametric models in BRL CAD using scripts?
04:24.34jarray52Actually, I should say, "Is it possible to create smooth surfaces using scripts?"
04:27.34jarray52For example, an aerodynamic car body constructed from lots of small cubes.
05:10.17*** join/#brlcad louipc (~louipc@archlinux/fellow/louipc)
10:00.05*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
13:53.56*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
14:18.44piksiuhh
14:19.10piksijordisayol: why would you want to create curved surfaces with cubes? you want nurbs for that
14:21.03jordisayolpiksi: !?
14:51.04piksiwhops
14:51.28piksijordisayol: sorry, i didn't notice jarray52 left and used tab completion too hastly :-)
14:52.09jordisayolpiksi: no problem :-)
14:52.09jordisayolHappy New Year!
14:52.44piksisame to you! :-)
16:37.18``Erikstarseeker: http://alvyray.com/Art/AndreAndWally.htm  and look at the 'making of' pdf, some interesting history and a mention of MAGI
18:47.27CIA-28BRL-CAD: 03n_reed * r48179 10/brlcad/trunk/src/other/CMakeLists.txt: condition SCL build on perplex/lemon rather than lex/yacc
19:12.42*** join/#brlcad DarkCalfz (DC@173.231.40.98)
19:12.42*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
19:21.32*** join/#brlcad piksi (piksi@pi-xi.net)
19:24.01*** join/#brlcad louipc (~louipc@archlinux/fellow/louipc)
19:24.02*** join/#brlcad kanzure (~kanzure@131.252.130.248)
19:24.02*** join/#brlcad yiyus (1242712427@je.je.je)
19:24.02*** join/#brlcad cvds_ (~leila@e255180.upc-e.chello.nl)
19:24.02*** join/#brlcad ChanServ (ChanServ@services.)
19:24.02*** mode/#brlcad [+o ChanServ] by bartol.freenode.net
19:55.21CIA-28BRL-CAD: 03n_reed * r48180 10/brlcad/trunk/src/other/step/ (3 files in 3 dirs): remove old debug header
20:54.42*** part/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
IRC log for #brlcad on 20111231

IRC log for #brlcad on 20111231

07:34.45*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
18:46.27*** join/#brlcad piksi (piksi@pi-xi.net)
19:21.29CIA-28BRL-CAD: 03RobertoBhr11 07http://brlcad.org * r3265 10/wiki/User:RobertoBhr11: New page: Profuse Sweating - Three Solutions to prevent Excessive sweating Around 8 million people in The United States alone suffer from hyperhidrosis. Sweating profusely is labeled as a medical p...
19:21.35CIA-28BRL-CAD: 03RobertoBhr11 07http://brlcad.org * r3266 10/wiki/User:RobertoBhr11:
20:54.41CIA-28BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User:RobertoBhr11]]": idiot
20:54.50CIA-28BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:RobertoBhr11]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites
22:01.25brlcaddamn.. long conversion script had been processing for more than 30 days before the server rebooted .. didn't finish, not even halfway I think